Implementace rozděleného tunelového propojení VPN pro Microsoft 365

Článek
12/21/2023

Poznámka

Tento článek je součástí sady článků, které se týkají optimalizace Microsoftu 365 pro vzdálené uživatele.

Přehled použití rozděleného tunelového propojení VPN k optimalizaci připojení Microsoftu 365 pro vzdálené uživatele najdete v tématu Přehled: Dělené tunelové propojení VPN pro Microsoft 365.
Podrobný seznam scénářů rozděleného tunelového propojení VPN najdete v tématu Běžné scénáře rozděleného tunelového propojení VPN pro Microsoft 365.
Pokyny k zabezpečení provozu médií Teams v prostředích rozděleného tunelového propojení VPN najdete v tématu Zabezpečení provozu médií Teams pro rozdělené tunelování VPN.
Informace o tom, jak nakonfigurovat stream a živé události v prostředích VPN, najdete v tématu Zvláštní aspekty pro stream a živé události v prostředích VPN.
Informace o optimalizaci výkonu tenanta Microsoftu 365 po celém světě pro uživatele v Číně najdete v tématu Optimalizace výkonu Microsoftu 365 pro uživatele z Číny.

Doporučená strategie Microsoftu pro optimalizaci připojení vzdáleného pracovního procesu se zaměřuje na rychlé zmírnění problémů a zajištění vysokého výkonu pomocí několika jednoduchých kroků. Tímto postupem se upraví starší verze přístupu VPN pro několik definovaných koncových bodů, které obcházejí kritické servery VPN. V různých vrstvách je možné použít ekvivalentní nebo dokonce nadřazený model zabezpečení, aby se odstranila potřeba zabezpečit veškerý provoz při odchozím přenosu dat podnikové sítě. Ve většině případů je toho možné efektivně dosáhnout během několika hodin a pak je škálovatelný pro další úlohy podle požadavků a času.

Implementace rozděleného tunelového propojení VPN

V tomto článku najdete jednoduché kroky potřebné k migraci architektury klienta VPN z vynuceného tunelu VPN na vynucené tunelové propojení VPN s několika důvěryhodnými výjimkami, model rozděleného tunelu VPN č. 2 v tématu Běžné scénáře rozděleného tunelového propojení VPN pro Microsoft 365.

Následující diagram znázorňuje, jak funguje doporučené řešení rozděleného tunelu VPN:

Podrobnosti o řešení VPN rozděleného tunelu

1. Identifikace koncových bodů pro optimalizaci

V článku Adresy URL a rozsahy IP adres Microsoftu 365 Microsoft jasně identifikuje klíčové koncové body, které potřebujete k optimalizaci, a kategorizuje je jako Optimalizovat. V současné době je potřeba optimalizovat pouze čtyři adresy URL a 20 podsítí PROTOKOLU IP. Tato malá skupina koncových bodů představuje přibližně 70 až 80 % objemu přenosů do služby Microsoft 365, včetně koncových bodů citlivých na latenci, jako jsou koncové body pro média Teams. V podstatě se jedná o provoz, o který musíme věnovat zvláštní pozornost, a je to také provoz, který bude neuvěřitelně tlačit na tradiční síťové cesty a infrastrukturu VPN.

Adresy URL v této kategorii mají následující charakteristiky:

Jsou koncové body vlastněné a spravované microsoftem hostované v infrastruktuře Microsoftu?
Poskytnutí IP adres
Nízká míra změn a očekává se, že jejich počet zůstane malý (v současné době 20 podsítí IP)
Jsou citlivé na šířku pásma nebo latenci?
Můžou mít požadované prvky zabezpečení poskytované ve službě, nikoli v síti
70–80 % objemu provozu do služby Microsoft 365

Další informace o koncových bodech Microsoftu 365 a jejich kategorizaci a správě najdete v tématu Správa koncových bodů Microsoftu 365.

Optimalizace adres URL

Aktuální adresy URL pro optimalizaci najdete v následující tabulce. Ve většině případů byste měli v souboru PAC prohlížeče používat pouze koncové body adresy URL, kde jsou koncové body nakonfigurované tak, aby se odesílaly přímo, nikoli na proxy server.

Optimalizace adres URL	Port/protokol	Účel
https://outlook.office365.com	TCP 443	Toto je jedna z primárních adres URL, které Outlook používá pro připojení ke svému Exchange Online serveru a má velké využití šířky pásma a počet připojení. Nízká latence sítě je vyžadována pro online funkce, mezi které patří: okamžité vyhledávání, jiné kalendáře poštovní schránky, vyhledávání informací o volném čase, správa pravidel a upozornění, archiv Exchange Online, e-maily odcházející ze složky Pošta k odeslání.
https://outlook.office.com	TCP 443	Tato adresa URL se používá pro Outlook Online Web Access pro připojení k Exchange Online serveru a je citlivá na latenci sítě. Připojení se vyžaduje zejména pro nahrávání a stahování velkých souborů pomocí SharePointu Online.
`https://\<tenant\>.sharepoint.com`	TCP 443	Toto je primární adresa URL SharePointu Online s velkou šířkou pásma.
`https://\<tenant\>-my.sharepoint.com`	TCP 443	Toto je primární adresa URL pro OneDrive pro firmy a má vysoké využití šířky pásma a pravděpodobně vysoký počet připojení z nástroje OneDrive pro firmy Sync.
IP adresy médií teams (bez adresy URL)	UDP 3478, 3479, 3480 a 3481	Přidělení služby Relay Discovery a provoz v reálném čase Jedná se o koncové body používané pro Skype pro firmy a přenosy médií v Microsoft Teams (hovory, schůzky atd.). Většina koncových bodů se poskytuje, když klient Microsoft Teams naváže volání (a jsou obsaženy v požadovaných IP adresách uvedených pro službu). Pro optimální kvalitu médií je nutné použít protokol UDP.

Ve výše uvedených příkladech by se tenant měl nahradit názvem vašeho tenanta Microsoftu 365. Například contoso.onmicrosoft.com by použil contoso.sharepoint.com a contoso-my.sharepoint.com.

Optimalizace rozsahů IP adres

Rozsahy IP adres, kterým tyto koncové body odpovídají, jsou v době psaní následující. Důrazně doporučujeme použít skript, jako je tento příklad, webovou službu Microsoft 365 IP a URL nebo stránku URL/IP, abyste při použití konfigurace zkontrolovali případné aktualizace a zavedli zásady, které to budou pravidelně provádět. Pokud využíváte průběžné vyhodnocování přístupu, projděte si téma Varianta IP adresy průběžného vyhodnocování přístupu. Aby se zabránilo selhání bloků souvisejících s insufficient_claims nebo kontrolou okamžitého vynucování IP adres, může se vyžadovat směrování IP adres prostřednictvím důvěryhodné IP adresy nebo sítě VPN.

104.146.128.0/17
13.107.128.0/22
13.107.136.0/22
13.107.18.10/31
13.107.6.152/31
13.107.64.0/18
131.253.33.215/32
132.245.0.0/16
150.171.32.0/22
150.171.40.0/22
204.79.197.215/32
23.103.160.0/20
40.104.0.0/15
40.108.128.0/17
40.96.0.0/13
52.104.0.0/14
52.112.0.0/14
52.96.0.0/14
52.122.0.0/15

2. Optimalizace přístupu k těmto koncovým bodům prostřednictvím sítě VPN

Teď, když jsme identifikovali tyto kritické koncové body, musíme je odvést od tunelu VPN a umožnit jim používat místní internetové připojení uživatele pro připojení přímo ke službě. Způsob, jakým se toho dosáhne, se bude lišit v závislosti na použité platformě produktu VPN a počítače, ale většina řešení VPN umožní určitou jednoduchou konfiguraci zásad pro použití této logiky. Informace o rozdělených tunelech specifických pro danou platformu VPN najdete v průvodcích POSTUPY pro běžné platformy VPN.

