Skydda Teams medietrafik för delade VPN-tunnlar

Obs!

Den här artikeln är en del av en uppsättning artiklar som behandlar Microsoft 365-optimering för fjärranvändare.

Vissa Microsoft Teams-administratörer kan kräva detaljerad information om hur samtalsflöden fungerar i Teams med hjälp av en modell för delade tunnlar och hur anslutningar skyddas.

Konfiguration

För både anrop och möten, så länge de nödvändiga Optimera IP-undernät för Teams-media är korrekt på plats i routningstabellen, när Teams anropar funktionen GetBestRoute för att avgöra vilket lokalt gränssnitt som motsvarar den väg som ska användas för ett visst mål, returneras det lokala gränssnittet för Microsoft-mål i Microsofts IP-block som anges ovan.

Vissa VPN-klientprogram tillåter routningsmanipulering baserat på URL. Teams mediatrafik har dock ingen associerad URL, så kontrollen över routningen för den här trafiken måste göras med hjälp av IP-undernät.

I vissa scenarier, som ofta inte är relaterade till Teams-klientkonfiguration, passerar medietrafiken fortfarande VPN-tunneln även med rätt vägar på plats. Om du stöter på det här scenariot bör det räcka med att använda en brandväggsregel för att blockera Teams IP-undernät eller portar från att använda VPN.

Viktigt

Se till att Teams mediatrafik dirigeras via önskad metod i alla VPN-scenarier genom att se till att användarna kör Microsoft Teams-klientversion 1.3.00.13565 eller senare. Den här versionen innehåller förbättringar i hur klienten identifierar tillgängliga nätverkssökvägar.

Signaltrafik utförs via HTTPS och är inte lika svarstidskänslig som medietrafiken och markeras som Tillåt i URL/IP-data och kan därför dirigeras via VPN-klienten om så önskas.

Obs!

Microsoft Edge 96 och senare stöder även VPN-delade tunnlar för peer-to-peer-trafik. Det innebär att kunder kan dra nytta av VPN-delade tunnlar för Till exempel Teams-webbklienter på Edge. Kunder som vill konfigurera det för webbplatser som körs på Edge kan uppnå det genom att ta ytterligare ett steg för att inaktivera Edge WebRtcRespectOsRoutingTableEnabled-principen .

Säkerhet

Ett vanligt argument för att undvika delade tunnlar är att Det är mindre säkert att göra det, dvs. all trafik som inte går genom VPN-tunneln kommer inte att dra nytta av det krypteringsschema som tillämpas på VPN-tunneln och är därför mindre säker.

Huvudargumentet för detta är att medietrafiken redan är krypterad via SRTP (Secure Real-Time Transport Protocol), en profil för Real-Time Transport Protocol (RTP) som tillhandahåller konfidentialitet, autentisering och åter spela upp attackskydd för RTP-trafik. SRTP förlitar sig på en slumpmässigt genererad sessionsnyckel som utbyts via den TLS-skyddade signalkanalen. Detta beskrivs i detalj i den här säkerhetsguiden, men det primära avsnittet av intresse är mediekryptering.

Medietrafiken krypteras med hjälp av SRTP, som använder en sessionsnyckel som genereras av en säker slumptalsgenerator och utbyts med TLS-signalkanalen. Dessutom krypteras media som flödar i båda riktningarna mellan mediationsservern och dess interna nästa hopp med hjälp av SRTP.

Skype för företag Online genererar användarnamn/lösenord för säker åtkomst till mediereläer via Traversal Using Relays around NAT (TURN). Mediereläer utbyter användarnamnet/lösenordet via en TLS-skyddad SIP-kanal. Det är värt att notera att även om en VPN-tunnel kan användas för att ansluta klienten till företagsnätverket, måste trafiken fortfarande flöda i sitt SRTP-formulär när den lämnar företagsnätverket för att nå tjänsten.

Information om hur Teams åtgärdar vanliga säkerhetsproblem som röst- eller sessionsbläddringsverktyg för NAT-förstärkningsattacker (STUN) finns i 5.1 Säkerhetsöverväganden för implementerare.

Du kan också läsa om moderna säkerhetskontroller i fjärrarbetsscenarier på Alternativa sätt för säkerhetspersonal och IT att uppnå moderna säkerhetskontroller i dagens unika fjärrarbetsscenarier (Microsoft Security Team-bloggen).

Testning

När principen är på plats bör du bekräfta att den fungerar som förväntat. Det finns flera sätt att testa sökvägen är korrekt inställd på att använda den lokala Internetanslutningen:

  • Kör Microsoft 365-anslutningstestet som kör anslutningstester åt dig, inklusive spårningsvägar enligt ovan. Vi lägger också till VPN-tester i den här verktygsuppsättningen som också bör ge ytterligare insikter.

  • En enkel tracert till en slutpunkt inom omfånget för den delade tunneln bör visa sökvägen, till exempel:

    tracert worldaz.tr.teams.microsoft.com
    

    Du bör sedan se en sökväg via den lokala ISP:en till den här slutpunkten som ska matcha till en IP-adress i teams-intervallen som vi har konfigurerat för delade tunnlar.

  • Ta en nätverksfångst med hjälp av ett verktyg som Wireshark. Filtrera på UDP under ett anrop så bör du se trafik som flödar till en IP-adress i teams-optimeringsintervallet . Om VPN-tunneln används för den här trafiken visas inte medietrafiken i spårningen.

Ytterligare supportloggar

Om du behöver ytterligare data för att felsöka eller begär hjälp från Microsoft-supporten bör du snabbt hitta en lösning genom att hämta följande information. Microsoft-supportens TSS Windows CMD-baserade universella verktyg för felsökningsskript kan hjälpa dig att samla in relevanta loggar på ett enkelt sätt. Verktyget och instruktionerna för användning finns på https://aka.ms/TssTools.

Översikt: DELADE VPN-tunnlar för Microsoft 365

Implementera DELADE VPN-tunnlar för Microsoft 365

Vanliga scenarier med delade VPN-tunnlar för Microsoft 365

Särskilda överväganden för Stream- och livehändelser i VPN-miljöer

Microsoft 365-prestandaoptimering för kinesiska användare

Principer för nätverksanslutning i Microsoft 365

Utvärdera Microsoft 365 nätverksanslutningar

Nätverks- och prestandajustering för Microsoft 365

Alternativa sätt för säkerhetspersonal och IT att uppnå moderna säkerhetskontroller i dagens unika fjärrarbetsscenarier (Microsoft Security Team-bloggen)

Förbättra VPN-prestanda hos Microsoft: använda Windows 10 VPN-profiler för att tillåta automatiska anslutningar

Körs på VPN: Hur Microsoft håller sin fjärranslutna personal ansluten

Microsofts globala nätverk