Implementering af ExpressRoute til Microsoft 365
Denne artikel gælder for Microsoft 365 Enterprise.
ExpressRoute til Microsoft 365 giver en alternativ routingsti til mange microsoft 365-tjenester, der er på internettet. Arkitekturen i ExpressRoute til Microsoft 365 er baseret på annoncering af offentlige IP-præfikser for Microsoft 365-tjenester, der allerede er tilgængelige via internettet i dine klargjorte ExpressRoute-kredsløb for efterfølgende videredistribuering af disse IP-præfikser til dit netværk. Med ExpressRoute aktiverer du effektivt flere forskellige routingstier via internettet og via ExpressRoute for mange Microsoft 365-tjenester. Denne routingtilstand på netværket kan repræsentere en betydelig ændring af den måde, din interne netværkstopologi er designet på.
Bemærk!
Vi anbefaler ikke ExpressRoute til Microsoft 365, fordi det i de fleste tilfælde ikke leverer den bedste forbindelsesmodel til tjenesten. Microsoft-godkendelse er derfor påkrævet for at bruge denne forbindelsesmodel. Vi gennemser kun alle kundeanmodninger og godkender ExpressRoute til Microsoft 365 i de sjældne scenarier, hvor det er nødvendigt. Læs ExpressRoute til Microsoft 365-vejledningen for at få flere oplysninger og efter en omfattende gennemgang af dokumentet med dine produktivitets-, netværks- og sikkerhedsteams, og arbejd sammen med dit Microsoft-kontoteam om at indsende en undtagelse, hvis det er nødvendigt. Der vises en fejlmeddelelse for uautoriserede abonnementer, der forsøger at oprette rutefiltre til Microsoft 365.
Du skal omhyggeligt planlægge din ExpressRoute til Microsoft 365-implementering for at imødekomme netværkskompleksiteten ved at have routing tilgængelig via både et dedikeret kredsløb med ruter, der er sprøjtet ind i dit kernenetværk og internettet. Hvis du og dit team ikke udfører den detaljerede planlægning og test i denne vejledning, er der en høj risiko for, at du oplever periodiske eller samlede tab af forbindelse til Microsoft 365-tjenester, når ExpressRoute-kredsløbet er aktiveret.
Hvis du vil have en vellykket implementering, skal du analysere dine infrastrukturkrav, gennemgå detaljeret netværksvurdering og -design, planlægge udrulningen omhyggeligt på en faseindtrudført og kontrolleret måde og oprette en detaljeret validerings- og testplan. I et stort distribueret miljø er det ikke ualmindeligt, at implementeringer strækker sig over flere måneder. Denne vejledning er designet til at hjælpe dig med at planlægge fremad.
Store vellykkede udrulninger kan tage seks måneder at planlægge og omfatter ofte teammedlemmer fra mange områder i organisationen, herunder netværk, administratorer af firewall og proxyservere, Microsoft 365-administratorer, sikkerhed, slutbrugersupport, projektstyring og sponsorater fra ledelsen. Din investering i planlægningsprocessen reducerer sandsynligheden for, at du oplever udrulningsfejl, hvilket resulterer i nedetid eller kompleks og dyr fejlfinding.
Vi forventer, at følgende forudsætninger er fuldført, før denne implementeringsvejledning startes.
Du har fuldført en netværksvurdering for at afgøre, om ExpressRoute anbefales og godkendes.
Du har valgt en ExpressRoute-netværkstjenesteudbyder. Find oplysninger om ExpressRoute-partnere og peeringplaceringer.
Du har allerede læst og forstå dokumentationen til ExpressRoute , og dit interne netværk kan opfylde forudsætningerne for ExpressRoute fra ende til anden.
Dit team har læst al offentlig vejledning og dokumentation på https://aka.ms/expressrouteoffice365, https://aka.ms/ertog set Azure ExpressRoute for Microsoft 365 Training-serien på Channel 9 for at få en forståelse af vigtige tekniske detaljer, herunder:
Internetafhængighederne for SaaS-tjenester.
Sådan undgår du asymmetriske ruter og håndterer kompleks routing.
Sådan inkorporerer du kontrolelementer på perimetersikkerhed, tilgængelighed og programniveau.
Begynd med at indsamle krav
Start med at bestemme, hvilke funktioner og tjenester du planlægger at anvende i din organisation. Du skal afgøre, hvilke funktioner i de forskellige Microsoft 365-tjenester der skal bruges, og hvilke placeringer på dit netværk der skal hoste personer, der bruger disse funktioner. Med kataloget over scenarier skal du tilføje de netværksattributter, som hvert af disse scenarier kræver. f.eks. indgående og udgående netværkstrafikflow, og om Microsoft 365-slutpunkterne er tilgængelige via ExpressRoute eller ej.
Sådan indsamler du organisationens krav:
Katalogér den indgående og udgående netværkstrafik for de Microsoft 365-tjenester, din organisation bruger. Se microsoft 365 URL-adresser og siden MED IP-adresseområder for at få en beskrivelse af flow, som forskellige Microsoft 365-scenarier kræver.
Indsaml dokumentation for eksisterende netværkstopologi, der viser detaljer om din interne WAN-backbone og -topologi, tilslutning af satellitwebsteder, sidste kilometers brugerforbindelse, routing til udgående netværksperimeterpunkter og proxytjenester.
Identificer indgående tjenesteslutpunkter i netværksdiagrammer, som Microsoft 365 og andre Microsoft-tjenester opretter forbindelse til, og vis både internet- og foreslåede ExpressRoute-forbindelsesstier.
Identificer alle geografiske brugerplaceringer og WAN-forbindelser mellem placeringer, sammen med hvilke placeringer der i øjeblikket har en udgående forbindelse til internettet, og hvilke placeringer der foreslås til at have en udgående forbindelse til en ExpressRoute-peeringplacering.
Identificer alle edge-enheder, f.eks. proxyer, firewalls osv., og katalogiser deres relation til flow, der går over internettet og ExpressRoute.
Dokumentér, om slutbrugerne skal have adgang til Microsoft 365-tjenester via Direct Routing eller indirekte programproxy for både internet- og ExpressRoute-flow.
Føj lejerens placering og møde mig-placeringer til netværksdiagrammet.
Estimer den forventede og observerede netværksydeevne og ventetid fra større brugerplaceringer til Microsoft 365. Vær opmærksom på, at Microsoft 365 er et globalt og distribueret sæt tjenester, og at brugerne opretter forbindelse til placeringer, der kan være forskellige fra placeringen af deres lejer. Derfor anbefales det at måle og optimere ventetiden mellem brugeren og den nærmeste kant af Microsofts globale netværk via ExpressRoute og internetforbindelser. Du kan bruge dine resultater fra netværksvurderingen til at hjælpe med denne opgave.
Angiv virksomhedens krav til netværkssikkerhed og høj tilgængelighed, der skal opfyldes med den nye ExpressRoute-forbindelse. Hvordan fortsætter brugerne f.eks. med at få adgang til Microsoft 365 i tilfælde af, at der opstår fejl i udgående data eller ExpressRoute-kredsløb.
Dokumentér, hvilke indgående og udgående Microsoft 365-netværksflows der bruger internetstien, og som bruger ExpressRoute. Specifikationerne for dine brugeres geografiske placeringer og oplysninger om din lokale netværkstopologi kan kræve, at planen er forskellig fra én brugerplacering til en anden.
Katalogér din udgående og indgående netværkstrafik
For at minimere routing og andre netværkskompleksiteter anbefaler vi, at du kun bruger ExpressRoute til Microsoft 365 til de netværkstrafikflow, der skal bruges til at oprette en dedikeret forbindelse på grund af lovmæssige krav eller som følge af netværksvurderingen. Derudover anbefaler vi, at du faser omfanget af ExpressRoute-routing og tilgang til udgående og indgående netværkstrafikflow som forskellige og særskilte faser i implementeringsprojektet. Installér ExpressRoute til Microsoft 365 for brugerinitierede udgående netværkstrafikflows, og lad indgående netværkstrafikflow forblive på tværs af internettet kan hjælpe med at styre stigningen i topologisk kompleksitet og risici ved at introducere yderligere asymmetriske routingmuligheder.
Dit katalog over netværkstrafik skal indeholde lister over alle de indgående og udgående netværksforbindelser, du har mellem dit lokale netværk og Microsoft.
Udgående netværkstrafikflows er alle scenarier, hvor der startes en forbindelse fra dit lokale miljø, f.eks. fra interne klienter eller servere, med en destination for Microsoft-tjenesterne. Disse forbindelser kan være direkte til Microsoft 365 eller indirekte, f.eks. når forbindelsen går gennem proxyservere, firewalls eller andre netværksenheder på stien til Microsoft 365.
Indgående netværkstrafikflow er scenarier, hvor der startes en forbindelse fra Microsoft-cloudmiljøet til en vært i det lokale miljø. Disse forbindelser skal typisk gå gennem firewall og anden sikkerhedsinfrastruktur, som kundens sikkerhedspolitik kræver til eksternt opståede flow.
Læs afsnittet Sikring af rutesymmetri for at finde ud af, hvilke tjenester der sender indgående trafik, og søg efter den kolonne, der er markeret som ExpressRoute for Microsoft 365 , i artiklen Reference til Microsoft 365-slutpunkter for at bestemme resten af forbindelsesoplysningerne.
For hver tjeneste, der kræver en udgående forbindelse, skal du beskrive den planlagte forbindelse til tjenesten, herunder netværksrouting, proxykonfiguration, pakkekontrol og båndbreddebehov.
For hver tjeneste, der kræver en indgående forbindelse, skal du bruge nogle yderligere oplysninger. Servere i Microsoft-clouden opretter forbindelser til dit lokale netværk. Hvis du vil sikre, at forbindelserne er oprettet korrekt, skal du beskrive alle aspekter af denne forbindelse, herunder; de offentlige DNS-poster for de tjenester, der accepterer disse indgående forbindelser, de CIDR-formaterede IPv4 IP-adresser, som ISP-udstyr er involveret i, og hvordan indgående NAT eller kilde-NAT håndteres for disse forbindelser.
Indgående forbindelser skal gennemses, uanset om de opretter forbindelse via internettet eller ExpressRoute, for at sikre, at asymmetrisk routing ikke er blevet introduceret. I nogle tilfælde skal de slutpunkter i det lokale miljø, som Microsoft 365-tjenester starter indgående forbindelser til, muligvis også have adgang til fra andre Microsoft- og ikke-Microsoft-tjenester. Det er altafgørende, at aktivering af ExpressRoute-routing til disse tjenester til Microsoft 365-formål ikke ødelægger andre scenarier. I mange tilfælde skal kunder muligvis implementere specifikke ændringer af deres interne netværk, f.eks. kildebaseret NAT, for at sikre, at indgående flow fra Microsoft forbliver symmetriske, når ExpressRoute er aktiveret.
Her er et eksempel på det påkrævede detaljeniveau. I dette tilfælde dirigerer Exchange Hybrid til det lokale system via ExpressRoute.
| Forbindelsesegenskab | Værdi |
|---|---|
| Netværkstrafikretning |
Indgående |
| Tjeneste |
Exchange Hybrid |
| Offentligt Microsoft 365-slutpunkt (kilde) |
Exchange Online (IP-adresser) |
| Offentligt slutpunkt i det lokale miljø (destination) |
5.5.5.5 |
| Offentlig (Internet) DNS-post |
Autodiscover.contoso.com |
| Vil dette slutpunkt i det lokale miljø blive brugt af andre (ikke-Microsoft 365) Microsoft-tjenester |
Nej |
| Vil dette slutpunkt i det lokale miljø blive brugt af brugere/systemer på internettet |
Ja |
| Interne systemer, der er publiceret via offentlige slutpunkter |
Exchange Server klientadgangsrolle (i det lokale miljø) 192.168.101, 192.168.102, 192.168.103 |
| IP-annoncering af det offentlige slutpunkt |
Til internettet: 5.5.0.0/16 til ExpressRoute: 5.5.5.0/24 |
| Sikkerheds-/perimeterkontrolelementer |
Internetsti: DeviceID_002 ExpressRoute-sti: DeviceID_003 |
| Høj tilgængelighed |
Active/Active på tværs af 2 geo-redundante/ExpressRoute-kredsløb – Chicago og Dallas |
| Stisymmetrikontrolelement |
Metode: Kilde NAT-internetsti: Kilde NAT-indgående forbindelser til 192.168.5.5 ExpressRoute-sti: Kilde NAT-forbindelser til 192.168.1.0 (Chicago) og 192.168.2.0 (Dallas) |
Her er et eksempel på en tjeneste, der kun er udgående:
| Forbindelsesegenskab | Værdi |
|---|---|
| Netværkstrafikretning |
Udgående |
| Tjeneste |
SharePoint |
| Slutpunkt i det lokale miljø (kilde) |
Brugerarbejdsstation |
| Offentligt Microsoft 365-slutpunkt (destination) |
SharePoint (IP-adresser) |
| Offentlig (Internet) DNS-post |
*.sharepoint.com (og flere FQDN'er) |
| CDN-henvisninger |
cdn.sharepointonline.com (og flere FQDN'er) – IP-adresser, der vedligeholdes af CDN-udbydere |
| IP-annoncering og NAT i brug |
Internetsti/kilde-NAT: 1.1.1.0/24 ExpressRoute path/Source NAT: 1.1.2.0/24 (Chicago) og 1.1.3.0/24 (Dallas) |
| Forbindelsesmetode |
Internet: via layer 7-proxy (.pac-fil) ExpressRoute: direkte routing (ingen proxy) |
| Sikkerheds-/perimeterkontrolelementer |
Internetsti: DeviceID_002 Sti til ExpressRoute: DeviceID_003 |
| Høj tilgængelighed |
Internetsti: Redundant internetudgående ExpressRoute-sti: Aktiv/aktiv distribution af "varme kartofler" på tværs af to geo-redundante ExpressRoute-kredsløb – Chicago og Dallas |
| Stisymmetrikontrolelement |
Metode: Kilde-NAT for alle forbindelser |
Dit design af netværkstopologi med regional forbindelse
Når du har forstået tjenesterne og deres tilknyttede netværkstrafikflow, kan du oprette et netværksdiagram, der omfatter disse nye forbindelseskrav og illustrerer de ændringer, du foretager for at bruge ExpressRoute til Microsoft 365. Diagrammet skal indeholde:
Alle brugerplaceringer, hvor Microsoft 365 og andre tjenester skal tilgås fra.
Alle internet- og ExpressRoute-udgående punkter.
Alle udgående og indgående enheder, der administrerer forbindelse ind og ud af netværket, herunder routere, firewalls, programproxyservere og registrering/forebyggelse af indtrængen.
Interne destinationer for al indgående trafik, f.eks. interne ADFS-servere, der accepterer forbindelser fra ADFS-webprogramproxyservere.
Katalog over alle IP-undernet, der vil blive annonceret
Identificer hver placering, hvor brugerne skal have adgang til Microsoft 365 fra, og angiv de mødeplaceringer, der skal bruges til ExpressRoute.
Placeringer og dele af din interne netværkstopologi, hvor Microsofts IP-præfikser, der er lært fra ExpressRoute, accepteres, filtreres og overføres til.
Netværkstopologien skal illustrere den geografiske placering af hvert netværkssegment, og hvordan det opretter forbindelse til Microsoft-netværket via ExpressRoute og/eller internettet.
Nedenstående diagram viser hver placering, hvor personer skal bruge Microsoft 365 fra sammen med de indgående og udgående routing-reklamer til Microsoft 365.
Ved udgående trafik får personerne adgang til Microsoft 365 på en af tre måder:
Gennem et møde-mig sted i Nordamerika for folk i Californien.
Gennem et møde-mig placering i Hongkong Særlige Administrative Region for befolkningen i Sar Hongkong.
Via internettet i Bangladesh, hvor der er færre mennesker, og hvor der ikke er klargjort noget ExpressRoute-kredsløb.
På samme måde returnerer den indgående netværkstrafik fra Microsoft 365 på en af tre måder:
Gennem et møde-mig sted i Nordamerika for folk i Californien.
Gennem et møde-mig placering i Hongkong Særlige Administrative Region for befolkningen i Sar Hongkong.
Via internettet i Bangladesh, hvor der er færre mennesker, og hvor der ikke er klargjort noget ExpressRoute-kredsløb.
Fastlæg den relevante møde-mig-placering
Valget af møde-mig-placeringer, som er den fysiske placering, hvor dit ExpressRoute-kredsløb forbinder dit netværk til Microsoft-netværket, påvirkes af de placeringer, hvor personer får adgang til Microsoft 365 fra. Som et SaaS-tilbud fungerer Microsoft 365 ikke under den regionale IaaS- eller PaaS-model på samme måde som Azure. Microsoft 365 er i stedet et distribueret sæt samarbejdstjenester, hvor brugerne muligvis skal oprette forbindelse til slutpunkter på tværs af flere datacentre og områder, som muligvis ikke nødvendigvis befinder sig på den samme placering eller det samme område, som brugerens lejer hostes på.
Det betyder, at den vigtigste overvejelse, du skal gøre, når du vælger møde-mig-placeringer for ExpressRoute til Microsoft 365, er det sted, hvor personerne i din organisation opretter forbindelse fra. Den generelle anbefaling om optimal Microsoft 365-forbindelse er at implementere routing, så brugeranmodninger til Microsoft 365-tjenester overdrages til Microsoft-netværket via den korteste netværkssti, og dette omtales også ofte som "varm kartoffel"-routing. Hvis de fleste Microsoft 365-brugere f.eks. befinder sig på en eller to placeringer, vil det skabe det optimale design, hvis du vælger møde-mig-placeringer, der ligger tættest på placeringen af disse brugere. Hvis din virksomhed har store brugerpopulationer i mange forskellige områder, kan det være en god idé at overveje at have flere ExpressRoute-kredsløb og mødessteder. For nogle af dine brugerplaceringer er den korteste/mest optimale sti til Microsoft-netværket og Microsoft 365 muligvis ikke via dine interne WAN- og ExpressRoute-mødepunkter, men via internettet.
Der er ofte flere møde-mig-placeringer, der kan vælges i et område med relativ nærhed til dine brugere. Udfyld følgende tabel for at vejlede dig i dine beslutninger.
Planlagte ExpressRoute-mødeplaceringer i Californien og New York
| Placering |
Antal personer |
Forventet ventetid for Microsoft-netværk via internetudgående data |
Forventet ventetid for Microsoft-netværk via ExpressRoute |
|---|---|---|---|
| Los Angeles |
10,000 |
Ca. 15 ms |
Ca. 10 ms (via Silicon Valley) |
| Washington DC |
15,000 |
Ca. 20 ms |
Ca. 10 ms (via New York) |
| Dallas |
5,000 |
Ca. 15 ms |
Ca. 40 ms (via New York) |
Når den globale netværksarkitektur, der viser Microsoft 365-området, Udbyderen af ExpressRoute-netværkstjenester opfylder mig,og antallet af personer efter placering er blevet udviklet, kan den bruges til at identificere, om der kan foretages optimeringer. Det kan også vise globale hårnål netværksforbindelser, hvor trafik ruter til en fjern placering for at få møde-mig placering. Hvis der opdages en hårnål på det globale netværk, skal den afhjælpes, før den fortsætter. Find en anden møde-mig-placering, eller brug selektive internet udgangspunkter for at undgå hårnålen.
Det første diagram viser et eksempel på en kunde med to fysiske placeringer i Nordamerika. Du kan se oplysninger om kontorplaceringer, Microsoft 365-lejerplaceringer og flere valgmuligheder for Møde-mig-placeringer i ExpressRoute. I dette eksempel har kunden valgt mødeplaceringen baseret på to principper i rækkefølge:
Tættest på personerne i organisationen.
Tættest på et Microsoft-datacenter, hvor Microsoft 365 hostes.
Hvis man udvider dette koncept lidt yderligere, viser det andet diagram et eksempel på en flernational kunde, der står over for lignende oplysninger og beslutningstagning. Denne kunde har et lille kontor i Bangladesh med kun et lille team på 10 personer, der fokuserer på at øge deres fodaftryk i regionen. Der er en møde-mig-placering i Chennai og et Microsoft-datacenter med Microsoft 365 hostet i Chennai, så en møde-mig-placering ville give mening. men for 10 personer er udgifterne til det ekstra kredsløb byrdefuldt. Når du ser på dit netværk, skal du afgøre, om den ventetid, der er forbundet med at sende din netværkstrafik på tværs af netværket, er mere effektiv end at bruge kapitalen til at erhverve et andet ExpressRoute-kredsløb.
Alternativt kan de 10 personer i Bangladesh opleve bedre ydeevne med deres netværkstrafik sendt over internettet til Microsoft-netværket, end de ville routing på deres interne netværk, som vi viste i introduktionsdiagrammerne og gengivet nedenfor.
Create din ExpressRoute til Microsoft 365-implementeringsplan
Din implementeringsplan bør omfatte både de tekniske detaljer om konfiguration af ExpressRoute og oplysninger om konfiguration af al anden infrastruktur på netværket, f.eks. følgende.
Planlæg, hvilke tjenester der skal opdeles mellem ExpressRoute og Internet.
Planlæg båndbredde, sikkerhed, høj tilgængelighed og failover.
Design indgående og udgående routing, herunder korrekt optimering af routingstier for forskellige placeringer
Beslut, hvor langt ExpressRoute-ruter skal annonceres i dit netværk, og hvad er mekanismen for klienter til at vælge internet- eller ExpressRoute-sti. f.eks. direkte routing eller programproxy.
Planlæg ændringer af DNS-poster, herunder poster i Sender Policy Framework .
Planlæg NAT-strategi, herunder udgående og indgående kilde NAT.
Planlæg distributionen med både internet- og ExpressRoute-netværksstier
I forbindelse med den indledende udrulning anbefales det, at alle indgående tjenester, f.eks. indgående mail eller hybridforbindelse, bruger internettet.
Planlæg lan-routing for slutbrugerklienten, f.eks . konfiguration af en PAC/WPAD-fil, standardrute, proxyservere og BGP-rutereklamer.
Planlæg perimeterrouting, herunder proxyservere, firewalls og proxyer i cloudmiljøet.
Planlæg din båndbredde, sikkerhed, høj tilgængelighed og failover
Create en plan for båndbredde, der kræves for hver større Microsoft 365-arbejdsbelastning. Estimer separat krav til Exchange Online, SharePoint og Skype for Business onlinebåndbredde. Du kan bruge de skønsberegninger, vi har angivet for Exchange Online og Skype for Business som udgangspunkt. Men en pilottest med et repræsentativt eksempel på brugerprofiler og placeringer er påkrævet for fuldt ud at forstå din organisations behov for båndbredde.
Føj den måde, sikkerhed håndteres på hver internet- og ExpressRoute-udgående placering til din plan på. Husk, at alle ExpressRoute-forbindelser til Microsoft 365 bruger offentlig peering, og at de stadig skal sikres i overensstemmelse med virksomhedens sikkerhedspolitikker for at oprette forbindelse til eksterne netværk.
Føj detaljer til din plan om, hvilke personer der påvirkes af, hvilken type afbrydelse, og hvordan disse personer på den nemmeste måde kan udføre deres arbejde i fuld kapacitet.
Planlæg krav til båndbredde, herunder krav til Skype for Business for Jitter, Ventetid, Overbelastning og Headroom
Skype for Business Online har også specifikke ekstra netværkskrav, som beskrives i artiklen Media Quality and Network Connectivity Performance in Skype for Business Online.
Læs afsnittet Planlægning af båndbredde for Azure ExpressRoute. Når du udfører en vurdering af båndbredden med dine pilotbrugere, kan du bruge vores vejledning til Tilpasning af ydeevnen i Microsoft 365 ved hjælp af grundlæggende data og ydeevnehistorik.
Planlæg krav til høj tilgængelighed
Create en plan for høj tilgængelighed, der opfylder dine behov, og indarbejde dette i dit opdaterede netværkstopologidiagram. Læs afsnittet Høj tilgængelighed og failover med Azure ExpressRoute.
Planlæg sikkerhedskrav til netværk
Create en plan, der opfylder dine krav til netværkssikkerhed, og indarbejde dette i dit opdaterede diagram over netværkstopologi. Læs afsnittet Anvendelse af sikkerhedskontroller på Azure ExpressRoute til Microsoft 365-scenarier.
Design forbindelse til udgående tjenester
ExpressRoute til Microsoft 365 har udgående netværkskrav, der kan være ukendte. De IP-adresser, der repræsenterer dine brugere og netværk til Microsoft 365 og fungerer som kildeslutpunkter for udgående netværksforbindelser til Microsoft, skal specifikt følge de specifikke krav, der er beskrevet nedenfor.
Slutpunkterne skal være offentlige IP-adresser, der er registreret i dit firma, eller til luftfartsselskabet, der leverer ExpressRoute-forbindelse til dig.
Slutpunkterne skal annonceres til Microsoft og valideres/accepteres af ExpressRoute.
Slutpunkterne må ikke annonceres på internettet med den samme eller flere foretrukne routingmetrikværdi.
Slutpunkterne må ikke bruges til at oprette forbindelse til Microsoft-tjenester, der ikke er konfigureret via ExpressRoute.
Hvis dit netværksdesign ikke opfylder disse krav, er der stor risiko for, at dine brugere vil opleve forbindelsesfejl til Microsoft 365 og andre Microsoft-tjenester på grund af distribution af sort holing eller asymmetrisk routing. Dette sker, når anmodninger til Microsoft-tjenester distribueres via ExpressRoute, men svar distribueres tilbage via internettet eller omvendt, og svarene fjernes af tilstandsfulde netværksenheder, f.eks. firewalls.
Den mest almindelige metode, du kan bruge til at opfylde ovenstående krav, er at bruge kilde-NAT, enten implementeret som en del af dit netværk eller leveret af din ExpressRoute-udbyder. Kilde NAT giver dig mulighed for at udtrække detaljer og privat IP-adressering for dit internetnetværk fra ExpressRoute og; kombineret med korrekt IP-rute reklamer, give en nem mekanisme til at sikre sti symmetri. Hvis du bruger tilstandsfulde netværksenheder, der er specifikke for ExpressRoute-peeringplaceringer, skal du implementere separate NAT-grupper for hver ExpressRoute-peering for at sikre stisymmetri.
Læs mere om ExpressRoute NAT-kravene.
Føj ændringerne for den udgående forbindelse til netværkstopologidiagrammet.
Design indgående tjenesteforbindelse
De fleste virksomhedsinstallationer af Microsoft 365 forudsætter en form for indgående forbindelse fra Microsoft 365 til tjenester i det lokale miljø, f.eks. til Exchange, SharePoint og Skype for Business hybride scenarier, migrering af postkasser og godkendelse ved hjælp af ADFS-infrastruktur. Når Du aktiverer en ekstra routingsti mellem dit lokale netværk og Microsoft til udgående forbindelser, kan disse indgående forbindelser utilsigtet blive påvirket af asymmetrisk routing, selvom du vil have, at disse flow fortsætter med at bruge internettet. Nogle få forholdsregler, der er beskrevet nedenfor, anbefales for at sikre, at der ikke er nogen indvirkning på internetbaserede indgående flow fra Microsoft 365 til systemer i det lokale miljø.
For at minimere risikoen for asymmetrisk routing for indgående netværkstrafikflow skal alle indgående forbindelser bruge kilde-NAT, før de distribueres til segmenter af dit netværk, som har routingsynlighed i ExpressRoute. Hvis indgående forbindelser er tilladt til et netværkssegment med routingsynlighed i ExpressRoute uden kilde-NAT, vil anmodninger fra Microsoft 365 komme ind fra internettet, men svaret, der går tilbage til Microsoft 365, foretrækker ExpressRoute-netværksstien tilbage til Microsoft-netværket, hvilket medfører asymmetrisk routing.
Du kan overveje et af følgende implementeringsmønstre for at opfylde dette krav:
Udfør nat-kilden, før anmodninger dirigeres til dit interne netværk ved hjælp af netværksudstyr, f.eks. firewalls eller belastningsjusteringer på stien fra internettet til dine systemer i det lokale miljø.
Sørg for, at ExpressRoute-ruter ikke overføres til de netværkssegmenter, hvor indgående tjenester, f.eks. frontendservere eller omvendte proxysystemer, håndterer internetforbindelser.
Eksplicit at tage højde for disse scenarier i dit netværk og holde alle indgående netværkstrafikflow over internettet hjælper med at minimere udrulningen og driftsrisikoen for asymmetrisk routing.
Der kan være tilfælde, hvor du kan vælge at dirigere nogle indgående flow via ExpressRoute-forbindelser. I forbindelse med disse scenarier skal du tage følgende ekstra overvejelser i betragtning.
Microsoft 365 kan kun målrette slutpunkter i det lokale miljø, der bruger offentlige IP-adresser. Det betyder, at selvom det indgående slutpunkt i det lokale miljø kun eksponeres for Microsoft 365 via ExpressRoute, skal det stadig have en offentlig IP-adresse tilknyttet.
Alle DNS-navnefortsættelser, som Microsoft 365-tjenester udfører for at løse slutpunkter i det lokale miljø, sker ved hjælp af offentlig DNS. Det betyder, at du skal registrere indgående tjenesteslutpunkters FQDN til IP-tilknytninger på internettet.
Hvis du vil modtage indgående netværksforbindelser via ExpressRoute, skal de offentlige IP-undernet for disse slutpunkter annonceres til Microsoft via ExpressRoute.
Evaluer omhyggeligt disse indgående netværkstrafikflow for at sikre, at der anvendes korrekt sikkerhed og netværkskontroller på dem i overensstemmelse med virksomhedens sikkerhed og netværkspolitikker.
Når dine indgående slutpunkter i det lokale miljø er annonceret til Microsoft via ExpressRoute, bliver ExpressRoute den foretrukne routingsti til disse slutpunkter for alle Microsoft-tjenester, herunder Microsoft 365. Det betyder, at disse slutpunktundernet kun må bruges til kommunikation med Microsoft 365-tjenester og ingen andre tjenester på Microsoft-netværket. Ellers medfører dit design asymmetrisk routing, hvor indgående forbindelser fra andre Microsoft-tjenester foretrækker at dirigere indgående over ExpressRoute, mens returstien bruger internettet.
Hvis et ExpressRoute-kredsløb eller en møde-mig-placering er nede, skal du sikre, at de indgående slutpunkter i det lokale miljø stadig er tilgængelige til at acceptere anmodninger via en separat netværkssti. Det kan betyde annoncering af undernet for disse slutpunkter via flere ExpressRoute-kredsløb.
Vi anbefaler, at du anvender nat-kilden for alle indgående netværkstrafikflow, der kommer ind på dit netværk via ExpressRoute, især når disse flow er på tværs af tilstandsbaserede netværksenheder, f.eks. firewalls.
Nogle tjenester i det lokale miljø, f.eks. ADFS-proxy eller Exchange autodiscover, kan modtage indgående anmodninger fra både Microsoft 365-tjenester og brugere fra internettet. For disse anmodninger vil Microsoft 365 målrette det samme FQDN som brugeranmodninger via internettet. Hvis du tillader indgående brugerforbindelser fra internettet til disse slutpunkter i det lokale miljø, samtidig med at Microsoft 365-forbindelser tvinges til at bruge ExpressRoute, repræsenterer det en betydelig routingkompleksitet. For langt de fleste kunder, der implementerer sådanne komplekse scenarier via ExpressRoute, anbefales det ikke på grund af driftsmæssige overvejelser. Dette ekstra spild omfatter administration af risici for asymmetrisk routing og kræver, at du omhyggeligt administrerer routingannoncer og politikker på tværs af flere dimensioner.
Opdater din netværkstopologiplan for at vise, hvordan du undgår asymmetriske ruter
Du vil gerne undgå asymmetrisk routing for at sikre, at personer i din organisation problemfrit kan bruge Microsoft 365 samt andre vigtige tjenester på internettet. Der er to almindelige konfigurationer, som kunderne har, som forårsager asymmetrisk routing. Nu er et godt tidspunkt til at gennemse den netværkskonfiguration, du planlægger at bruge, og kontrollere, om der kan være et af disse asymmetriske routingscenarier.
Til at begynde med undersøger vi nogle forskellige situationer, der er knyttet til følgende netværksdiagram. I dette diagram er alle servere, der modtager indgående anmodninger, f.eks. ADFS eller hybridservere i det lokale miljø, i New Jersey-datacenteret og annonceres på internettet.
Selvom perimeternetværket er sikkert, er der ingen kilde-NAT tilgængelig for indgående anmodninger.
Serverne i New Jersey-datacenteret kan se både internet- og ExpressRoute-ruter.
Vi har også forslag til, hvordan du løser dem.
Problem 1: Cloud til forbindelse i det lokale miljø via internettet
I følgende diagram illustreres den asymmetriske netværkssti, der udføres, når din netværkskonfiguration ikke leverer NAT til indgående anmodninger fra Microsoft-cloudmiljøet via internettet.
Den indgående anmodning fra Microsoft 365 henter IP-adressen for slutpunktet i det lokale miljø fra offentlig DNS og sender anmodningen til perimeternetværket.
I denne fejlbehæftede konfiguration er der ingen kilde-NAT konfigureret eller tilgængelig på perimeternetværket, hvor trafikken sendes, hvilket resulterer i, at den faktiske IP-kildeadresse bruges som returdestination.
Serveren på netværket dirigerer returtrafikken til Microsoft 365 via alle tilgængelige ExpressRoute-netværksforbindelser.
Resultatet er en asymmetrisk sti for det pågældende flow til Microsoft 365, hvilket resulterer i en afbrudt forbindelse.
Løsning 1a: Kilde NAT
Hvis du blot føjer en NAT-kilde til den indgående anmodning, løses dette forkert konfigurerede netværk. I dette diagram:
Den indgående anmodning fortsætter med at komme ind via New Jersey-datacenterets perimeternetværk. Denne gang er kilde-NAT tilgængelig.
Svaret fra serveren dirigeres tilbage mod den IP, der er knyttet til Kilde-NAT i stedet for den oprindelige IP-adresse, hvilket resulterer i, at svaret returneres langs den samme netværkssti.
Løsning 1b: Ruteudformning
Du kan også vælge ikke at tillade, at expressRoute BGP-præfikser annonceres, og fjerne den alternative netværkssti for disse computere. I dette diagram:
Den indgående anmodning fortsætter med at komme ind via New Jersey-datacenterets perimeternetværk. Denne gang er de præfikser, der annonceres fra Microsoft via ExpressRoute-kredsløbet, ikke tilgængelige for New Jersey-datacenteret.
Svaret fra serveren dirigeres tilbage mod den IP-adresse, der er knyttet til den oprindelige IP-adresse, via den eneste tilgængelige rute, hvilket resulterer i, at svaret returneres langs den samme netværkssti.
Problem 2: Cloud til forbindelse i det lokale miljø via ExpressRoute
I følgende diagram illustreres den asymmetriske netværkssti, der udføres, når netværkskonfigurationen ikke leverer NAT til indgående anmodninger fra Microsoft-cloudmiljøet via ExpressRoute.
Den indgående anmodning fra Microsoft 365 henter IP-adressen fra DNS og sender anmodningen til perimeternetværket.
I denne fejlbehæftede konfiguration er der ingen kilde-NAT konfigureret eller tilgængelig på perimeternetværket, hvor trafikken sendes, hvilket resulterer i, at den faktiske IP-kildeadresse bruges som returdestination.
Computeren på netværket dirigerer returtrafikken til Microsoft 365 via alle tilgængelige ExpressRoute-netværksforbindelser.
Resultatet er en asymmetrisk forbindelse til Microsoft 365.
Løsning 2: Kilde NAT
Hvis du blot føjer en NAT-kilde til den indgående anmodning, løses dette forkert konfigurerede netværk. I dette diagram:
Den indgående anmodning fortsætter med at komme ind via New York-datacenterets perimeternetværk. Denne gang er kilde-NAT tilgængelig.
Svaret fra serveren dirigeres tilbage mod den IP, der er knyttet til Kilde-NAT i stedet for den oprindelige IP-adresse, hvilket resulterer i, at svaret returneres langs den samme netværkssti.
Papir bekræfter, at netværksdesignet har stisymmetri
På dette tidspunkt skal du på papir bekræfte, at din implementeringsplan tilbyder rutesymmetri for de forskellige scenarier, hvor du bruger Microsoft 365. Du identificerer den specifikke netværksrute, der forventes at blive taget, når en person bruger forskellige funktioner i tjenesten. Fra netværket i det lokale miljø og WAN-routing til perimeterenhederne til forbindelsesstien. ExpressRoute eller internettet og videre til forbindelsen til onlineslutpunktet.
Du skal gøre dette for alle de Microsoft 365-netværkstjenester, der tidligere blev identificeret som tjenester, som din organisation vil anvende.
Det hjælper at gøre dette papir gennemgang af ruter med en anden person. Forklar dem, hvor hvert netværkshop forventes at få sin næste rute fra, og sørg for, at du kender distributionsstierne. Husk, at ExpressRoute altid giver en mere begrænset rute til Microsoft-serverens IP-adresser, hvilket giver den lavere ruteomkostninger end en standardrute på internettet.
Konfiguration af Design klientforbindelse
Hvis du bruger en proxyserver til internetbundet trafik, skal du justere alle PAC- eller klientkonfigurationsfiler for at sikre, at klientcomputerne på netværket er konfigureret korrekt til at sende den ExpressRoute-trafik, du ønsker, til Microsoft 365 uden at overføre proxyserveren, og at den resterende trafik, herunder lidt Microsoft 365-trafik, sendes til den relevante proxy. Læs vores vejledning til administration af Microsoft 365-slutpunkter, f.eks. PAC-filer.
Bemærk!
Slutpunkterne ændres ofte, så ofte som ugentligt. Du bør kun foretage ændringer på baggrund af de tjenester og funktioner, din organisation har vedtaget, for at reducere antallet af ændringer, du skal foretage for at holde dig opdateret. Vær opmærksom på ikrafttrædelsesdatoen i RSS-feedet, hvor ændringerne annonceres, og en registrering af alle tidligere ændringer, IP-adresser, der annonceres, må ikke annonceres eller fjernes fra annonceringen, indtil ikrafttrædelsesdatoen er nået.
Sikrer rutesymmetri
Microsoft 365-frontendserverne er tilgængelige både på internettet og ExpressRoute. Disse servere foretrækker at dirigere tilbage til det lokale miljø via ExpressRoute-kredsløb, når begge er tilgængelige. På grund af dette er der en mulighed for at distribuere asymmetri, hvis trafik fra dit netværk foretrækker at dirigere over dine internetkredsløb. Asymmetriske ruter er et problem, fordi enheder, der udfører tilstandsfuld pakkekontrol, kan blokere returtrafik, der følger en anden sti end de udgående pakker, der følges.
Uanset om du starter en forbindelse til Microsoft 365 via internettet eller ExpressRoute, skal kilden være en adresse, der kan sendes offentligt. Med mange kunder, der peerer direkte med Microsoft, er det ikke muligt at have private adresser, hvor duplikering er mulig mellem kunder.
Følgende er scenarier, hvor kommunikation fra Microsoft 365 til dit lokale netværk startes. For at forenkle netværksdesignet anbefaler vi, at du distribuerer følgende via internetstien.
SMTP-tjenester, f.eks. mail fra en Exchange Online lejer til en lokal vært eller SharePoint-mail, der er sendt fra SharePoint til en lokal vært. SMTP-protokollen bruges mere bredt på Microsofts netværk, end de rutepræfikser, der deles via ExpressRoute-kredsløb, og annoncering af SMTP-servere i det lokale miljø via ExpressRoute, vil medføre fejl med disse andre tjenester.
ADFS under validering af adgangskode til logon.
Skype for Business hybrid- og/eller Skype for Business-sammenslutning.
For at Microsoft kan dirigere tilbage til dit netværk for disse tovejstrafikflows, skal BGP-ruterne til dine enheder i det lokale miljø deles med Microsoft. Når du reklamerer for rutepræfikser til Microsoft via ExpressRoute, skal du følge disse bedste fremgangsmåder:
Undlad at annoncere for det samme præfiks for den offentlige IP-adresse til det offentlige internet og over ExpressRoute. Det anbefales, at reklamerne for IP BGP-rutepræfikset til Microsoft over ExpressRoute er fra et interval, der slet ikke annonceres på internettet. Hvis dette ikke er muligt at opnå på grund af den tilgængelige IP-adresseplads, er det vigtigt at sikre, at du reklamerer for et mere specifikt interval over ExpressRoute end nogen internetkredsløb.
Brug separate NAT IP-puljer pr. ExpressRoute-kredsløb, og adskil dem med internetkredsløbene.
Enhver rute, der annonceres til Microsoft, vil tiltrække netværkstrafik fra en hvilken som helst server i Microsofts netværk, ikke kun dem, for hvilke ruter annonceres til dit netværk via ExpressRoute. Reklamer kun for ruter til servere, hvor routingscenarier er defineret og forstås godt af dit team. Gør opmærksom på separate præfikser for IP-adresser på hvert af flere ExpressRoute-kredsløb fra dit netværk.
Høj tilgængelighed og failover med Azure ExpressRoute
Vi anbefaler, at du klargør mindst to aktive kredsløb fra hver enkelt udgående forbindelse med ExpressRoute til din ExpressRoute-udbyder. Dette er det mest almindelige sted, hvor vi ser fejl for kunder, og du kan nemt undgå det ved at klargøre et par aktive/aktive ExpressRoute-kredsløb. Vi anbefaler også mindst to aktive/aktive internetkredsløb, fordi mange Microsoft 365-tjenester kun er tilgængelige via internettet.
Inde i udgående punkt i dit netværk er mange andre enheder og kredsløb, der spiller en vigtig rolle i, hvordan folk opfatter tilgængelighed. Disse dele af dine forbindelsesscenarier er ikke omfattet af ExpressRoute eller Microsoft 365 SLA'er, men de spiller en vigtig rolle i forbindelse med tilgængeligheden af tjenesten fra ende til anden, som opfattes af personer i din organisation.
Fokuser på de personer, der bruger og driver Microsoft 365, hvis en fejl i en enkelt komponent ville påvirke folks oplevelse med at bruge tjenesten, skal du kigge efter måder at begrænse den samlede procentdel af berørte personer på. Hvis en failovertilstand er operationelt kompleks, skal du overveje folks oplevelse af lang tid til at komme sig og søge efter driftsklare og automatiserede failovertilstande.
Uden for dit netværk har Microsoft 365, ExpressRoute og din ExpressRoute-udbyder alle forskellige tilgængelighedsniveauer.
Tjenestetilgængelighed
Microsoft 365-tjenester er omfattet af veldefinerede serviceniveauaftaler, som omfatter målepunkter for oppetid og tilgængelighed for individuelle tjenester. En af grundene til, at Microsoft 365 kan bevare så høje tjenestetilgængelighedsniveauer, er muligheden for, at individuelle komponenter problemfrit kan skifte mellem de mange Microsoft-datacentre ved hjælp af det globale Microsoft-netværk. Denne failover strækker sig fra datacenteret og netværket til de mange internet udgående punkter og muliggør failover problemfrit set fra de personer, der bruger tjenesten.
ExpressRoute giver en SLA på 99,9 % tilgængelighed på individuelle dedikerede kredsløb mellem Microsoft Network Edge og ExpressRoute-udbyderen eller partnerinfrastrukturen. Disse tjenesteniveauer anvendes på ExpressRoute-kredsløbsniveauet, som består af to uafhængige forbindelser mellem det redundante Microsoft-udstyr og netværksudbyderudstyret på hver peeringplacering.
Udbydertilgængelighed
- Microsofts ordninger på tjenesteniveau stopper hos din ExpressRoute-udbyder eller -partner. Dette er også det første sted, hvor du kan foretage valg, der påvirker dit tilgængelighedsniveau. Du bør nøje evaluere arkitekturen, tilgængeligheden og robusthedsegenskaberne, som din ExpressRoute-udbyder tilbyder mellem din netværksperimeter og din udbyders forbindelse på hver Microsoft-peeringplacering. Vær opmærksom på både de logiske og fysiske aspekter af redundans, peeringudstyr, OPERATØR-leverede WAN-kredsløb og eventuelle ekstra værditilføjningstjenester som NAT-tjenester eller administrerede firewalls.
Design af din tilgængelighedsplan
Vi anbefaler på det kraftigste, at du planlægger og designer høj tilgængelighed og robusthed i dine komplette forbindelsesscenarier for Microsoft 365. Et design skal inkludere;
Der er ingen enkelte fejlpunkter, herunder både internet- og ExpressRoute-kredsløb.
Minimering af antallet af berørte personer og varigheden af denne indvirkning for de mest forventede fejltilstande.
Optimering til enkel, gentagelig og automatisk gendannelsesproces fra de mest forventede fejltilstande.
Understøttelse af de fulde krav til netværkstrafik og -funktionalitet via redundante stier uden en væsentlig forringelse.
Dine forbindelsesscenarier bør omfatte en netværkstopologi, der er optimeret til flere uafhængige og aktive netværksstier til Microsoft 365. Dette giver en bedre tilgængelighed fra ende til anden end en topologi, der kun er optimeret til redundans på individuel enhed- eller udstyrsniveau.
Tip
Hvis dine brugere distribueres på tværs af flere kontinenter eller geografiske områder, og hver af disse placeringer opretter forbindelse via redundante WAN-kredsløb til en enkelt placering i det lokale miljø, hvor et enkelt ExpressRoute-kredsløb er placeret, vil dine brugere opleve mindre end end-end-tjenestetilgængelighed end et netværkstopologidesign, der omfatter uafhængige ExpressRoute-kredsløb, der forbinder de forskellige områder til den nærmeste peeringplacering.
Vi anbefaler, at der klargøres mindst to ExpressRoute-kredsløb, hvor hvert kredsløb opretter forbindelse til med en anden geografisk peeringplacering. Du skal klargøre dette aktive kredsløbspar for hvert område, hvor brugerne skal bruge ExpressRoute-forbindelse til Microsoft 365-tjenester. Dette gør det muligt for hvert område at forblive forbundet under en katastrofe, der påvirker en større placering, f.eks. et datacenter eller en peeringplacering. Hvis du konfigurerer dem som aktive/aktive, kan slutbrugertrafik distribueres på tværs af flere netværksstier. Dette reducerer omfanget af berørte personer under afbrydelser af enhedens eller netværkets udstyr.
Vi anbefaler ikke, at du bruger et enkelt ExpressRoute-kredsløb med internettet som sikkerhedskopi.
Eksempel: Failover og høj tilgængelighed
Contosos multigeografiske design har gennemgået en gennemgang af routing, båndbredde, sikkerhed og skal nu gennemgå en gennemgang af høj tilgængelighed. Contoso mener, at høj tilgængelighed dækker tre kategorier; robusthed, pålidelighed og redundans.
Robusthed gør det muligt for Contoso hurtigt at genoprette efter fejl. Pålidelighed giver Contoso mulighed for at tilbyde et ensartet resultat i systemet. Redundans gør det muligt for Contoso at flytte mellem en eller flere spejlede forekomster af infrastrukturen.
I hver edgekonfiguration har Contoso redundante firewalls, proxyer og IDS. For Nordamerika har Contoso én edge-konfiguration i deres Dallas-datacenter og en anden edge-konfiguration i deres Virginia-datacenter. Det redundante udstyr på hvert sted giver robusthed til det pågældende sted.
Netværkskonfigurationen på Contoso er baseret på nogle få nøgleprincipper:
Inden for hvert geografisk område er der flere Azure ExpressRoute-kredsløb.
Hvert kredsløb i et område kan understøtte al netværkstrafik i det pågældende område.
Distribution foretrækker helt klart den ene eller den anden sti afhængigt af tilgængelighed, placering osv.
Failover mellem Azure ExpressRoute-kredsløb sker automatisk uden yderligere konfiguration eller handling, der kræves af Contoso.
Failover mellem internetkredsløb sker automatisk uden yderligere konfiguration eller handling, der kræves af Contoso.
I denne konfiguration kan Contoso med redundans på det fysiske og virtuelle niveau tilbyde lokal robusthed, regional robusthed og global robusthed på en pålidelig måde. Contoso valgte denne konfiguration efter at have evalueret et enkelt Azure ExpressRoute-kredsløb pr. område samt muligheden for at mislykkes via internettet.
Hvis Contoso ikke kunne have flere Azure ExpressRoute-kredsløb pr. område, vil routingtrafik, der stammer fra Nordamerika til Azure ExpressRoute-kredsløbet i Asien og Stillehavsområdet, tilføje en uacceptabel ventetid, og den påkrævede KONFIGURATION af DNS-videresendelse tilføjer kompleksitet.
Det anbefales ikke at bruge internettet som en sikkerhedskopikonfiguration. Dette bryder Contosos pålidelighedsprincip, hvilket resulterer i en uoverensstemmende oplevelse ved hjælp af forbindelsen. Desuden vil manuel konfiguration være påkrævet for at udføre failover i forhold til de BGP-reklamer, der er konfigureret, NAT-konfiguration, DNS-konfiguration og proxykonfigurationen. Denne ekstra failover-kompleksitet øger tiden til at gendanne og reducerer deres mulighed for at diagnosticere og foretage fejlfinding af de involverede trin.
Har du stadig spørgsmål om, hvordan du planlægger og implementerer trafikstyring eller Azure ExpressRoute? Læs resten af vores vejledning til netværk og ydeevne eller ofte stillede spørgsmål om Azure ExpressRoute.
Anvendelse af sikkerhedskontrolelementer på Azure ExpressRoute til Microsoft 365-scenarier
Sikring af Azure ExpressRoute-forbindelse starter med de samme principper som sikring af internetforbindelse. Mange kunder vælger at installere netværks- og perimeterkontrolelementer langs ExpressRoute-stien, der forbinder deres lokale netværk til Microsoft 365 og andre Microsoft-cloudmiljøer. Disse kontrolelementer kan omfatte firewalls, programproxyer, forebyggelse af datalækage, registrering af indtrængen, systemer til forebyggelse af indtrængen osv. I mange tilfælde anvender kunder forskellige niveauer af kontrolelementer for trafik, der startes fra det lokale miljø, og som går til Microsoft, i forhold til trafik, der startes fra Microsoft, når de går til kundenetværket i det lokale miljø, i forhold til trafik, der er startet fra det lokale miljø, og som går til en generel internetdestination.
Her er et par eksempler på integration af sikkerhed med den ExpressRoute-forbindelsesmodel, du vælger at udrulle.
| ExpressRoute-integrationsmulighed | Perimetermodel for netværkssikkerhed |
|---|---|
| Samlokeret på en cloududveksling |
Installér ny, eller brug eksisterende sikkerheds-/perimeterinfrastruktur i den colocationsfacilitet, hvor ExpressRoute-forbindelsen er etableret. Brug colocationsfacilitet udelukkende til routing-/interconnect-formål og back-træk-forbindelser fra colocationsfaciliteten til sikkerheds-/perimeterinfrastrukturen i det lokale miljø. |
| Point-to-Point Ethernet |
Afslut Point-to-Point ExpressRoute-forbindelsen på den eksisterende placering af sikkerheds-/perimeterinfrastrukturen i det lokale miljø. Installer ny sikkerheds-/perimeterinfrastruktur, der er specifik for ExpressRoute-stien, og afslut Point-to-Point-forbindelsen der. |
| Enhver-til-enhver IPVPN |
Brug en eksisterende sikkerheds-/perimeterinfrastruktur i det lokale miljø på alle de placeringer, der ankommer til DEN IPVPN, der bruges til ExpressRoute til Microsoft 365-forbindelse. Frigør DEN IPVPN, der bruges til ExpressRoute til Microsoft 365, til specifikke placeringer i det lokale miljø, der er angivet til at fungere som sikkerhed/perimeter. |
Nogle tjenesteudbydere tilbyder også administreret sikkerheds-/perimeterfunktionalitet som en del af deres integrationsløsninger med Azure ExpressRoute.
Når du overvejer topologiplaceringen af de netværks-/sikkerhedsperimeterindstillinger, der bruges til ExpressRoute til Microsoft 365-forbindelser, er følgende ekstra overvejelser
Dybde- og typekontrolelementerne for netværk/sikkerhed kan have indflydelse på ydeevnen og skalerbarheden af Microsoft 365-brugeroplevelsen.
Udgående (i det lokale miljø-Microsoft>) og indgående (Microsoft-i> det lokale miljø) [hvis aktiveret] flow kan have forskellige krav. Disse er sandsynligvis anderledes end udgående til generelle internetdestinationer.
Microsoft 365-krav til porte/protokoller og nødvendige IP-undernet er de samme, uanset om trafikken dirigeres via ExpressRoute til Microsoft 365 eller via internettet.
Topologisk placering af kundenetværks-/sikkerhedskontroller bestemmer det endelige slutpunkt til slutpunkt-netværk mellem brugeren og Microsoft 365-tjenesten og kan have stor indvirkning på netværksventetid og overbelastning.
Kunder opfordres til at designe deres sikkerheds-/perimetertopologi til brug med ExpressRoute til Microsoft 365 i overensstemmelse med bedste praksis for redundans, høj tilgængelighed og it-katastrofeberedskab.
Her er et eksempel på Contoso, der sammenligner de forskellige muligheder for Azure ExpressRoute-forbindelser med de perimetersikkerhedsmodeller, der er beskrevet ovenfor.
Eksempel: Sikring af Azure ExpressRoute
Contoso overvejer at implementere Azure ExpressRoute, og efter at have planlagt den optimale arkitektur for ExpressRoute til Microsoft 365 og efter at have brugt ovenstående vejledning til at forstå båndbreddekrav, bestemmer de den bedste metode til sikring af deres perimeter.
For Contoso, der er en multinational organisation med placeringer på flere kontinenter, skal sikkerheden spænde over alle perimeterer. Den optimale forbindelsesmulighed for Contoso er en multipunktforbindelse med flere peering-placeringer over hele verden for at servicere deres medarbejderes behov på hvert kontinent. Hvert kontinent indeholder redundante Azure ExpressRoute-kredsløb på kontinentet, og sikkerhed skal spænde over alle disse.
Contosos eksisterende infrastruktur er pålidelig og kan håndtere det ekstra arbejde. Derfor kan Contoso bruge infrastrukturen til deres Azure ExpressRoute- og internetperimetersikkerhed. Hvis det ikke var tilfældet, kunne Contoso vælge at købe mere udstyr for at supplere deres eksisterende udstyr eller håndtere en anden type forbindelse.
Planlægning af båndbredde for Azure ExpressRoute
Alle Microsoft 365-kunder har unikke båndbreddebehov, afhængigt af antallet af personer på hvert sted, hvor aktive de er med hvert Microsoft 365-program og andre faktorer, f.eks. brugen af lokale eller hybridudstyrs- og netværkssikkerhedskonfigurationer.
Hvis båndbredden er for lille, vil det medføre overbelastning, videretransmission af data og uforudsigelige forsinkelser. Hvis du har for meget båndbredde, medfører det unødvendige omkostninger. På et eksisterende netværk refereres der ofte til båndbredden i forhold til mængden af tilgængelig headroom på kredsløbet som en procentdel. Hvis der er 10 % headroom, vil det sandsynligvis medføre overbelastning, og hvis der er 80 % headroom, betyder det generelt unødvendige omkostninger. Typiske headroom måltildelinger er 20% til 50%.
For at finde det rigtige båndbreddeniveau er den bedste mekanisme at teste dit eksisterende netværksforbrug. Dette er den eneste måde at få en sand måling af brug og behov, da alle netværkskonfigurationer og -programmer på nogle måder er unikke. Når du måler, skal du være opmærksom på det samlede båndbreddeforbrug, ventetid og TCP-overbelastning for at forstå dine netværksbehov.
Når du har en anslået baseline, der omfatter alle netværksprogrammer, kan du styre Microsoft 365 med en lille gruppe, der består af de forskellige profiler af personer i din organisation for at bestemme det faktiske forbrug, og bruge de to målinger til at estimere den mængde båndbredde, du skal bruge for hver kontorplacering. Hvis der er problemer med ventetid eller TCP-overbelastning i din test, skal du muligvis flytte udgående data tættere på de personer, der bruger Microsoft 365, eller fjerne intensiv netværksscanning, f.eks. SSL-dekryptering/inspektion.
Alle vores anbefalinger til, hvilken type netværksbehandling der anbefales, gælder for både ExpressRoute- og internetkredsløb. Det samme gælder for resten af vejledningen på vores websted til justering af ydeevne.
Byg dine udrulnings- og testprocedurer
Din implementeringsplan skal omfatte både test- og annulleringsplanlægning. Hvis din implementering ikke fungerer som forventet, skal planen være designet til at påvirke det mindste antal personer, før der opdages problemer. Følgende er nogle principper på højt niveau, som din plan bør overveje.
Iscenegør netværkssegmentet og onboarding af brugertjenesten for at minimere afbrydelse.
Plan for test af ruter med traceroute og TCP-forbindelse fra en separat vært med internetforbindelse.
Det foretrækkes, at test af indgående og udgående tjenester udføres på et isoleret testnetværk med en test af Microsoft 365-lejeren.
Alternativt kan der udføres test på et produktionsnetværk, hvis kunden endnu ikke bruger Microsoft 365 eller er pilot.
Alternativt kan der udføres test under en produktionsafbrydelse, der kun afsættes til test og overvågning.
Alternativt kan du teste ved at kontrollere ruterne for hver tjeneste på hver lag 3-routernode. Dette tilbagefald bør kun bruges, hvis ingen andre test er mulige, da manglende fysisk test medfører risiko.
Opbyg dine installationsprocedurer
Dine udrulningsprocedurer bør udrulles til små grupper af personer i faser, så de kan testes, før de udrulles til større grupper af personer. Følgende er flere måder at forberede installationen af ExpressRoute på.
Konfigurer ExpressRoute med Microsoft-peering, og få rutereklamerne kun videresendt til en enkelt vært med henblik på trinvis test.
Annoncer ruter til ExpressRoute-netværket til et enkelt netværkssegment i første omgang, og udvid ruteannoncer efter netværkssegment eller område.
Hvis det er første gang, du installerer Microsoft 365, skal du bruge netværksinstallationen ExpressRoute som pilot for nogle få personer.
Hvis du bruger proxyservere, kan du alternativt konfigurere en test-PAC-fil for at sende nogle få personer til ExpressRoute med test og feedback, før du tilføjer mere.
Din implementeringsplan skal vise hver af de installationsprocedurer, der skal udføres, eller kommandoer, der skal bruges til at installere netværkskonfigurationen. Når netværksafbrydelsestiden ankommer, skal alle de ændringer, der foretages, være fra den skriftlige udrulningsplan, der blev skrevet på forhånd, og peer review. Se vores vejledning til den tekniske konfiguration af ExpressRoute.
Opdatering af SPF TXT-posterne, hvis du har ændret IP-adresser for servere i det lokale miljø, som fortsat vil sende mails.
Opdaterer alle DNS-poster for lokale servere, hvis du har ændret IP-adresser for at imødekomme en ny NAT-konfiguration.
Sørg for, at du abonnerer på RSS-feedet for Microsoft 365-slutpunktsmeddelelser for at bevare alle routing- eller proxykonfigurationer.
Når installationen af ExpressRoute er fuldført, skal procedurerne i testplanen udføres. Resultaterne for hver procedure skal logføres. Du skal inkludere procedurer for tilbagerulning til det oprindelige produktionsmiljø, hvis resultaterne af testplanen angiver, at implementeringen ikke lykkedes.
Opbyg dine testprocedurer
Dine testprocedurer skal omfatte test for hver udgående og indgående netværkstjeneste til Microsoft 365, som både bruger ExpressRoute og dem, der ikke vil. Procedurerne bør omfatte test fra hver unikke netværksplacering, herunder brugere, der ikke er i det lokale miljø på virksomhedens LAN.
Nogle eksempler på testaktiviteter omfatter følgende.
Ping fra din lokale router til din netværksoperatørrouter.
Valider, at reklamer for IP-adresser til 500+ Microsoft 365 og CRM Online modtages af routeren i det lokale miljø.
Kontrollér, at din indgående og udgående NAT fungerer mellem ExpressRoute og det interne netværk.
Valider, at ruter til din NAT annonceres fra din router.
Kontrollér, at ExpressRoute har accepteret de annoncerede præfikser.
- Brug følgende cmdlet til at bekræfte peering-reklamer:
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringValider, at dit offentlige NAT-IP-interval ikke annonceres til Microsoft via andre ExpressRoute- eller offentlige internetnetværkskredsløb, medmindre det er et bestemt undersæt af et større interval som i det forrige eksempel.
ExpressRoute-kredsløb parres. Kontrollér, at begge BGP-sessioner kører.
Konfigurer en enkelt vært på indersiden af din NAT, og brug ping, tracert og tcpping til at teste forbindelsen på tværs af det nye kredsløb til værts-outlook.office365.com. Du kan også bruge et værktøj som Wireshark eller Microsoft Network Monitor 3.4 på en spejlet port til MSEE til at validere, at du kan oprette forbindelse til den IP-adresse, der er knyttet til outlook.office365.com.
Test funktionaliteten på programniveau for Exchange Online.
Test, at Outlook kan oprette forbindelse til Exchange Online og sende/modtage mail.
Test Outlook kan bruge onlinetilstand.
Test smartphoneforbindelse og send/modtag-funktionalitet.
- Test funktionalitet på programniveau for SharePoint
Test OneDrive for Business synkroniseringsklient.
Test SharePoint-webadgang.
- Test funktionaliteten på programniveau for Skype for Business opkaldsscenarier:
Deltag i telefonmøde som godkendt bruger [inviter startet af slutbrugeren].
Inviter bruger til telefonmøde [invitation sendt fra MCU].
Deltag i konferencen som anonym bruger ved hjælp af Skype for Business webprogrammet.
Deltag i opkald fra din kablede pc-forbindelse, IP-telefon og mobilenhed.
Opkald til den bruger, der er medlem af organisationsnetværket, o Opkald til PSTN-validering: Opkaldet er fuldført, opkaldskvaliteten er acceptabel, forbindelsestiden er acceptabel.
Kontrollér, at tilstedeværelsesstatus for kontakter er opdateret for både medlemmer af lejeren og brugere i organisationsnetværket.
Almindelige problemer
Asymmetrisk routing er det mest almindelige implementeringsproblem. Her er nogle almindelige kilder, du kan søge efter:
Brug af en åben eller flad netværksroutingstopologi uden kilde-NAT på plads.
Bruger ikke SNAT til at dirigere til indgående tjenester via både internet- og ExpressRoute-forbindelser.
Der testes ikke indgående tjenester på ExpressRoute på et testnetværk, før de udrulles bredt.
Udrulning af ExpressRoute-forbindelse via dit netværk
Udrulning til ét segment af netværket ad gangen, gradvis udrulning af forbindelsen til forskellige dele af netværket med en plan om at annullere for hvert nyt netværkssegment. Hvis din installation er justeret i forhold til en Microsoft 365-udrulning, skal du først udrulle til dine Microsoft 365-pilotbrugere og udvide derfra.
Først til din test og derefter til produktion:
Kør installationstrinnene for at aktivere ExpressRoute.
Test, om netværksruterne er som forventet.
Udfør test af hver indgående og udgående tjeneste.
Annullering, hvis du opdager problemer.
Konfigurer en testforbindelse til ExpressRoute med et testnetværkssegment
Nu, hvor du har den færdige plan på papir, er det tid til at teste i lille skala. I denne test skal du oprette en enkelt ExpressRoute-forbindelse med Microsoft Peering til et testundernet på dit lokale netværk. Du kan konfigurere en prøveversion af En Microsoft 365-lejer med forbindelse til og fra testundernettet og inkludere alle udgående og indgående tjenester, som du bruger i produktionen i testundernettet. Konfigurer DNS for testnetværkssegmentet, og opret alle indgående og udgående tjenester. Udfør din testplan, og sørg for, at du kender distributionen for hver tjeneste og ruteoverførslen.
Udfør udrulnings- og testplanerne
Når du har fuldført de elementer, der er beskrevet ovenfor, skal du afkrydse de områder, du har fuldført, og sikre, at du og dit team har gennemgået dem, før du kører dine udrulnings- og testplaner.
Liste over udgående og indgående tjenester, der er involveret i netværksændringen.
Diagram over global netværksarkitektur, der viser både internet udgående data og ExpressRoute-mødeplaceringer.
Netværksroutingdiagram, der demonstrerer de forskellige netværksstier, der bruges til hver tjeneste, der er installeret.
En udrulningsplan med trin til implementering af ændringerne og annullering, hvis det er nødvendigt.
En testplan til test af hver Microsoft 365- og netværkstjeneste.
Fuldført papirvalidering af produktionsruter for indgående og udgående tjenester.
En fuldført test på tværs af et testnetværkssegment, herunder tilgængelighedstest.
Vælg et afbrydelsesvindue, der er langt nok til at gennemgå hele udrulningsplanen og testplanen, og som har lidt tid til rådighed til fejlfinding og tid til at rulle tilbage, hvis det er nødvendigt.
Forsigtighed
På grund af den komplekse distribution over både internettet og ExpressRoute anbefales det, at der føjes ekstra buffertid til dette vindue for at håndtere fejlfinding af kompleks routing.
Konfigurer QoS for Skype for Business Online
QoS er nødvendigt for at opnå stemme- og mødefordele for Skype for Business Online. Du kan konfigurere QoS, når du har sørget for, at ExpressRoute-netværksforbindelsen ikke blokerer nogen af dine andre microsoft 365-tjenesteadgange. Konfiguration af QoS er beskrevet i artiklen ExpressRoute og QoS i Skype for Business Online .
Fejlfinding af implementeringen
Det første sted at se på trinnene i denne implementeringsvejledning, blev nogen savnet i din implementeringsplan? Gå tilbage, og kør yderligere test af små netværk, hvis det er muligt, for at replikere fejlen og foretage fejlfinding af den der.
Identificer, hvilke indgående eller udgående tjenester der mislykkedes under testen. Hent specifikt IP-adresserne og undernet for hver af de tjenester, der mislykkedes. Gå videre, og gå i gang med netværkstopologidiagrammet på papir, og valider distributionen. Valider specifikt, hvor ExpressRoute-distributionen annonceres til, Test denne routing under afbrydelsen, hvis det er muligt med sporinger.
Kør PSPing med en netværkssporing til hvert kundeslutpunkt, og evaluer kilde- og destinations-IP-adresser for at validere, at de er som forventet. Kør telnet til en hvilken som helst postvært, som du viser på port 25, og kontrollér, at SNAT skjuler den oprindelige kilde-IP-adresse, hvis dette forventes.
Vær opmærksom på, at når du udruller Microsoft 365 med en ExpressRoute-forbindelse, skal du sikre, at både netværkskonfigurationen for ExpressRoute er optimalt designet, og at du også har optimeret de andre komponenter på netværket, f.eks. klientcomputere. Ud over at bruge denne planlægningsvejledning til fejlfinding af de trin, du måske gik glip af, har vi også skrevet en plan til fejlfinding af ydeevnen for Microsoft 365 .
Her er et kort link, du kan bruge til at vende tilbage: https://aka.ms/implementexpressroute365
Relaterede emner
Vurderer Microsoft 365 netværksforbindelse
Azure ExpressRoute til Microsoft 365
Mediekvalitet og ydeevne for netværksforbindelsen i Skype for Business Online
Optimering af netværket til Skype for Business Online
ExpressRoute og QoS i Skype for Business Online
Opkaldsflow ved hjælp af ExpressRoute
Justering af ydeevnen i Microsoft 365 ved hjælp af grundlinjer og ydeevnehistorik
Plan for fejlfinding af ydeevne for Microsoft 365