Pokud chcete řešení otestovat ručně, můžete spuštěním následujícího příkladu PowerShellu emulovat řešení na úrovni směrovací tabulky. Tento příklad přidá trasu pro každou podsíť ip adres médií Teams do směrovací tabulky. Můžete otestovat výkon médií Teams před a po a sledovat rozdíly v trasách pro zadané koncové body.

Příklad: Přidání podsítí ip adres médií Teams do směrovací tabulky

$intIndex = "" # index of the interface connected to the internet
$gateway = "" # default gateway of that interface
$destPrefix = "52.120.0.0/14", "52.112.0.0/14", "13.107.64.0/18" # Teams Media endpoints
# Add routes to the route table
foreach ($prefix in $destPrefix) {New-NetRoute -DestinationPrefix $prefix -InterfaceIndex $intIndex -NextHop $gateway}

Ve výše uvedeném skriptu je $intIndex index rozhraní připojeného k internetu (najdete spuštěním rutiny get-netadapter v PowerShellu; vyhledejte hodnotu ifIndex) a $gateway je výchozí bránou tohoto rozhraní (najdete ji spuštěním příkazu ipconfig na příkazovém řádku nebo (Get-NetIPConfiguration | Foreach IPv4DefaultGateway). NextHop v PowerShellu).

Po přidání tras můžete ověřit správnost směrovací tabulky spuštěním příkazu route print na příkazovém řádku nebo v PowerShellu. Výstup by měl obsahovat trasy, které jste přidali, zobrazující index rozhraní (v tomto příkladu 22 ) a bránu pro toto rozhraní (v tomto příkladu 192.168.1.1 ):

Směrovat výstup tisku.

Pokud chcete přidat trasy pro všechny aktuální rozsahy IP adres v kategorii Optimalizovat, můžete použít následující variantu skriptu k dotazování webové služby Microsoft 365 IP a URL na aktuální sadu podsítí Optimalizovat ip adresy a přidat je do směrovací tabulky.

Příklad: Přidání všech podsítí optimalizace do směrovací tabulky

$intIndex = "" # index of the interface connected to the internet
$gateway = "" # default gateway of that interface
# Query the web service for IPs in the Optimize category
$ep = Invoke-RestMethod ("https://endpoints.office.com/endpoints/worldwide?clientrequestid=" + ([GUID]::NewGuid()).Guid)
# Output only IPv4 Optimize IPs to $optimizeIps
$destPrefix = $ep | where {$_.category -eq "Optimize"} | Select-Object -ExpandProperty ips | Where-Object { $_ -like '*.*' }
# Add routes to the route table
foreach ($prefix in $destPrefix) {New-NetRoute -DestinationPrefix $prefix -InterfaceIndex $intIndex -NextHop $gateway}

Pokud jste neúmyslně přidali trasy s nesprávnými parametry nebo chcete jednoduše vrátit změny, můžete trasy, které jste právě přidali, odebrat pomocí následujícího příkazu:

foreach ($prefix in $destPrefix) {Remove-NetRoute -DestinationPrefix $prefix -InterfaceIndex $intIndex -NextHop $gateway}

Klient VPN by měl být nakonfigurovaný tak, aby provoz na IP adresy Optimalizace byl směrován tímto způsobem. To umožňuje, aby provoz využíval místní prostředky Microsoftu, jako jsou front doory služeb Microsoftu 365 , jako je služba Azure Front Door , která poskytuje služby Microsoft 365 a koncové body připojení co nejblíže vašim uživatelům. To nám umožňuje poskytovat vysoké úrovně výkonu uživatelům bez ohledu na to, kde jsou na světě, a naplno využívat globální síť Microsoftu, která je pravděpodobně v řádu několika milisekund od přímého výchozího přenosu dat uživatelů.

Návody k používání běžných platforem VPN

Tato část obsahuje odkazy na podrobné průvodce implementací rozděleného tunelování pro provoz Microsoftu 365 od nejběžnějších partnerů v této oblasti. Jakmile budou k dispozici, přidáme další příručky.