Implementace ExpressRoute pro Microsoft 365
Tento článek se týká Microsoft 365 Enterprise.
ExpressRoute pro Microsoft 365 poskytuje alternativní cestu směrování k mnoha internetovým službám Microsoft 365. Architektura ExpressRoute pro Microsoft 365 je založená na inzerování předpon veřejných IP adres služeb Microsoftu 365, které už jsou přístupné přes internet, do zřízených okruhů ExpressRoute, aby se tyto předpony IP adres následně redistribuovaly do vaší sítě. S ExpressRoute efektivně povolíte několik různých cest směrování, přes internet a ExpressRoute, pro mnoho služeb Microsoft 365. Tento stav směrování v síti může představovat významnou změnu způsobu návrhu interní síťové topologie.
Poznámka
ExpressRoute pro Microsoft 365 nedoporučujeme , protože ve většině případů neposkytuje nejlepší model připojení pro službu. Proto se k použití tohoto modelu připojení vyžaduje autorizace Microsoftu. Kontrolujeme každou žádost zákazníka a autorizujeme ExpressRoute pro Microsoft 365 pouze ve výjimečných situacích, kdy je to nezbytné. Přečtěte si prosím příručku ExpressRoute pro Microsoft 365 , kde najdete další informace a po komplexní kontrole dokumentu se svými týmy pro produktivitu, síť a zabezpečení ve spolupráci s týmem účtu Microsoft odešlete v případě potřeby výjimku. Neautorizovaným předplatným, která se pokoušejí vytvořit filtry tras pro Microsoft 365, se zobrazí chybová zpráva.
Musíte pečlivě naplánovat implementaci ExpressRoute pro Microsoft 365 tak, aby vyhovovala složitosti sítě, která je dostupná prostřednictvím vyhrazeného okruhu s trasami vloženými do vaší základní sítě i internetu. Pokud vy a váš tým neprovádíte podrobné plánování a testování v této příručce, existuje vysoké riziko, že při povolení okruhu ExpressRoute dojde k přerušované nebo úplné ztrátě připojení ke službám Microsoftu 365.
Pokud chcete mít úspěšnou implementaci, budete muset analyzovat požadavky na infrastrukturu, projít si podrobné posouzení a návrh sítě, pečlivě naplánovat zavedení postupně a kontrolovaně a sestavit podrobný plán ověřování a testování. U rozsáhlých distribuovaných prostředí není neobvyklé, že implementace trvají několik měsíců. Tato příručka je navržená tak, aby vám pomohla plánovat dopředu.
Plánování velkých úspěšných nasazení může trvat šest měsíců a často zahrnuje členy týmu z mnoha oblastí v organizaci, včetně sítí, správců brány firewall a proxy serverů, správců Microsoftu 365, zabezpečení, podpory koncových uživatelů, řízení projektů a sponzorství pro vedoucí pracovníky. Vaše investice do procesu plánování sníží pravděpodobnost, že dojde k selhání nasazení, které způsobí výpadky nebo složité a nákladné řešení potíží.
Před spuštěním tohoto průvodce implementací očekáváme splnění následujících požadavků.
Dokončili jste posouzení sítě, abyste zjistili, jestli je ExpressRoute doporučený a schválený.
Vybrali jste poskytovatele síťových služeb ExpressRoute. Tady najdete podrobnosti o partnerech ExpressRoute a umístěních peeringu.
Už jste si přečetli dokumentaci k ExpressRoute a rozumíte jí a vaše interní síť dokáže splňovat komplexní požadavky ExpressRoute.
Váš tým si přečetl všechny veřejné pokyny a dokumentaci na webu https://aka.ms/expressrouteoffice365https://aka.ms/erta sledoval sérii školení Azure ExpressRoute pro Microsoft 365 na Kanálu 9, aby získal přehled o důležitých technických podrobnostech, mezi které patří:
Internetové závislosti služeb SaaS
Jak se vyhnout asymetrickým trasám a zpracovávat složité směrování.
Jak začlenit zabezpečení hraniční sítě, dostupnost a řízení na úrovni aplikace.
Začněte tím, že shromáždíte požadavky.
Začněte tím, že určíte, které funkce a služby plánujete v organizaci přijmout. Musíte určit, které funkce různých služeb Microsoft 365 se budou používat a která umístění ve vaší síti budou hostovat uživatele, kteří tyto funkce používají. V katalogu scénářů musíte přidat síťové atributy, které každý z těchto scénářů vyžaduje. například příchozí a odchozí toky síťového provozu a jestli jsou koncové body Microsoftu 365 dostupné přes ExpressRoute nebo ne.
Shromáždění požadavků vaší organizace:
Katalogujte příchozí a odchozí síťový provoz pro služby Microsoft 365, které vaše organizace používá. Popis toků, které vyžadují různé scénáře Microsoftu 365, najdete na stránce Adresy URL a rozsahy IP adres Microsoftu 365.
Shromážděte dokumentaci ke stávající topologii sítě, která obsahuje podrobnosti o interní páteřní síti WAN a topologii, připojení satelitních lokalit, připojení uživatelů na poslední míli, směrování do hraničních výstupních bodů sítě a proxy služby.
Identifikujte příchozí koncové body služeb v diagramech sítě, ke kterým se bude Microsoft 365 a další služby Microsoftu připojovat, a zobrazte internetové i navrhované cesty připojení ExpressRoute.
Identifikujte všechna umístění geografických uživatelů a připojení wan mezi umístěními spolu s umístěními, která umístění mají aktuálně výchozí přenos dat na internet a která umístění jsou navržená pro výchozí přenos dat do umístění partnerského vztahu ExpressRoute.
Identifikujte všechna hraniční zařízení, jako jsou proxy servery, brány firewall atd., a katalogujte jejich vztah k tokům přes internet a ExpressRoute.
Zdokumentujte, jestli budou koncoví uživatelé přistupovat ke službám Microsoftu 365 prostřednictvím přímého směrování nebo proxy nepřímých aplikací pro internetové toky i toky ExpressRoute.
Přidejte do diagramu sítě umístění vašeho tenanta a umístění meet-me.
Odhad očekávaných a pozorovaných charakteristik výkonu a latence sítě z hlavních uživatelských umístění do Microsoftu 365. Mějte na paměti, že Microsoft 365 je globální a distribuovaná sada služeb a uživatelé se budou připojovat k umístěním, která se můžou lišit od umístění jejich tenanta. Z tohoto důvodu doporučujeme měřit a optimalizovat latenci mezi uživatelem a nejbližší hraniční sítí Microsoftu přes ExpressRoute a připojení k internetu. K tomuto úkolu můžete využít své poznatky z hodnocení sítě.
Uveďte požadavky na zabezpečení podnikové sítě a vysokou dostupnost, které je potřeba splnit s novým připojením ExpressRoute. Například jak uživatelé dál získají přístup k Microsoftu 365 v případě selhání odchozího přenosu dat z internetu nebo selhání okruhu ExpressRoute.
Zdokumentujte, které příchozí a odchozí síťové toky Microsoftu 365 budou používat internetovou cestu a které budou používat ExpressRoute. Specifika geografických umístění vašich uživatelů a podrobnosti o místní síťové topologii můžou vyžadovat, aby se plán v jednotlivých umístěních uživatelů lišit.
Katalogujte odchozí a příchozí síťový provoz.
Pokud chcete minimalizovat směrování a další složitosti sítě, doporučujeme používat ExpressRoute pro Microsoft 365 pouze pro toky síťového provozu, které se vyžadují přes vyhrazené připojení kvůli zákonným požadavkům nebo jako výsledek posouzení sítě. Dále doporučujeme připravit rozsah směrování ExpressRoute a přistupovat k odchozím a příchozím tokům síťového provozu jako k různým a odlišným fázím projektu implementace. Nasazení ExpressRoute pro Microsoft 365 pouze pro odchozí toky síťového provozu iniciované uživatelem a ponechání příchozích síťových přenosů přes internet vám můžou pomoct řídit nárůst topologické složitosti a rizika spojená se zavedením dalších možností asymetrického směrování.
Katalog síťových přenosů by měl obsahovat seznam všech příchozích a odchozích síťových připojení, která budete mít mezi místní sítí a Microsoftem.
Toky odchozího síťového provozu jsou všechny scénáře, ve kterých se připojení iniciuje z místního prostředí, například z interních klientů nebo serverů, s cílem služeb Microsoftu. Tato připojení můžou být přímá k Microsoftu 365 nebo nepřímá, například když připojení prochází přes proxy servery, brány firewall nebo jiná síťová zařízení na cestě k Microsoftu 365.
Toky příchozího síťového provozu jsou všechny scénáře, ve kterých se iniciuje připojení z cloudu Microsoftu k místnímu hostiteli. Tato připojení obvykle musí projít bránou firewall a další infrastrukturou zabezpečení, kterou zásady zabezpečení zákazníka vyžadují pro externí toky.
Přečtěte si část Zajištění symetrie tras , kde zjistíte, které služby budou posílat příchozí provoz, a vyhledejte sloupec s označením ExpressRoute pro Microsoft 365 v referenčním článku o koncových bodech Microsoftu 365 , kde zjistíte zbývající informace o připojení.
Pro každou službu, která vyžaduje odchozí připojení, budete chtít popsat plánované připojení služby, včetně síťového směrování, konfigurace proxy serveru, kontroly paketů a požadavků na šířku pásma.
Pro každou službu, která vyžaduje příchozí připojení, budete potřebovat nějaké další informace. Servery v cloudu Microsoftu naváže připojení k vaší místní síti. Abyste měli jistotu, že se připojení navazují správně, budete chtít popsat všechny aspekty tohoto připojení, včetně: veřejné záznamy DNS pro služby, které budou přijímat tato příchozí připojení, IP adresy IPv4 ve formátu CIDR, které vybavení poskytovatele internetových služeb se týká, a způsob zpracování příchozího překladu adres (NAT) nebo zdrojového překladu adres (NAT) pro tato připojení.
Příchozí připojení by se měla kontrolovat bez ohledu na to, jestli se připojují přes internet nebo ExpressRoute, aby se zajistilo, že se nezavádí asymetrické směrování. V některých případech můžou místní koncové body, ke kterým služby Microsoftu 365 inicializovaly příchozí připojení, potřebovat přístup i jiné služby microsoftu a jiných služeb. Je nanejvýš důležité, aby povolení směrování ExpressRoute do těchto služeb pro účely Microsoftu 365 nenarušil jiné scénáře. V mnoha případech můžou zákazníci potřebovat implementovat konkrétní změny ve své interní síti, jako je překlad adres (NAT) založený na zdroji, aby zajistili, že příchozí toky z Microsoftu zůstanou po povolení ExpressRoute symetrické.
Tady je ukázka požadované úrovně podrobností. V tomto případě by Exchange Hybrid směroval do místního systému přes ExpressRoute.
| Vlastnost Připojení | Hodnota |
|---|---|
| Směr síťového provozu |
Příchozí |
| Služba |
Hybridní nasazení Exchange |
| Veřejný koncový bod Microsoftu 365 (zdroj) |
Exchange Online (IP adresy) |
| Veřejný místní koncový bod (cíl) |
5.5.5.5 |
| Veřejná (internetová) položka DNS |
Autodiscover.contoso.com |
| Budou tento místní koncový bod používat pro jiné (jiné než Microsoft 365) služby Microsoftu? |
Ne |
| Budou tento místní koncový bod používat uživatelé nebo systémy na internetu? |
Ano |
| Interní systémy publikované prostřednictvím veřejných koncových bodů |
Exchange Server role klientského přístupu (místní) 192.168.101, 192.168.102, 192.168.103 |
| Inzerování PROTOKOLU IP veřejného koncového bodu |
Na internet: 5.5.0.0/16 Do ExpressRoute: 5.5.5.0/24 |
| Zabezpečení / hraniční kontroly |
Internetová cesta: DeviceID_002 cesta ExpressRoute: DeviceID_003 |
| Vysoká dostupnost |
Aktivní/aktivní napříč 2 geograficky redundantními okruhy / okruhy ExpressRoute – Chicago a Dallas |
| Řízení symetrie cesty |
Metoda: Zdrojová internetová cesta PŘEKLADU ADRES: Příchozí připojení zdrojového překladu adres (NAT) k 192.168.5.5 ExpressRoute: Připojení zdrojového překladu adres (NAT) k 192.168.1.0 (Chicago) a 192.168.2.0 (Dallas) |
Tady je ukázka služby, která je jenom odchozí:
| Vlastnost Připojení | Hodnota |
|---|---|
| Směr síťového provozu |
Odchozí |
| Služba |
SharePoint |
| Místní koncový bod (zdroj) |
Uživatelská pracovní stanice |
| Veřejný koncový bod Microsoftu 365 (cíl) |
SharePoint (IP adresy) |
| Veřejná (internetová) položka DNS |
*.sharepoint.com (a více plně kvalifikovaných názvů domén) |
| Referenční seznamy CDN |
cdn.sharepointonline.com (a další plně kvalifikované názvy domén) – IP adresy spravované poskytovateli CDN) |
| Inzerce PROTOKOLU IP a použití překladu adres (NAT) |
Internetová cesta/zdrojový překlad adres (NAT): 1.1.1.0/24 Cesta ExpressRoute / zdrojový překlad adres (NAT): 1.1.2.0/24 (Chicago) a 1.1.3.0/24 (Dallas) |
| Metoda připojení |
Internet: přes proxy server vrstvy 7 (soubor .pac) ExpressRoute: Přímé směrování (bez proxy serveru) |
| Zabezpečení / hraniční kontroly |
Cesta k internetu: DeviceID_002 Cesta ExpressRoute: DeviceID_003 |
| Vysoká dostupnost |
Internetová cesta: Redundantní výchozí přenos dat z internetu Cesta ExpressRoute: Aktivní/aktivní směrování horkým bramborem přes 2 geograficky redundantní okruhy ExpressRoute – Chicago a Dallas |
| Řízení symetrie cesty |
Metoda: Zdrojový překlad adres (NAT) pro všechna připojení |
Návrh síťové topologie s regionálním připojením
Jakmile porozumíte službám a jejich přidruženým tokům síťového provozu, můžete vytvořit diagram sítě, který bude zahrnovat tyto nové požadavky na připojení a znázorní změny, které provedete při používání ExpressRoute pro Microsoft 365. Diagram by měl obsahovat:
Všechna uživatelská umístění, ze kterých bude Microsoft 365 a další služby přístupné.
Všechny výchozí body internetu a ExpressRoute
Všechna odchozí a příchozí zařízení, která spravují připojení v síti a z této sítě, včetně směrovačů, bran firewall, proxy serverů aplikací a detekce/prevence neoprávněných vniknutí.
Interní cíle pro veškerý příchozí provoz, jako jsou interní servery ADFS, které přijímají připojení z proxy serverů webových aplikací ADFS.
Katalog všech podsítí PROTOKOLU IP, které se budou inzerovat
Identifikujte všechna místa, ze kterých budou lidé přistupovat k Microsoftu 365, a uveďte umístění meet-me, která se budou používat pro ExpressRoute.
Umístění a části interní síťové topologie, ve kterých se budou přijímat, filtrovat a šířit předpony IP adres Microsoftu získané z ExpressRoute.
Síťová topologie by měla ilustrovat zeměpisné umístění jednotlivých segmentů sítě a způsob připojení k síti Microsoftu přes ExpressRoute nebo internet.
Následující diagram znázorňuje všechna místa, ze kterých budou uživatelé používat Microsoft 365, a také inzerování příchozích a odchozích směrování do Microsoftu 365.
V případě odchozího provozu uživatelé přistupují k Microsoftu 365 jedním ze tří způsobů:
Prostřednictvím místa setkání v Severní Amerika pro lidi v Kalifornii.
Prostřednictvím místa setkání-me v Hongkongu Zvláštní administrativní oblast pro lidi v Hongkongu SAR.
Prostřednictvím internetu v Bangladéši, kde je méně lidí a není zřízený žádný okruh ExpressRoute.
Podobně příchozí síťový provoz z Microsoftu 365 vrací jedním ze tří způsobů:
Prostřednictvím místa setkání v Severní Amerika pro lidi v Kalifornii.
Prostřednictvím místa setkání-me v Hongkongu Zvláštní administrativní oblast pro lidi v Hongkongu SAR.
Prostřednictvím internetu v Bangladéši, kde je méně lidí a není zřízený žádný okruh ExpressRoute.
Určení vhodného umístění meet-me
Výběr umístění meet-me, což jsou fyzické umístění, kde váš okruh ExpressRoute připojuje vaši síť k síti Microsoftu, je ovlivněn umístěními, ze kterých budou lidé přistupovat k Microsoftu 365. Jako nabídka SaaS nefunguje Microsoft 365 v rámci regionálního modelu IaaS nebo PaaS stejným způsobem jako Azure. Místo toho je Microsoft 365 distribuovanou sadou služeb pro spolupráci, ve kterých se uživatelé můžou muset připojit ke koncovým bodům napříč několika datovými centry a oblastmi, které nemusí být nutně ve stejném umístění nebo oblasti, kde je hostovaný tenant uživatele.
To znamená, že nejdůležitější, co musíte vzít v úvahu při výběru umístění meet-me pro ExpressRoute pro Microsoft 365, je to, odkud se budou lidé ve vaší organizaci připojovat. Obecným doporučením pro optimální připojení k Microsoftu 365 je implementovat směrování, aby se žádosti uživatelů na služby Microsoftu 365 předávaly do sítě Microsoftu přes nejkratší síťovou cestu, což se také často označuje jako směrování s horkým bramborem. Pokud je například většina uživatelů Microsoftu 365 na jednom nebo dvou místech, výběrem umístění meet-me, která jsou v nejbližší blízkosti umístění těchto uživatelů, vytvoříte optimální návrh. Pokud má vaše společnost velké uživatelské populace v mnoha různých oblastech, můžete zvážit více okruhů ExpressRoute a umístění meet-me. U některých umístění uživatelů nemusí být nejkratší nebo nejoptimálnější cesta k síti Microsoftu a Microsoftu 365 přes interní body wan a ExpressRoute meet-me, ale přes internet.
Často existuje několik umístění meet-me, která se dají vybrat v rámci oblasti s relativní blízkostí vašich uživatelů. Vyplňte následující tabulku, která vám pomůže při rozhodování.
Plánovaná místa schůzky ExpressRoute v Kalifornii a New Yorku
| Umístění |
Počet osob |
Očekávaná latence odchozího přenosu dat sítě Microsoft přes internet |
Očekávaná latence sítě Microsoftu přes ExpressRoute |
|---|---|---|---|
| Los Angeles |
10,000 |
~15ms |
~10ms (přes Silicon Valley) |
| Washington DC |
15,000 |
~20ms |
~10ms (přes New York) |
| Dallas |
5,000 |
~15ms |
~40ms (přes New York) |
Jakmile se vytvoří globální síťová architektura zobrazující oblast Microsoftu 365, poskytovatel síťových služeb ExpressRoute se seznamuje s umístěními a počet lidí podle umístění, můžete ji použít k identifikaci, jestli je možné provést nějaké optimalizace. Může také zobrazit globální připojení k síti, kde provoz směruje do vzdáleného místa, aby bylo možné získat umístění meet-me. Pokud zjistíte vlásek v globální síti, měli byste ho před pokračováním napravit. Buď najděte jiné místo, kde se setkáte, nebo použijte selektivní internetové výstupní body, abyste se vyhnuli vlásku.
První diagram znázorňuje příklad zákazníka se dvěma fyzickými umístěními v Severní Amerika. Můžete se podívat na informace o umístěních kanceláří, umístěních tenantů Microsoftu 365 a několika možnostech pro umístění expressroute meet-me. V tomto příkladu zákazník vybral umístění meet-me na základě dvou principů, v tomto pořadí:
Nejbližší blízkost lidí v organizaci.
Nejblíže k datovému centru Microsoftu, kde je hostovaný Microsoft 365.
Druhý diagram tento koncept trochu rozšiřuje a ukazuje příklad zákazníka s více národními státy, který se potýká s podobnými informacemi a rozhodováním. Tento zákazník má malou kancelář v Bangladéši s pouze malým týmem 10 lidí, kteří se zaměřují na růst své stopy v regionu. V Čennai je místo schůzky a datové centrum Microsoftu s Microsoftem 365 hostovaným v Čennaí, takže by místo setkání dávalo smysl. nicméně, pro 10 lidí, výdaje na dodatečný okruh jsou zatěžující. Při pohledu na vaši síť budete muset zjistit, jestli je latence související s odesíláním síťového provozu přes vaši síť efektivnější než vynaložení kapitálu na získání dalšího okruhu ExpressRoute.
Nebo 10 lidí v Bangladéši může dosáhnout lepšího výkonu se síťovým provozem odesílaným přes internet do sítě Microsoft, než by směrovali do své interní sítě, jak jsme si ukázali v úvodních diagramech a reprodukovali níže.
Create plánu implementace ExpressRoute pro Microsoft 365
Plán implementace by měl zahrnovat technické podrobnosti o konfiguraci ExpressRoute i podrobnosti o konfiguraci veškeré další infrastruktury ve vaší síti, například následující.
Naplánujte, které služby jsou rozdělené mezi ExpressRoute a Internet.
Naplánujte šířku pásma, zabezpečení, vysokou dostupnost a převzetí služeb při selhání.
Návrh příchozího a odchozího směrování, včetně optimalizace správných cest směrování pro různá umístění
Rozhodněte, jak daleko budou trasy ExpressRoute inzerovány do vaší sítě a jaký je mechanismus, jakým klienti můžou vybrat internet nebo cestu ExpressRoute. například přímé směrování nebo proxy aplikace.
Naplánujte změny záznamů DNS, včetně položek architektury zásad odesílatele .
Plánování strategie překladu adres (NAT) včetně odchozích a příchozích zdrojových překladů adres (NAT).
Plánování směrování s využitím internetových i síťových cest ExpressRoute
Pro počáteční nasazení se všem příchozím službám, jako je příchozí e-mail nebo hybridní připojení, doporučuje používat internet.
Naplánujte směrování sítě LAN koncového uživatele, jako je konfigurace souboru PAC/WPAD, výchozí trasy, proxy serverů a inzerování tras protokolu BGP.
Naplánujte směrování hraniční sítě, včetně proxy serverů, bran firewall a cloudových proxy serverů.
Plánování šířky pásma, zabezpečení, vysoké dostupnosti a převzetí služeb při selhání
Create plán šířky pásma vyžadovaný pro každou hlavní úlohu Microsoftu 365. Samostatně odhadněte požadavky na šířku pásma Exchange Online, SharePointu a Skype pro firmy Online. Jako výchozí místo můžete použít kalkulačky odhadu, které jsme poskytli pro Exchange Online a Skype pro firmy. K úplnému pochopení požadavků vaší organizace na šířku pásma je ale nutný pilotní test s reprezentativním vzorkem profilů a umístění uživatelů.
Přidejte do svého plánu způsob, jakým se zpracovává zabezpečení v každém internetu a výchozích umístěních ExpressRoute. Mějte na paměti, že všechna připojení ExpressRoute k Microsoftu 365 používají veřejný partnerský vztah a musí být stále zabezpečená v souladu se zásadami zabezpečení vaší společnosti pro připojení k externím sítím.
Přidejte do plánu podrobnosti o tom, kteří lidé budou ovlivněni typem výpadku a jak budou moct co nejjednodušším způsobem provádět svou práci při plné kapacitě.
Plánování požadavků na šířku pásma, včetně Skype pro firmy požadavků na jitter, latenci, zahlcení a prostor pro hlavu
Skype pro firmy Online má také specifické dodatečné požadavky na síť, které jsou podrobně popsány v článku Kvalita médií a výkon připojení k síti v Skype pro firmy Online.
Přečtěte si část Plánování šířky pásma pro Azure ExpressRoute. Při vyhodnocování šířky pásma s pilotními uživateli můžete využít našeho průvodce laděním výkonu Microsoftu 365 pomocí směrných plánů a historie výkonu.
Plánování požadavků na vysokou dostupnost
Create plán vysoké dostupnosti, který bude vyhovovat vašim potřebám, a začlenit ho do aktualizovaného diagramu síťové topologie. Přečtěte si část Vysoká dostupnost a převzetí služeb při selhání pomocí Azure ExpressRoute.
Plánování požadavků na zabezpečení sítě
Create plán pro splnění požadavků na zabezpečení sítě a začlenit ho do aktualizovaného diagramu síťové topologie. Přečtěte si část Použití kontrolních mechanismů zabezpečení v Azure ExpressRoute pro scénáře Microsoftu 365.
Návrh připojení odchozích služeb
ExpressRoute pro Microsoft 365 má požadavky na odchozí síť, které nemusí být neznámé. Konkrétně IP adresy, které představují vaše uživatele a sítě pro Microsoft 365 a fungují jako zdrojové koncové body pro odchozí síťová připojení k Microsoftu, musí splňovat konkrétní požadavky uvedené níže.
Koncové body musí být veřejné IP adresy zaregistrované pro vaši společnost nebo operátora, který vám poskytuje připojení ExpressRoute.
Koncové body musí být inzerované Microsoftu a služba ExpressRoute je musí ověřit nebo přijmout.
Koncové body nesmí být inzerovány na internetu se stejnou nebo více upřednostňovanou metrikou směrování.
Koncové body se nesmí používat pro připojení ke službám Microsoftu, které nejsou nakonfigurované přes ExpressRoute.
Pokud návrh vaší sítě tyto požadavky nesplňuje, existuje vysoké riziko, že uživatelé budou mít problémy s připojením k Microsoftu 365 a dalším službám Microsoftu kvůli černému směrování trasy nebo asymetrickému směrování. K tomu dochází, když jsou požadavky na služby Microsoftu směrovány přes ExpressRoute, ale odpovědi se směrují zpět přes internet nebo naopak a odpovědi zahodí stavová síťová zařízení, jako jsou brány firewall.
Nejběžnější metodou, kterou můžete použít ke splnění výše uvedených požadavků, je použití zdrojového překladu adres (NAT) implementovaného jako součásti sítě nebo poskytovaného operátorem ExpressRoute. Zdrojový překlad adres (NAT) umožňuje abstrakci podrobností a privátních IP adres vaší internetové sítě z ExpressRoute a; spolu se správnými inzerovanými trasami IP poskytují snadný mechanismus pro zajištění symetrie cest. Pokud používáte stavová síťová zařízení, která jsou specifická pro umístění partnerského vztahu ExpressRoute, musíte pro každý partnerský vztah ExpressRoute implementovat samostatné fondy překladu adres (NAT), abyste zajistili symetrii cest.
Přečtěte si další informace o požadavcích na překlad adres (NAT) ExpressRoute.
Přidejte změny pro odchozí připojení do diagramu síťové topologie.
Návrh připojení příchozích služeb
Většina podnikových nasazení Microsoftu 365 předpokládá určitou formu příchozího připojení z Microsoftu 365 k místním službám, například pro Exchange, SharePoint a Skype pro firmy hybridní scénáře, migrace poštovních schránek a ověřování pomocí infrastruktury ADFS. Pokud ExpressRoute povolíte další cestu směrování mezi vaší místní sítí a Microsoftem pro odchozí připojení, může na tato příchozí připojení nechtěně dojít k ovlivnění asymetrickým směrováním, a to i v případě, že chcete, aby tyto toky dál používaly internet. Doporučujeme několik níže popsaných opatření, která zajistí, že nebudou mít vliv na příchozí internetové toky z Microsoftu 365 do místních systémů.
Aby se minimalizovala rizika asymetrického směrování příchozích síťových přenosů, všechna příchozí připojení by měla před směrováním do segmentů vaší sítě, které mají přehled o směrování do ExpressRoute, používat zdrojový překlad adres (NAT). Pokud jsou příchozí připojení povolená do segmentu sítě s viditelností směrování do ExpressRoute bez zdrojového překladu adres (NAT), požadavky pocházející z Microsoftu 365 budou zadávat z internetu, ale odpověď, která se vrátí do Microsoftu 365, bude upřednostňovat síťovou cestu ExpressRoute zpět do sítě Microsoftu, což způsobí asymetrické směrování.
Pro splnění tohoto požadavku můžete zvážit jeden z následujících způsobů implementace:
Před směrováním požadavků do interní sítě pomocí síťového vybavení, jako jsou brány firewall nebo nástroje pro vyrovnávání zatížení na cestě z internetu do místních systémů, proveďte zdrojový překlad adres (NAT).
Ujistěte se, že trasy ExpressRoute nejsou šířené do segmentů sítě, ve kterých se nacházejí příchozí služby, jako jsou front-end servery nebo reverzní proxy systémy, které zpracovávají připojení k internetu.
Explicitní zohlednění těchto scénářů ve vaší síti a zachování všech příchozích toků síťového provozu přes internet pomáhá minimalizovat nasazení a provozní riziko asymetrického směrování.
Můžou nastat případy, kdy se můžete rozhodnout přesměrovat některé příchozí toky přes připojení ExpressRoute. V těchto scénářích vezměte v úvahu následující dodatečné aspekty.
Microsoft 365 může cílit jenom na místní koncové body, které používají veřejné IP adresy. To znamená, že i když je místní příchozí koncový bod vystavený jenom Microsoftu 365 přes ExpressRoute, musí mít přidruženou veřejnou IP adresu.
Všechny překlady názvů DNS, které služby Microsoftu 365 provádějí při překladu místních koncových bodů, se provádějí pomocí veřejného DNS. To znamená, že musíte zaregistrovat plně kvalifikovaný název domény příchozích koncových bodů služby pro mapování IP adres na internetu.
Aby bylo možné přijímat příchozí síťová připojení přes ExpressRoute, musí být podsítě veřejných IP adres pro tyto koncové body inzerovány Microsoftu přes ExpressRoute.
Pečlivě vyhodnoťte tyto příchozí toky síťového provozu, abyste zajistili, že se na ně použijí správné kontroly zabezpečení a sítě v souladu se zásadami zabezpečení a sítě vaší společnosti.
Jakmile se vaše místní příchozí koncové body inzerují Microsoftu přes ExpressRoute, ExpressRoute se stane upřednostňovanou cestou směrování k těmto koncovým bodům pro všechny služby Microsoftu, včetně Microsoftu 365. To znamená, že tyto podsítě koncových bodů se musí používat jenom pro komunikaci se službami Microsoftu 365 a s žádnými dalšími službami v síti Microsoftu. Jinak návrh způsobí asymetrické směrování, kdy příchozí připojení z jiných služeb Microsoftu preferují příchozí směrování přes ExpressRoute, zatímco návratová cesta bude používat internet.
V případě, že je okruh ExpressRoute nebo umístění meet-me mimo provoz, budete muset zajistit, aby místní příchozí koncové body byly stále dostupné pro příjem požadavků přes samostatnou síťovou cestu. To může znamenat inzerování podsítí pro tyto koncové body prostřednictvím několika okruhů ExpressRoute.
Doporučujeme použít zdrojový překlad adres (NAT) pro všechny příchozí toky síťového provozu vstupující do vaší sítě prostřednictvím ExpressRoute, zejména v případě, že tyto toky procházejí stavovými síťovými zařízeními, jako jsou brány firewall.
Některé místní služby, jako je proxy server ADFS nebo automatická konfigurace Exchange, můžou přijímat příchozí požadavky od služeb Microsoftu 365 i uživatelů z internetu. U těchto požadavků bude Microsoft 365 cílit na stejný plně kvalifikovaný název domény jako požadavky uživatelů přes internet. Povolení příchozích uživatelských připojení z internetu k těmto místním koncovým bodům a vynucení připojení Microsoft 365, aby používala ExpressRoute, představuje značnou složitost směrování. Pro velkou většinu zákazníků se kvůli provozním aspektům nedoporučuje implementace takových složitých scénářů přes ExpressRoute. Tato další režie zahrnuje správu rizik asymetrického směrování a bude vyžadovat, abyste pečlivě spravovali inzerování směrování a zásady napříč více dimenzemi.
Aktualizujte plán síťové topologie tak, abyste ukázali, jak byste se vyhnuli asymetrickým trasám.
Chcete se vyhnout asymetrickému směrování, abyste zajistili, že lidé ve vaší organizaci budou moct bez problémů používat Microsoft 365 a další důležité služby na internetu. Existují dvě běžné konfigurace, které zákazníci mají a které způsobují asymetrické směrování. Teď je vhodný čas zkontrolovat konfiguraci sítě, kterou plánujete použít, a zkontrolovat, jestli může existovat některý z těchto scénářů asymetrického směrování.
Nejprve prozkoumáme několik různých situací spojených s následujícím diagramem sítě. V tomto diagramu jsou všechny servery, které přijímají příchozí požadavky, například ADFS nebo místní hybridní servery, v datacentru v New Jersey a inzerují se na internetu.
I když je hraniční síť zabezpečená, pro příchozí požadavky není k dispozici žádný zdrojový překlad adres (NAT).
Na serverech v datovém centru v New Jersey se zobrazují internetové trasy i trasy ExpressRoute.
Máme také návrhy, jak je opravit.
Problém 1: Připojení z cloudu k místnímu prostředí přes internet
Následující diagram znázorňuje asymetrickou síťovou cestu, která se používá v případě, že konfigurace sítě neposkytuje překlad adres (NAT) pro příchozí požadavky z cloudu Microsoftu přes internet.
Příchozí požadavek z Microsoftu 365 načte IP adresu místního koncového bodu z veřejného DNS a odešle požadavek do vaší hraniční sítě.
V této chybné konfiguraci není v hraniční síti, kam se provoz odesílá, nakonfigurovaný ani dostupný žádný zdrojový překlad adres (NAT), což vede k tomu, že se jako cíl pro vrácení použije skutečná zdrojová IP adresa.
Server ve vaší síti směruje zpětný provoz do Microsoftu 365 přes jakékoli dostupné síťové připojení ExpressRoute.
Výsledkem je asymetrická cesta pro tento tok do Microsoftu 365, což vede k přerušení připojení.
Řešení 1a: Zdrojový překlad adres (NAT)
Jednoduše přidáním zdrojového překladu adres (NAT) do příchozího požadavku se tato chybně nakonfigurovaná síť vyřeší. V tomto diagramu:
Příchozí požadavek bude dál zadávat přes hraniční síť datacentra v New Jersey. Tentokrát je k dispozici zdrojový překlad adres (NAT).
Odpověď ze serveru se směruje zpět na IP adresu přidruženou ke zdrojovému překladu adres (NAT) místo k původní IP adrese, což vede k tomu, že se odpověď vrátí ve stejné síťové cestě.
Řešení 1b: Vymezení rozsahu trasy
Případně můžete nepovolit inzerování předpon protokolu BGP ExpressRoute a odebrat alternativní síťovou cestu pro tyto počítače. V tomto diagramu:
Příchozí požadavek bude dál zadávat přes hraniční síť datacentra v New Jersey. Tentokrát nejsou předpony inzerované od Microsoftu přes okruh ExpressRoute dostupné pro datové centrum v New Jersey.
Odpověď ze serveru se směruje zpět na IP adresu přidruženou k původní IP adrese přes jedinou dostupnou trasu, což vede k tomu, že se odpověď vrátí po stejné síťové cestě.
Problém 2: Připojení z cloudu k místnímu prostředí přes ExpressRoute
Následující diagram znázorňuje asymetrickou síťovou cestu, která se použije v případě, že konfigurace sítě neposkytuje překlad adres (NAT) pro příchozí požadavky z cloudu Microsoftu přes ExpressRoute.
Příchozí požadavek z Microsoftu 365 načte IP adresu z DNS a odešle požadavek do vaší hraniční sítě.
V této chybné konfiguraci není v hraniční síti, kam se provoz odesílá, nakonfigurovaný ani dostupný žádný zdrojový překlad adres (NAT), což vede k tomu, že se jako cíl pro vrácení použije skutečná zdrojová IP adresa.
Počítač ve vaší síti směruje zpětný provoz do Microsoftu 365 prostřednictvím libovolného dostupného síťového připojení ExpressRoute.
Výsledkem je asymetrické připojení k Microsoftu 365.
Řešení 2: Zdrojový překlad adres (NAT)
Jednoduše přidáním zdrojového překladu adres (NAT) do příchozího požadavku se tato chybně nakonfigurovaná síť vyřeší. V tomto diagramu:
Příchozí požadavek bude dál zadávat přes hraniční síť datacentra v New Yorku. Tentokrát je k dispozici zdrojový překlad adres (NAT).
Odpověď ze serveru se směruje zpět na IP adresu přidruženou ke zdrojovému překladu adres (NAT) místo k původní IP adrese, což vede k tomu, že se odpověď vrátí ve stejné síťové cestě.
Na papíře ověřte, že návrh sítě má symetrii cesty.
V tuto chvíli musíte na papíře ověřit, že váš plán implementace nabízí symetrii tras pro různé scénáře, ve kterých budete používat Microsoft 365. Určíte konkrétní síťovou trasu, která se očekává, když osoba používá různé funkce služby. Z místní sítě a směrování sítě WAN, hraničních zařízení až po cestu připojení; ExpressRoute nebo internet a připojení k online koncovému bodu.
Budete to muset udělat pro všechny síťové služby Microsoft 365, které byly dříve identifikovány jako služby, které vaše organizace přijme.
Pomůže vám to udělat tento papírový návod k trasám s druhou osobou. Vysvětlete jim, odkud se očekává, že každý segment směrování sítě získá svoji další trasu, a ujistěte se, že znáte trasy směrování. Mějte na paměti, že ExpressRoute bude vždy poskytovat trasu s větším rozsahem na IP adresy serveru Microsoftu, což znamená nižší náklady na trasu než výchozí internetová trasa.
Návrh konfigurace připojení klienta
Pokud používáte proxy server pro provoz směřující na internet, musíte upravit všechny konfigurační soubory PAC nebo klienta, aby klientské počítače ve vaší síti byly správně nakonfigurované tak, aby odesílaly požadovaný provoz ExpressRoute do Microsoftu 365 bez přenosu proxy serveru a zbývající provoz, včetně některých přenosů Microsoft 365, se odešle na příslušný proxy server. Přečtěte si našeho průvodce správou koncových bodů Microsoftu 365, například souborů PAC.
Poznámka
Koncové body se často mění, často i jednou týdně. Změny byste měli provádět jenom na základě služeb a funkcí, které vaše organizace přijala, abyste snížili počet změn, které budete muset udělat, abyste zůstali aktuální. Věnujte velkou pozornost datu účinnosti v informačním kanálu RSS, kde jsou změny oznámeny a je uložen záznam všech minulých změn, IP adresy, které jsou oznámeny, nemusí být inzerovány nebo odebrány z reklamy, dokud nebude dosaženo data účinnosti.
Zajištění symetrie tras
Front-end servery Microsoftu 365 jsou přístupné jak z internetu, tak z ExpressRoute. Tyto servery budou raději směrovat zpět do místního prostředí přes okruhy ExpressRoute, pokud jsou k dispozici oba. Z tohoto důvodu existuje možnost asymetrie směrování, pokud provoz z vaší sítě dává přednost směrování přes vaše internetové okruhy. Asymetrické trasy jsou problém, protože zařízení, která provádějí stavovou kontrolu paketů, můžou blokovat zpětný provoz, který následuje jinou cestou než odchozí pakety.
Bez ohledu na to, jestli zahájíte připojení k Microsoftu 365 přes internet nebo ExpressRoute, zdrojem musí být veřejně směrovatelná adresa. Vzhledem k tomu, že mnoho zákazníků spolupracuje přímo s Microsoftem, není možné mít privátní adresy, kde je možné duplikovat mezi zákazníky.
Tady jsou scénáře, ve kterých se zahájí komunikace z Microsoftu 365 do vaší místní sítě. Pro zjednodušení návrhu sítě doporučujeme směrovat následující položky přes internetovou cestu.
Služby SMTP, jako je pošta z tenanta Exchange Online na místního hostitele nebo pošta SharePointu odeslaná ze SharePointu na místního hostitele. Protokol SMTP se používá v síti Microsoftu obecněji než předpony tras sdílené přes okruhy ExpressRoute a inzerce místních serverů SMTP přes ExpressRoute způsobí selhání s těmito dalšími službami.
Služba AD FS během ověřování hesla pro přihlášení.
Skype pro firmy hybridní federace nebo federace Skype pro firmy.
Aby Microsoft pro tyto obousměrné toky provozu přesměrovává zpátky do vaší sítě, musí být trasy protokolu BGP do místních zařízení sdíleny s Microsoftem. Při inzerování předpon tras Microsoftu přes ExpressRoute byste měli postupovat podle těchto osvědčených postupů:
Neinzerujte stejnou předponu trasy veřejné IP adresy do veřejného internetu a přes ExpressRoute. Doporučujeme, aby předpony tras protokolu IP protokolu BGP inzerované Microsoftu přes ExpressRoute byly z rozsahu, který se vůbec neinzeruje na internetu. Pokud toho není možné dosáhnout kvůli dostupnému adresní prostoru IP adres, je nezbytné zajistit, abyste prostřednictvím ExpressRoute inzerování konkrétnějšího rozsahu než jakékoli internetové okruhy.
Pro každý okruh ExpressRoute použijte samostatné fondy IP adres NAT a oddělené fondy IP adres pro vaše internetové okruhy.
Všechny trasy inzerované microsoftu přilákají síťový provoz z libovolného serveru v síti Microsoftu, nejen z těch, pro které se trasy inzerují do vaší sítě přes ExpressRoute. Inzerujte trasy pouze na servery, na kterých jsou definované scénáře směrování, které jsou dobře srozumitelné vašemu týmu. Inzerujte samostatné předpony tras IP adres na každém z více okruhů ExpressRoute z vaší sítě.
Vysoká dostupnost a převzetí služeb při selhání s využitím Azure ExpressRoute
Doporučujeme zřídit pro poskytovatele ExpressRoute alespoň dva aktivní okruhy z každého výchozího přenosu dat pomocí ExpressRoute. To je nejčastější místo, kde dochází k selháním zákazníků, a můžete se tomu snadno vyhnout tím, že zřídíte dvojici aktivních a aktivních okruhů ExpressRoute. Doporučujeme také alespoň dva aktivní/aktivní internetové okruhy, protože mnoho služeb Microsoft 365 je dostupných jenom přes internet.
Uvnitř výchozího bodu vaší sítě je mnoho dalších zařízení a okruhů, které hrají zásadní roli v tom, jak lidé vidí dostupnost. Tyto části vašich scénářů připojení nejsou pokryté smlouvami SLA ExpressRoute ani Microsoft 365, ale hrají zásadní roli v komplexní dostupnosti služeb, jak ji lidé ve vaší organizaci vnímají.
Zaměřte se na lidi, kteří používají a provozují Microsoft 365. Pokud by selhání některé komponenty mělo vliv na jejich zkušenosti s používáním služby, hledejte způsoby, jak omezit celkové procento ovlivněných osob. Pokud je režim převzetí služeb při selhání z provozu složitý, zvažte dlouhodobé zkušenosti uživatelů s obnovením a hledejte režimy jednoduchého a automatizovaného převzetí služeb při selhání.
Mimo vaši síť mají Microsoft 365, ExpressRoute a váš poskytovatel ExpressRoute různé úrovně dostupnosti.
Dostupnost služby
Na služby Microsoftu 365 se vztahují dobře definované smlouvy o úrovni služeb, které zahrnují metriky dostupnosti a doby provozu pro jednotlivé služby. Jedním z důvodů, proč Může Microsoft 365 udržovat tak vysokou dostupnost služeb, je schopnost jednotlivých komponent bezproblémově převzít služby při selhání mezi mnoha datovými centry Microsoftu pomocí globální sítě Microsoftu. Toto převzetí služeb při selhání se rozšiřuje z datacentra a sítě na několik výchozích internetových bodů a umožňuje bezproblémové převzetí služeb při selhání z pohledu lidí, kteří službu používají.
ExpressRoute poskytuje smlouvu SLA s 99,9% dostupností pro jednotlivé vyhrazené okruhy mezi Microsoft Network Edge a poskytovatelem ExpressRoute nebo partnerskou infrastrukturou. Tyto úrovně služeb se používají na úrovni okruhu ExpressRoute, který se skládá ze dvou nezávislých propojení mezi redundantním zařízením Microsoftu a zařízením poskytovatele sítě v každém umístění peeringu.
Dostupnost poskytovatele
- Ujednání o úrovni služeb microsoftu se zastaví u vašeho poskytovatele nebo partnera ExpressRoute. Toto je také první místo, kde můžete provádět rozhodnutí, která ovlivní vaši úroveň dostupnosti. Měli byste pečlivě vyhodnotit charakteristiky architektury, dostupnosti a odolnosti, které poskytovatel ExpressRoute nabízí mezi hraniční sítí a připojením poskytovatele v každém umístění partnerského vztahu Microsoftu. Věnujte velkou pozornost logickým i fyzickým aspektům redundance, vybavení peeringu, okruhům WAN poskytovaným operátorem a všem dalším službám, jako jsou služby PŘEKLAD ADRES (NAT) nebo spravované brány firewall.
Návrh plánu dostupnosti
Důrazně doporučujeme naplánovat a navrhnout vysokou dostupnost a odolnost ve scénářích kompletního připojení pro Microsoft 365. Návrh by měl obsahovat;
Žádné jednotlivé body selhání, včetně internetových okruhů a okruhů ExpressRoute.
Minimalizace počtu ovlivněných osob a doby trvání tohoto dopadu pro nejočekávanější režimy selhání
Optimalizace pro jednoduchý, opakovatelný a automatický proces obnovení z většiny předpokládaných režimů selhání
Podpora všech požadavků na síťový provoz a funkčnost prostřednictvím redundantních cest bez výrazného snížení výkonu.
Vaše scénáře připojení by měly zahrnovat síťovou topologii, která je optimalizovaná pro několik nezávislých a aktivních síťových cest k Microsoftu 365. Tím získáte lepší ucelenou dostupnost než topologie optimalizovaná pouze pro redundanci na úrovni jednotlivých zařízení nebo zařízení.
Tip
Pokud jsou vaši uživatelé distribuovaná napříč několika kontinenty nebo geografickými oblastmi a každá z těchto umístění se připojuje přes redundantní okruhy SÍTĚ WAN k jednomu místnímu umístění, kde se nachází jeden okruh ExpressRoute, budou mít uživatelé menší dostupnost služeb pro celou službu než návrh topologie sítě, který zahrnuje nezávislé okruhy ExpressRoute, které spojují různé oblasti s nejbližším umístěním partnerského vztahu.
Doporučujeme zřídit alespoň dva okruhy ExpressRoute, ke kterým se každý okruh připojuje s jiným geografickým umístěním partnerského vztahu. Tuto dvojici okruhů aktivní-aktivní byste měli zřídit pro každou oblast, ve které budou uživatelé používat připojení ExpressRoute pro služby Microsoft 365. To umožňuje, aby každá oblast zůstala připojená během havárie, která ovlivňuje hlavní umístění, jako je datacentrum nebo umístění partnerského vztahu. Jejich konfigurace v souboru jako aktivní/aktivní umožňuje distribuci provozu koncových uživatelů napříč několika síťovými cestami. Tím se zmenšuje rozsah osob ovlivněných během výpadků zařízení nebo síťového zařízení.
Nedoporučujeme jako zálohu používat jeden okruh ExpressRoute s internetem.
Příklad: Převzetí služeb při selhání a vysoká dostupnost
Multigeografická konstrukce společnosti Contoso prošla kontrolou směrování, šířky pásma a zabezpečení a teď musí projít kontrolou vysoké dostupnosti. Společnost Contoso uvažuje o vysoké dostupnosti jako o třech kategoriích; odolnost, spolehlivost a redundance.
Odolnost umožňuje společnosti Contoso rychle se zotavit z chyb. Spolehlivost umožňuje společnosti Contoso nabízet konzistentní výsledky v rámci systému. Redundance umožňuje společnosti Contoso přecházet mezi jednou nebo několika zrcadlenými instancemi infrastruktury.
V každé konfiguraci hraničních zařízení má společnost Contoso redundantní brány firewall, proxy servery a IDS. Pro Severní Amerika má společnost Contoso jednu konfiguraci hraničních zařízení ve svém datacentru Dallas a druhou v datacentru ve Virginii. Redundantní zařízení v každém umístění nabízí odolnost vůči danému umístění.
Konfigurace sítě ve společnosti Contoso je založena na několika klíčových principech:
V každé geografické oblasti existuje několik okruhů Azure ExpressRoute.
Každý okruh v rámci oblasti může podporovat veškerý síťový provoz v této oblasti.
Směrování bude jasně upřednostňovat jednu nebo druhou cestu v závislosti na dostupnosti, umístění atd.
Převzetí služeb při selhání mezi okruhy Azure ExpressRoute probíhá automaticky bez další konfigurace nebo akce vyžadované společností Contoso.
Převzetí služeb při selhání mezi internetovými okruhy probíhá automaticky bez další konfigurace nebo akce vyžadované společností Contoso.
V této konfiguraci s redundancí na fyzické i virtuální úrovni dokáže společnost Contoso spolehlivým způsobem nabídnout místní odolnost, regionální a globální odolnost. Společnost Contoso tuto konfiguraci zvolila po vyhodnocení jednoho okruhu Azure ExpressRoute pro každou oblast a možnosti převzetí služeb při selhání na internet.
Pokud společnost Contoso nemohla mít více okruhů Azure ExpressRoute pro každou oblast, směrování provozu pocházejícího z Severní Amerika do okruhu Azure ExpressRoute v asii a Tichomoří by přidalo nepřijatelnou úroveň latence a požadovaná konfigurace služby předávání DNS by byla složitější.
Použití internetu jako konfigurace zálohování se nedoporučuje. Tím se naruší princip spolehlivosti společnosti Contoso, což vede k nekonzistentnímu používání připojení. Kromě toho se k převzetí služeb při selhání vyžaduje ruční konfigurace s ohledem na nakonfigurované inzerce protokolu BGP, konfiguraci překladu adres (NAT), konfiguraci DNS a konfiguraci proxy serveru. Díky této složitosti převzetí služeb při selhání se prodlužuje doba potřebná k zotavení a snižuje se jejich schopnost diagnostikovat příslušné kroky a řešit jejich potíže.
Máte stále dotazy ohledně plánování a implementace správy provozu nebo Azure ExpressRoute? Přečtěte si zbytek našich pokynů k síti a výkonu nebo nejčastější dotazy k Azure ExpressRoute.
Použití kontrolních mechanismů zabezpečení v Azure ExpressRoute pro scénáře Microsoftu 365
Zabezpečení připojení Azure ExpressRoute začíná stejnými principy jako zabezpečení připojení k internetu. Mnoho zákazníků se rozhodne nasadit ovládací prvky sítě a hraniční sítě podél cesty ExpressRoute, která propojuje jejich místní síť s Microsoftem 365 a dalšími cloudy Microsoftu. Mezi tyto ovládací prvky patří brány firewall, proxy aplikace, prevence úniku dat, detekce neoprávněných vniknutí, systémy pro prevenci neoprávněných vniknutí atd. V mnoha případech zákazníci používají různé úrovně řízení na provoz zahájený z místního prostředí do Microsoftu a provoz zahájený z Microsoftu do místní sítě zákazníka a provoz zahájený z místního prostředí směřující do obecného internetového cíle.
Tady je několik příkladů integrace zabezpečení s modelem připojení ExpressRoute , který se rozhodnete nasadit.
| Možnost integrace ExpressRoute | Model perimetru zabezpečení sítě |
|---|---|
| Společně umístěné v cloudové výměně |
Nainstalujte novou nebo použijte stávající zabezpečení nebo hraniční infrastrukturu v zařízení pro kolokaci, kde je připojení ExpressRoute navázané. Kolokační zařízení používejte čistě pro účely směrování/propojení a zpětného přenosu připojení z kolokačního zařízení do místní bezpečnostní/hraniční infrastruktury. |
| Point-to-Point Ethernet |
Ukončete připojení ExpressRoute typu point-to-point ve stávajícím umístění místní infrastruktury zabezpečení nebo hraniční infrastruktury. Nainstalujte novou infrastrukturu zabezpečení nebo hraniční sítě specifickou pro cestu ExpressRoute a ukončete tam připojení point-to-point. |
| Any-to-Any IPVPN |
Použijte existující místní infrastrukturu zabezpečení nebo hraniční infrastruktury ve všech umístěních, která se vychytá do IPVPN používaného pro ExpressRoute pro připojení Microsoft 365. Připněte IPVPN používanou pro ExpressRoute pro Microsoft 365 do konkrétních místních umístění určených k zabezpečení nebo hraniční síti. |
Někteří poskytovatelé služeb také nabízejí funkce spravovaného zabezpečení a hraniční sítě jako součást svých řešení integrace s Azure ExpressRoute.
Při zvažování umístění topologie možností hraniční sítě nebo zabezpečení používaných pro ExpressRoute pro připojení Microsoft 365 jsou další důležité informace.
Hloubka a typ ovládacích prvků sítě a zabezpečení může mít vliv na výkon a škálovatelnost uživatelského prostředí Microsoftu 365.
Odchozí toky> (místní Microsoft) a příchozí (Microsoft-on-premises>) [pokud jsou povolené] můžou mít různé požadavky. Ty se pravděpodobně liší od odchozích a obecných internetových cílů.
Požadavky Microsoftu 365 na porty/protokoly a nezbytné podsítě IP jsou stejné bez ohledu na to, jestli se provoz směruje přes ExpressRoute pro Microsoft 365 nebo přes internet.
Topologické umístění ovládacích prvků sítě nebo zabezpečení zákazníka určuje konečnou koncovou síť mezi uživatelem a službou Microsoftu 365 a může mít podstatný dopad na latenci a zahlcení sítě.
Zákazníkům se doporučuje navrhnout topologii zabezpečení nebo hraniční sítě pro použití s ExpressRoute pro Microsoft 365 v souladu s osvědčenými postupy pro redundanci, vysokou dostupnost a zotavení po havárii.
Tady je příklad společnosti Contoso, který porovnává různé možnosti připojení Azure ExpressRoute s modely zabezpečení hraniční sítě, které jsou popsány výše.
Příklad: Zabezpečení Azure ExpressRoute
Společnost Contoso uvažuje o implementaci Azure ExpressRoute a po naplánování optimální architektury pro ExpressRoute pro Microsoft 365 a po použití výše uvedených pokynů k pochopení požadavků na šířku pásma určuje nejlepší způsob zabezpečení hraniční sítě.
V případě společnosti Contoso, organizace pro více států s umístěními na více kontinentech, musí zabezpečení překlenovat všechny perimetry. Optimální možností připojení pro společnost Contoso je vícebodové připojení s několika partnerskými umístěními po celém světě, aby bylo možné zajistit služby potřebám svých zaměstnanců na jednotlivých kontinentech. Každý kontinent zahrnuje redundantní okruhy Azure ExpressRoute v rámci tohoto kontinentu a zabezpečení musí zahrnovat všechny tyto okruhy.
Stávající infrastruktura společnosti Contoso je spolehlivá a dokáže zvládnout práci navíc. Díky tomu je společnost Contoso schopna tuto infrastrukturu používat pro zabezpečení azure ExpressRoute a internetového perimetru. Pokud tomu tak není, společnost Contoso by se mohla rozhodnout, že si koupí další vybavení, aby mohla doplnit stávající zařízení nebo zpracovat jiný typ připojení.
Plánování šířky pásma pro Azure ExpressRoute
Každý zákazník Microsoft 365 má jedinečné požadavky na šířku pásma v závislosti na počtu lidí v jednotlivých umístěních, na tom, jak jsou aktivní s každou aplikací Microsoft 365 a na dalších faktorech, jako je použití místního nebo hybridního zařízení a konfigurace zabezpečení sítě.
Příliš malá šířka pásma způsobí zahlcení, opakované přenosy dat a nepředvídatelné zpoždění. Příliš velká šířka pásma způsobí zbytečné náklady. Ve stávající síti se šířka pásma často označuje jako procento dostupného místa na okruhu. 10% prostor pro hlavu bude pravděpodobně mít za následek přetížení a 80% prostor pro hlavu obecně znamená zbytečné náklady. Typické přidělení cílové místnosti je 20 až 50 %.
Pokud chcete najít správnou úroveň šířky pásma, je nejlepším mechanismem otestovat stávající spotřebu sítě. Je to jediný způsob, jak získat skutečnou míru využití a potřeby, protože každá konfigurace sítě a aplikace jsou v některých ohledech jedinečné. Při měření budete chtít věnovat velkou pozornost celkové spotřebě šířky pásma, latenci a zahlcení protokolu TCP, abyste porozuměli potřebám sítě.
Jakmile budete mít odhadovaný směrný plán, který zahrnuje všechny síťové aplikace, nasaďte Microsoft 365 s malou skupinou, která se skládá z různých profilů lidí ve vaší organizaci, abyste zjistili skutečné využití, a pomocí těchto dvou měření odhadněte šířku pásma, kterou budete potřebovat pro každé umístění kanceláře. Pokud při testování dojde k problémům s latencí nebo zahlcením protokolu TCP, možná budete muset výchozí přenos dat přesunout blíž k uživatelům, kteří používají Microsoft 365, nebo odebrat náročné prohledávání sítě, jako je dešifrování nebo kontrola SSL.
Všechna naše doporučení ohledně toho, jaký typ síťového zpracování se doporučuje, platí pro okruhy ExpressRoute i internetové okruhy. Totéž platí pro zbytek pokynů na našem webu pro ladění výkonu.
Sestavení postupů nasazení a testování
Plán implementace by měl zahrnovat plánování testování i vrácení zpět. Pokud vaše implementace nefunguje podle očekávání, měl by být plán navržený tak, aby před zjištěním problémů ovlivnil co nejmenší počet lidí. Tady jsou některé základní principy, které byste měli zvážit v plánu.
Připravte segment sítě a onboarding uživatelských služeb, abyste minimalizovali přerušení.
Naplánujte testování tras s připojením traceroute a tcp ze samostatného hostitele připojeného k internetu.
Testování příchozích a odchozích služeb by se mělo přednostně provádět v izolované testovací síti s testovacím tenantem Microsoftu 365.
Případně je možné testování provést v produkční síti, pokud zákazník ještě nepoužívá Microsoft 365 nebo je v pilotním nasazení.
Případně je možné testování provést během výpadku výroby, který je vyhrazen pouze pro testování a monitorování.
Alternativně je možné testování provést kontrolou tras pro každou službu na každém uzlu směrovače vrstvy 3. Toto náhradní testování by mělo být použito pouze v případě, že není možné žádné jiné testování, protože nedostatek fyzického testování představuje riziko.
Sestavení postupů nasazení
Postupy nasazení by se měly postupně zavádět pro malé skupiny lidí, aby bylo možné provést testování před nasazením do větších skupin lidí. Níže je několik způsobů, jak připravit nasazení ExpressRoute.
Nastavte ExpressRoute s partnerským vztahem Microsoftu a nechte inzerování tras předávat na jednoho hostitele pouze pro účely fázovaného testování.
Nejprve inzerujte trasy do sítě ExpressRoute do jednoho segmentu sítě a rozbalte inzerování tras podle segmentu sítě nebo oblasti.
Pokud microsoft 365 nasazujete poprvé, použijte nasazení sítě ExpressRoute jako pilotní nasazení pro několik lidí.
Pokud používáte proxy servery, můžete alternativně nakonfigurovat testovací soubor PAC tak, aby nasměrovali několik lidí na ExpressRoute s testováním a zpětnou vazbou, než přidáte další.
Plán implementace by měl obsahovat seznam všech postupů nasazení, které je potřeba provést, nebo příkazů, které je potřeba použít k nasazení konfigurace sítě. Jakmile dojde k výpadku sítě, měly by všechny provedené změny pocházet z předem napsaného plánu nasazení a zkontrolovat partnerský vztah. Projděte si naše doprovodné materiály k technické konfiguraci ExpressRoute.
Aktualizace záznamů SPF TXT, pokud jste změnili IP adresy pro všechny místní servery, které budou dál posílat e-maily.
Aktualizace všech položek DNS pro místní servery, pokud jste změnili IP adresy tak, aby vyhovovaly nové konfiguraci překladu adres (NAT).
Ujistěte se, že jste se přihlásili k odběru informačního kanálu RSS pro oznámení koncového bodu Microsoftu 365, abyste zachovali všechny konfigurace směrování nebo proxy serveru.
Po dokončení nasazení ExpressRoute by se měly provést postupy v testovacím plánu. Výsledky jednotlivých postupů by měly být protokolovány. V případě, že výsledky testovacího plánu naznačují, že implementace nebyla úspěšná, musíte zahrnout postupy pro vrácení zpět do původního produkčního prostředí.
Sestavení testovacích postupů
Vaše testovací postupy by měly zahrnovat testy pro každou odchozí a příchozí síťovou službu pro Microsoft 365, která bude používat ExpressRoute i ty, které nebudou používat. Postupy by měly zahrnovat testování z každého jedinečného síťového umístění, včetně uživatelů, kteří nejsou místně ve firemní síti LAN.
Mezi příklady testovacích aktivit patří následující:
Příkazem Ping se můžete připojit z místního směrovače ke směrovači síťového operátora.
Ověřte, že místní směrovač přijímá více než 500 inzerovaných IP adres Microsoft 365 a CRM Online.
Ověřte, že příchozí a odchozí překlad adres (NAT) funguje mezi ExpressRoute a interní sítí.
Ověřte, že se trasy do vašeho překladu adres (NAT) inzerují ze směrovače.
Ověřte, že ExpressRoute přijal vaše inzerované předpony.
- Pomocí následující rutiny ověřte inzerování peeringu:
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringOvěřte, že váš rozsah veřejných IP adres (NAT) není Microsoftu inzerován prostřednictvím žádného jiného okruhu ExpressRoute nebo veřejného internetového síťového okruhu, pokud se nejedná o konkrétní podmnožinu většího rozsahu jako v předchozím příkladu.
Okruhy ExpressRoute jsou spárované a ověřte, že jsou spuštěné obě relace protokolu BGP.
Nastavte jednoho hostitele uvnitř překladu adres (NAT) a pomocí příkazů ping, tracert a tcpping otestujte připojení přes nový okruh k hostitelskému outlook.office365.com. Alternativně můžete použít nástroj, jako je Wireshark nebo Microsoft Network Monitor 3.4 na zrcadleném portu MSEE, abyste ověřili, že se můžete připojit k IP adrese přidružené k outlook.office365.com.
Otestujte funkce na úrovni aplikace pro Exchange Online.
Otestujte, že se Outlook může připojit k Exchange Online a odesílat a přijímat e-maily.
Otestujte, že Outlook může používat online režim.
Otestujte možnosti připojení a odesílání a přijímání smartphonů.
- Testování funkcí na úrovni aplikace pro SharePoint
Otestujte klienta synchronizace OneDrive pro firmy.
Otestujte přístup k webu SharePointu.
- Otestujte funkce na úrovni aplikace pro scénáře volání Skype pro firmy:
Připojte se ke konferenčnímu hovoru jako ověřený uživatel [pozvánka iniciovaná koncovým uživatelem].
Pozvat uživatele do konferenčního hovoru [pozvánka odeslána z MCU].
Připojte se ke konferenci jako anonymní uživatel pomocí webové aplikace Skype pro firmy.
Připojte se k hovoru z kabelového připojení k počítači, IP telefonu a mobilního zařízení.
Volání federovaného uživatele o Ověření volání do veřejné telefonní sítě: hovor je dokončený, kvalita hovoru je přijatelná, doba připojení je přijatelná.
Ověřte, že stav kontaktů je aktualizovaný jak pro členy tenanta, tak pro federované uživatele.
Běžné problémy
Nejčastějším problémem s implementací je asymetrické směrování. Tady je několik běžných zdrojů, které můžete hledat:
Použití otevřené nebo ploché síťové topologie směrování bez zdrojového překladu adres (NAT).
Nepoužívá se SNAT ke směrování do příchozích služeb prostřednictvím připojení k internetu i připojení ExpressRoute.
Netestování příchozích služeb v ExpressRoute v testovací síti před širším nasazením.
Nasazení připojení ExpressRoute přes vaši síť
Připravte nasazení do jednoho segmentu sítě najednou a postupně zaváďte připojení k různým částem sítě s plánem, který se bude vracet zpět pro každý nový segment sítě. Pokud je vaše nasazení v souladu s nasazením Microsoftu 365, nejprve proveďte nasazení pro pilotní uživatele Microsoftu 365 a proveďte rozšíření odsud.
Nejprve pro váš test a pak pro produkční:
Spuštěním kroků nasazení povolte ExpressRoute.
Otestujte, že se síťové trasy zobrazují podle očekávání.
Proveďte testování u každé příchozí a odchozí služby.
Pokud zjistíte nějaké problémy, vraťte zpět.
Nastavení testovacího připojení k ExpressRoute pomocí segmentu testovací sítě
Teď, když máte dokončený plán na papíře, je čas otestovat v malém měřítku. V tomto testu navážete jedno připojení ExpressRoute s partnerským vztahem Microsoftu k testovací podsíti ve vaší místní síti. Zkušebního tenanta Microsoftu 365 můžete nakonfigurovat s připojením k testovací podsíti a z testovací podsítě a zahrnout do testovací podsítě všechny odchozí a příchozí služby, které budete používat v produkčním prostředí. Nastavte DNS pro segment testovací sítě a vytvořte všechny příchozí a odchozí služby. Spusťte testovací plán a ujistěte se, že jste obeznámeni se směrováním jednotlivých služeb a šířením tras.
Spuštění plánů nasazení a testování
Po dokončení výše popsaných položek si před spuštěním plánů nasazení a testování zkontrolujte oblasti, které jste dokončili, a ujistěte se, že jste je vy a váš tým zkontrolovali.
Seznam odchozích a příchozích služeb, které se podílejí na změně sítě
Diagram globální síťové architektury znázorňující výchozí přenos dat z internetu i umístění ExpressRoute meet-me
Diagram směrování sítě znázorňující různé síťové cesty používané pro každou nasazenou službu
Plán nasazení s kroky pro implementaci změn a v případě potřeby vrácení zpět
Testovací plán pro testování každého Microsoftu 365 a síťové služby
Dokončilo se ověření provozních tras pro příchozí a odchozí služby na papíře.
Dokončený test napříč segmentem testovací sítě, včetně testování dostupnosti.
Zvolte okno výpadku, které je dostatečně dlouhé na to, aby prošel celým plánem nasazení a testovacím plánem, má k dispozici určitou dobu pro řešení potíží a v případě potřeby čas na vrácení zpět.
Upozornění
Vzhledem ke složité povaze směrování přes internet i ExpressRoute se doporučuje přidat do tohoto okna další čas vyrovnávací paměti, aby bylo možné řešit potíže se složitým směrováním.
Konfigurace QoS pro Skype pro firmy Online
QoS je nezbytné k získání hlasových výhod a výhod schůzek pro Skype pro firmy Online. QoS můžete nakonfigurovat poté, co ověříte, že síťové připojení ExpressRoute neblokuje žádný z vašich dalších služeb Microsoft 365. Konfigurace pro QoS je popsána v článku ExpressRoute a QoS v Skype pro firmy Online .
Řešení potíží s implementací
Nejprve je potřeba se podívat na kroky v tomto průvodci implementací. Došlo ve vašem plánu implementace k nějaké chybě? pokud je to možné, Zpět a spusťte další testování malé sítě, abyste chybu replikují a ladily tam.
Zjistěte, které příchozí nebo odchozí služby selhaly během testování. Získejte konkrétně IP adresy a podsítě pro každou službu, u které došlo k selhání. Pokračujte a projděte si diagram síťové topologie na papíře a ověřte směrování. Ověřte konkrétně, kam se inzeruje směrování ExpressRoute, a pokud je to možné, otestujte směrování během výpadku pomocí trasování.
Spusťte PSPing s trasováním sítě pro každý koncový bod zákazníka a vyhodnoťte zdrojové a cílové IP adresy, abyste ověřili, že jsou podle očekávání. Spusťte telnet na libovolném hostiteli pošty, kterého zveřejňujete na portu 25, a ověřte, že SNAT skrývá původní zdrojovou IP adresu, pokud je to očekávané.
Mějte na paměti, že při nasazování Microsoftu 365 s připojením ExpressRoute budete muset zajistit optimální návrh konfigurace sítě pro ExpressRoute a také optimalizaci dalších komponent v síti, jako jsou klientské počítače. Kromě použití tohoto průvodce plánováním k řešení potíží s kroky, které jste možná zmeškali, jsme také napsali plán řešení potíží s výkonem pro Microsoft 365 .
Tady je krátký odkaz, který můžete použít k návratu: https://aka.ms/implementexpressroute365
Příbuzná témata
Vyhodnocování síťového připojení Microsoftu 365
Azure ExpressRoute pro Microsoft 365
Kvalita médií a výkon připojení k síti v Skype pro firmy Online
Optimalizace sítě pro Skype pro firmy Online
ExpressRoute a QoS v Skype pro firmy Online
Tok volání pomocí ExpressRoute
Ladění výkonu Microsoftu 365 s využitím směrných plánů a historie výkonu
Plán řešení potíží s výkonem pro Microsoft 365
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro