Implementere ExpressRoute for Microsoft 365
Denne artikkelen gjelder for Microsoft 365 Enterprise.
ExpressRoute for Microsoft 365 gir en alternativ rutingbane til mange Internett-vendte Microsoft 365-tjenester. Arkitekturen til ExpressRoute for Microsoft 365 er basert på annonsering av offentlige IP-prefikser for Microsoft 365-tjenester som allerede er tilgjengelige via Internett, i de klargjorte ExpressRoute-kretsene for påfølgende redistribusjon av disse IP-prefiksene i nettverket. Med ExpressRoute aktiverer du effektivt flere forskjellige rutingbaner, via Internett og via ExpressRoute, for mange Microsoft 365-tjenester. Denne tilstanden for ruting på nettverket kan representere en betydelig endring i hvordan den interne nettverkstopologien er utformet.
Obs!
Vi anbefaler ikke ExpressRoute for Microsoft 365 fordi den ikke tilbyr den beste tilkoblingsmodellen for tjenesten i de fleste tilfeller. Som sådan kreves Microsoft-autorisasjon for å bruke denne tilkoblingsmodellen. Vi ser gjennom alle kundeforespørsler og godkjenner ExpressRoute for Microsoft 365 bare i de sjeldne scenariene der det er nødvendig. Les ExpressRoute for Microsoft 365-veiledningen for mer informasjon, og følg en omfattende gjennomgang av dokumentet med produktivitets-, nettverks- og sikkerhetsteamene dine, og samarbeid med Microsoft-kontoteamet for å sende inn et unntak om nødvendig. Uautoriserte abonnementer som prøver å opprette rutefiltre for Microsoft 365, får en feilmelding.
Du må planlegge ExpressRoute for Microsoft 365-implementeringen nøye for å imøtekomme nettverkskompleksiteten ved å ha ruting tilgjengelig via både en dedikert krets med ruter injisert i kjernenettverket og Internett. Hvis du og teamet ditt ikke utfører den detaljerte planleggingen og testingen i denne veiledningen, er det en høy risiko for at du opplever uregelmessig eller totalt tap av tilkobling til Microsoft 365-tjenester når ExpressRoute-kretsen er aktivert.
Hvis du vil ha en vellykket implementering, må du analysere kravene til infrastrukturen, gå gjennom detaljert nettverksvurdering og -utforming, planlegge utrullingen nøye på en trinnvis og kontrollert måte, og bygge en detaljert validerings- og testplan. For et stort, distribuert miljø er det ikke uvanlig å se implementeringer strekke seg over flere måneder. Denne veiledningen er utformet for å hjelpe deg med å planlegge fremover.
Store vellykkede distribusjoner kan ta seks måneder i planleggingen og inkluderer ofte gruppemedlemmer fra mange områder i organisasjonen, inkludert nettverks-, brannmur- og proxy-serveradministratorer, Microsoft 365-administratorer, sikkerhet, sluttbrukerstøtte, prosjektstyring og støtte fra ledelsen. Investeringen i planleggingsprosessen vil redusere sannsynligheten for at du vil oppleve distribusjonsfeil som resulterer i nedetid eller kompleks og dyr feilsøking.
Vi forventer at følgende forutsetninger må fullføres før denne implementeringsveiledningen startes.
Du har fullført en nettverksvurdering for å finne ut om ExpressRoute anbefales og godkjennes.
Du har valgt en leverandør av expressroute-nettverkstjeneste. Finn detaljer om ExpressRoute-partnere og nodeplasseringer.
Du har allerede lest og forstått ExpressRoute-dokumentasjonen , og det interne nettverket kan oppfylle forutsetningene for ExpressRoute fra ende til ende.
Teamet ditt har lest all offentlig veiledning og dokumentasjon på https://aka.ms/expressrouteoffice365, https://aka.ms/ertog har sett opplæringsserien Azure ExpressRoute for Microsoft 365 på Kanal 9 for å få en forståelse av kritiske tekniske detaljer, inkludert:
Internett-avhengighetene til SaaS-tjenester.
Slik unngår du asymmetriske ruter og håndterer kompleks ruting.
Slik innlemmer du perimetersikkerhet, tilgjengelighet og programnivåkontroller.
Begynn med å samle inn krav
Start med å bestemme hvilke funksjoner og tjenester du planlegger å ta i bruk i organisasjonen. Du må finne ut hvilke funksjoner i de ulike Microsoft 365-tjenestene som skal brukes, og hvilke plasseringer på nettverket som vil være vert for personer som bruker disse funksjonene. Med katalogen over scenarioer må du legge til nettverksattributtene som hvert av disse scenariene krever. for eksempel innkommende og utgående nettverkstrafikkflyter og hvis Microsoft 365-endepunktene er tilgjengelige via ExpressRoute eller ikke.
Slik samler du inn organisasjonens krav:
Katalogisere den inngående og utgående nettverkstrafikken for Microsoft 365-tjenestene organisasjonen bruker. Se nettadresser og IP-adresseområder for Microsoft 365 for å få en beskrivelse av flyter som ulike Microsoft 365-scenarioer krever.
Samle dokumentasjon om eksisterende nettverkstopologi som viser detaljer om intern WAN ryggrad og topologi, tilkobling av satellittområder, siste mil brukertilkobling, ruting til nettverksperimeterutgående punkter og proxy-tjenester.
Identifiser innkommende tjenesteendepunkter i nettverksdiagrammene som Microsoft 365 og andre Microsoft-tjenester skal koble til, og som viser både Internett- og foreslåtte ExpressRoute-tilkoblingsbaner.
Identifiser alle geografiske brukerplasseringer og WAN-tilkobling mellom plasseringer sammen med hvilke plasseringer som for øyeblikket har en utgående trafikk til Internett, og hvilke plasseringer som foreslås å ha en utgående plassering til en ExpressRoute-nodeplassering.
Identifiser alle edge-enheter, for eksempel proxyer, brannmurer og så videre, og katalogisere relasjonen til flyter som går via Internett og ExpressRoute.
Dokumenter om sluttbrukere skal få tilgang til Microsoft 365-tjenester via direkteruting eller indirekte programproxy for både Internett- og ExpressRoute-flyter.
Legg til plasseringen til leieren og møt-meg-plasseringene i nettverksdiagrammet.
Estimer de forventede og observerte egenskapene for nettverksytelse og ventetid fra viktige brukerplasseringer til Microsoft 365. Husk at Microsoft 365 er et globalt og distribuert sett med tjenester, og brukere vil koble til plasseringer som kan være forskjellige fra plasseringen til leieren. Derfor anbefales det å måle og optimalisere for ventetid mellom brukeren og den nærmeste kanten av Microsofts globale nettverk via ExpressRoute- og Internett-tilkoblinger. Du kan bruke resultatene fra nettverksvurderingen til å hjelpe til med denne oppgaven.
List opp firmaets nettverkssikkerhet og høye tilgjengelighetskrav som må oppfylles med den nye ExpressRoute-tilkoblingen. Hvordan kan brukere for eksempel fortsette å få tilgang til Microsoft 365 hvis det oppstår en feil i utgående internett- eller ExpressRoute-kretsen.
Dokumenter hvilke inngående og utgående Microsoft 365-nettverksflyter som skal bruke Internett-banen, og som skal bruke ExpressRoute. Detaljene for brukernes geografiske plasseringer og detaljer om den lokale nettverkstopologien kan kreve at planen er forskjellig fra én brukerplassering til en annen.
Katalogisere utgående og inngående nettverkstrafikk
For å minimere ruting og andre nettverkskompleksiteter anbefaler vi at du bare bruker ExpressRoute for Microsoft 365 for nettverkstrafikkflytene som kreves for å gå over en dedikert tilkobling på grunn av forskriftsmessige krav eller som resultat av nettverksvurderingen. I tillegg anbefaler vi at du faser omfanget av ExpressRoute-ruting og tilnærming utgående og inngående nettverkstrafikkflyter som forskjellige og distinkte stadier av implementeringsprosjektet. Distribuer ExpressRoute for Microsoft 365 for bare brukerstartede utgående nettverkstrafikkflyter, og la inngående nettverkstrafikkflyter over Hele Internett bidra til å kontrollere økningen i topologisk kompleksitet og risiko ved å innføre ytterligere asymmetriske rutingmuligheter.
Nettverkstrafikkkatalogen skal inneholde lister over alle innkommende og utgående nettverkstilkoblinger som du har mellom det lokale nettverket og Microsoft.
Utgående nettverkstrafikkflyter er alle scenarioer der en tilkobling startes fra det lokale miljøet, for eksempel fra interne klienter eller servere, med et mål for Microsoft-tjenestene. Disse tilkoblingene kan være direkte til Microsoft 365 eller indirekte, for eksempel når tilkoblingen går gjennom proxy-servere, brannmurer eller andre nettverksenheter på banen til Microsoft 365.
Innkommende nettverkstrafikkflyter er alle scenarioer der en tilkobling startes fra Microsoft-skyen til en lokal vert. Disse tilkoblingene må vanligvis gå gjennom brannmuren og annen sikkerhetsinfrastruktur som kundens sikkerhetspolicy krever for flyter med ekstern opprinnelse.
Les delen Sikre rutesymmetri for å finne ut hvilke tjenester som skal sende inngående trafikk, og se etter kolonnen merket ExpressRoute for Microsoft 365 i referanseartikkelen for Microsoft 365-endepunkter for å finne ut resten av tilkoblingsinformasjonen.
For hver tjeneste som krever en utgående tilkobling, bør du beskrive den planlagte tilkoblingen for tjenesten, inkludert nettverksruting, proxy-konfigurasjon, pakkeinspeksjon og båndbreddebehov.
For hver tjeneste som krever en inngående tilkobling, trenger du litt mer informasjon. Servere i Microsoft-skyen etablerer tilkoblinger til det lokale nettverket. Hvis du vil sikre at tilkoblingene gjøres riktig, bør du beskrive alle aspekter ved denne tilkoblingen, inkludert de offentlige DNS-oppføringene for tjenestene som godtar disse inngående tilkoblingene, CIDR-formaterte IPv4 IP-adresser, hvilket ISP-utstyr som er involvert, og hvordan innkommende NAT eller kilde-NAT håndteres for disse tilkoblingene.
Innkommende tilkoblinger bør gjennomgås uavhengig av om de kobler til via Internett eller ExpressRoute for å sikre at asymmetrisk ruting ikke er innført. I noen tilfeller kan det hende at lokale endepunkter som Microsoft 365-tjenester starter innkommende tilkoblinger til, også må åpnes av andre Microsoft- og ikke-Microsoft-tjenester. Det er avgjørende at aktivering av ExpressRoute-ruting til disse tjenestene for Microsoft 365-formål ikke bryter andre scenarioer. I mange tilfeller kan det hende at kunder må implementere spesifikke endringer i det interne nettverket, for eksempel kildebasert NAT, for å sikre at inngående flyter fra Microsoft forblir symmetriske etter at ExpressRoute er aktivert.
Her er et eksempel på detaljnivået som kreves. I dette tilfellet rutes Exchange Hybrid til det lokale systemet via ExpressRoute.
| Tilkoblingsegenskap | Verdi |
|---|---|
| Nettverkstrafikkretning |
Innkommende |
| Tjeneste |
Exchange Hybrid |
| Offentlig Microsoft 365-endepunkt (kilde) |
Exchange Online (IP-adresser) |
| Offentlig lokalt endepunkt (mål) |
5.5.5.5 |
| Offentlig DNS-oppføring (Internett) |
Autodiscover.contoso.com |
| Vil dette lokale endepunktet brukes av andre (ikke Microsoft 365) Microsoft-tjenester |
Nei |
| Vil dette lokale endepunktet brukes av brukere/systemer på Internett |
Ja |
| Interne systemer publisert gjennom offentlige endepunkter |
Exchange Server klienttilgangsrolle (lokal) 192.168.101, 192.168.102, 192.168.103 |
| IP-annonsering av det offentlige endepunktet |
Til Internett: 5.5.0.0/16 To ExpressRoute: 5.5.5.0/24 |
| Kontroller for sikkerhet/perimeter |
Internettbane: DeviceID_002 ExpressRoute-bane: DeviceID_003 |
| Høy tilgjengelighet |
Aktiv/aktiv på tvers av to georedundante / ExpressRoute-kretser - Chicago og Dallas |
| Banesymmetrikontroll |
Metode: Kilde NAT Internett-bane: Kilde NAT inngående tilkoblinger til 192.168.5.5 ExpressRoute bane: Kilde NAT tilkoblinger til 192.168.1.0 (Chicago) og 192.168.2.0 (Dallas) |
Her er et eksempel på en tjeneste som bare er utgående:
| Tilkoblingsegenskap | Verdi |
|---|---|
| Nettverkstrafikkretning |
Utgående |
| Tjeneste |
SharePoint |
| Lokalt endepunkt (kilde) |
Brukerarbeidsstasjon |
| Offentlig Microsoft 365-endepunkt (mål) |
SharePoint (IP-adresser) |
| Offentlig DNS-oppføring (Internett) |
*.sharepoint.com (og flere FQDN-er) |
| CDN-henvisninger |
cdn.sharepointonline.com (og flere FQDN-er) – IP-adresser vedlikeholdt av CDN-leverandører) |
| IP-reklame og NAT i bruk |
Internettbane/kilde-NAT: 1.1.1.0/24 ExpressRoute bane/ Kilde NAT: 1.1.2.0/24 (Chicago) og 1.1.3.0/24 (Dallas) |
| Tilkoblingsmetode |
Internett: via proxy for lag 7 (PAC-fil) ExpressRoute: direkteruting (ingen proxy) |
| Kontroller for sikkerhet/perimeter |
Internett-bane: DeviceID_002 ExpressRoute-bane: DeviceID_003 |
| Høy tilgjengelighet |
Internettbane: Redundant internett-utgående ExpressRoute-bane: Aktiv/aktiv "varm potet" ruting over 2 georedundante ExpressRoute-kretser - Chicago og Dallas |
| Banesymmetrikontroll |
Metode: Kilde-NAT for alle tilkoblinger |
Din nettverkstopologiutforming med regional tilkobling
Når du forstår tjenestene og de tilknyttede trafikkflytene for nettverket, kan du opprette et nettverksdiagram som inneholder disse nye tilkoblingskravene og illustrerer endringene du gjør for å bruke ExpressRoute for Microsoft 365. Diagrammet skal omfatte:
Alle brukerplasseringer der Microsoft 365 og andre tjenester åpnes fra.
Alle internett- og ExpressRoute-utgangspunkter.
Alle utgående og inngående enheter som administrerer tilkobling inn og ut av nettverket, inkludert rutere, brannmurer, programproxyservere og gjenkjenning/forebygging av inntrenging.
Interne mål for all inngående trafikk, for eksempel interne ADFS-servere som godtar tilkoblinger fra proxy-serverne for ADFS-webprogrammet.
Katalog over alle IP-delnett som vil bli annonsert
Identifiser hver plassering der personer får tilgang til Microsoft 365 fra, og list opp møt-meg-plasseringene som skal brukes for ExpressRoute.
Plasseringer og deler av den interne nettverkstopologien, der Microsoft IP-prefikser som er lært fra ExpressRoute, godtas, filtreres og overføres til.
Nettverkstopologien skal illustrere den geografiske plasseringen til hvert nettverkssegment og hvordan det kobles til Microsoft-nettverket via ExpressRoute og/eller Internett.
Diagrammet nedenfor viser hver plassering der personer skal bruke Microsoft 365 sammen med innkommende og utgående rutingannonser til Microsoft 365.
For utgående trafikk får personene tilgang til Microsoft 365 på én av tre måter:
Gjennom et møt-meg sted i Nord-Amerika for folk i California.
Gjennom en møt-meg plassering i Hong Kong Special Administrative Region for personer i Hong Kong SAR.
Via Internett i Bangladesh der det er færre personer og ingen ExpressRoute krets klargjort.
På samme måte returnerer den inngående nettverkstrafikken fra Microsoft 365 på én av tre måter:
Gjennom et møt-meg sted i Nord-Amerika for folk i California.
Gjennom en møt-meg plassering i Hong Kong Special Administrative Region for personer i Hong Kong SAR.
Via Internett i Bangladesh der det er færre personer og ingen ExpressRoute krets klargjort.
Bestem riktig møt-meg-plassering
Valget av møt-meg-plasseringer, som er den fysiske plasseringen der ExpressRoute-kretsen kobler nettverket til Microsoft-nettverket, påvirkes av plasseringene der personer får tilgang til Microsoft 365 fra. Som et SaaS-tilbud opererer ikke Microsoft 365 under den regionale IaaS- eller PaaS-modellen på samme måte som Azure gjør. I stedet er Microsoft 365 et distribuert sett med samarbeidstjenester, der brukere kanskje må koble til endepunkter på tvers av flere datasentre og områder, som kanskje ikke nødvendigvis er på samme sted eller område der brukerens leier driftes.
Dette betyr at det viktigste du må ta når du velger møt-meg-plasseringer for ExpressRoute for Microsoft 365, er hvor personene i organisasjonen kobler seg til. Den generelle anbefalingen for optimal Microsoft 365-tilkobling er å implementere ruting, slik at brukerforespørsler til Microsoft 365-tjenester blir overlevert til Microsoft-nettverket over den korteste nettverksbanen, dette blir også ofte referert til som "varm potet" ruting. Hvis for eksempel de fleste Microsoft 365-brukerne befinner seg på én eller to plasseringer, vil det å velge møt-meg-plasseringer som er nærmest plasseringen til disse brukerne, skape den optimale utformingen. Hvis firmaet har store brukerpopulasjoner i mange forskjellige områder, bør du vurdere å ha flere ExpressRoute-kretser og møt-meg-plasseringer. Den korteste/mest optimale banen til Microsoft-nettverket og Microsoft 365 er kanskje ikke gjennom dine interne WAN- og ExpressRoute-møtepunkter, men via Internett.
Det finnes ofte flere møt-meg-plasseringer som kan velges innenfor et område med relativ nærhet til brukerne. Fyll ut tabellen nedenfor for å veilede avgjørelsene dine.
Planlagte ExpressRoute meet-me-steder i California og New York
| Plasseringen |
Antall personer |
Forventet ventetid for Microsoft-nettverk over utgående Internett-trafikk |
Forventet ventetid for Microsoft-nettverk via ExpressRoute |
|---|---|---|---|
| Los Angeles |
10,000 |
~15 ms |
~10 ms (via Silicon Valley) |
| Washington DC |
15,000 |
~20 ms |
~10 ms (via New York) |
| Dallas |
5,000 |
~15 ms |
~40 ms (via New York) |
Når den globale nettverksarkitekturen som viser Microsoft 365-området, tjenesteleverandøren for ExpressRoute møter meg plasseringer, og antall personer etter plassering er utviklet, kan den brukes til å identifisere om det kan gjøres optimaliseringer. Det kan også vise globale hårnålsnettverkstilkoblinger der trafikken ruter til et fjernt sted for å få møt-meg-plasseringen. Hvis en hårnål på det globale nettverket oppdages, bør den utbedres før du fortsetter. Enten finne en annen møt-meg plassering, eller bruke selektive Internett breakout utgående punkter for å unngå hårnål.
Det første diagrammet viser et eksempel på en kunde med to fysiske plasseringer i Nord-Amerika. Du kan se informasjonen om kontorplasseringer, Microsoft 365-leierplasseringer og flere valg for ExpressRoute meet-me-plasseringer. I dette eksemplet har kunden valgt møt-meg-plasseringen basert på to prinsipper, i rekkefølge:
Nærmeste nærhet til personene i organisasjonen.
Nærmest i nærheten av et Microsoft-datasenter der Microsoft 365 driftes.
Hvis du utvider dette konseptet litt lenger, viser det andre diagrammet et eksempel på at en flernasjonal kunde står overfor lignende informasjon og beslutningstaking. Denne kunden har et lite kontor i Bangladesh med bare et lite team på 10 personer fokusert på å øke sitt fotavtrykk i regionen. Det er en møt-meg-plassering i Chennai og et Microsoft-datasenter med Microsoft 365 driftet i Chennai, slik at en møt-meg-plassering ville være fornuftig; Men for 10 personer er bekostning av den ekstra kretsen tyngende. Når du ser på nettverket, må du finne ut om ventetiden som er involvert i å sende nettverkstrafikken over nettverket, er mer effektiv enn å bruke kapitalen til å skaffe seg en annen ExpressRoute-krets.
Alternativt kan de 10 personene i Bangladesh oppleve bedre ytelse med nettverkstrafikken sendt over Internett til Microsoft-nettverket enn de ville rute på sitt interne nettverk som vi viste i de innledende diagrammene og gjengitt nedenfor.
Opprett implementeringsplanen for ExpressRoute for Microsoft 365
Implementeringsplanen bør omfatte både de tekniske detaljene for konfigurering av ExpressRoute og detaljene for konfigurering av all annen infrastruktur på nettverket, for eksempel følgende.
Planlegg hvilke tjenester som er delt mellom ExpressRoute og Internett.
Planlegg båndbredde, sikkerhet, høy tilgjengelighet og failover.
Utform inngående og utgående ruting, inkludert riktige rutingbaneoptimaliseringer for ulike plasseringer
Bestem hvor langt ExpressRoute-ruter skal annonseres inn i nettverket og hva som er mekanismen for klienter å velge Internett- eller ExpressRoute-bane. for eksempel direkte ruting eller programproxy.
Planlegg endringer i DNS-poster, inkludert oppføringer i rammeverket for avsenderpolicy .
Planlegg NAT-strategi, inkludert utgående og inngående kilde-NAT.
Planlegge rutingen med både Internett- og ExpressRoute-nettverksbaner
For den første distribusjonen anbefales alle innkommende tjenester, for eksempel innkommende e-post eller hybridtilkobling, å bruke Internett.
Planlegg lan-ruting for sluttbrukerklient, for eksempel konfigurering av en PAC/WPAD-fil, standardrute, proxy-servere og BGP-ruteannonser.
Planlegg perimeterruting, inkludert proxy-servere, brannmurer og skyproxyer.
Planlegge båndbredde, sikkerhet, høy tilgjengelighet og failover
Opprett en plan for båndbredde som kreves for hver større Microsoft 365-arbeidsbelastning. Beregne Exchange Online, SharePoint og Skype for Business Online båndbreddekrav separat. Du kan bruke beregningskalkulatorene vi har angitt for Exchange Online og Skype for Business som et utgangspunkt. En pilottest med et representativt utvalg av brukerprofiler og plasseringer kreves imidlertid for å forstå båndbreddebehovene til organisasjonen.
Legg til hvordan sikkerhet håndteres på hver internett- og ExpressRoute-utgående plassering i planen, husk at alle ExpressRoute-tilkoblinger til Microsoft 365 bruker offentlig nodefordeling og må fortsatt sikres i samsvar med firmaets sikkerhetspolicyer for å koble til eksterne nettverk.
Legg til detaljer i planen om hvilke personer som vil bli påvirket av hva slags strømbrudd og hvordan disse personene vil kunne utføre arbeidet sitt på full kapasitet på den enkleste måten.
Planlegg båndbreddekrav, inkludert Skype for Business krav til jitter, ventetid, overbelastning og takhøyde
Skype for Business Online har også spesifikke ekstra nettverkskrav, som er beskrevet i artikkelen Mediekvalitet og nettverkstilkoblingsytelse i Skype for Business Online.
Les delen Båndbreddeplanlegging for Azure ExpressRoute. Når du utfører en båndbreddevurdering med pilotbrukerne, kan du bruke vår veiledning for ytelsesjustering for Microsoft 365 ved hjelp av grunnlinjer og ytelseslogg.
Planlegg for høye tilgjengelighetskrav
Opprett en plan for høy tilgjengelighet for å dekke dine behov og innlemme dette i det oppdaterte nettverkstopologidiagrammet. Les delen Høy tilgjengelighet og failover med Azure ExpressRoute.
Planlegg for sikkerhetskrav for nettverk
Opprett en plan for å oppfylle dine krav til nettverkssikkerhet og innlemme dette i det oppdaterte nettverkstopologidiagrammet. Les delen Bruke sikkerhetskontroller på Azure ExpressRoute for Microsoft 365-scenarioer.
Utform tilkobling for utgående tjeneste
ExpressRoute for Microsoft 365 har utgående nettverkskrav som kan være ukjente. IP-adressene som representerer brukerne og nettverkene dine til Microsoft 365 og fungerer som kildeendepunkter for utgående nettverkstilkoblinger til Microsoft, må følge spesifikke krav som er beskrevet nedenfor.
Endepunktene må være offentlige IP-adresser som er registrert i firmaet eller til operatøren som tilbyr ExpressRoute-tilkobling til deg.
Endepunktene må annonseres til Microsoft og valideres/godtas av ExpressRoute.
Endepunktene må ikke annonseres til Internett med samme eller flere foretrukne rutingmåledata.
Endepunktene må ikke brukes for tilkobling til Microsoft-tjenester som ikke er konfigurert via ExpressRoute.
Hvis nettverksutformingen ikke oppfyller disse kravene, er det en høy risiko for at brukerne opplever tilkoblingsfeil til Microsoft 365 og andre Microsoft-tjenester på grunn av rute svart holing eller asymmetrisk ruting. Dette skjer når forespørsler til Microsoft-tjenester rutes via ExpressRoute, men svar rutes tilbake over Internett, eller omvendt, og svarene slippes av tilstandsfulle nettverksenheter som brannmurer.
Den vanligste metoden du kan bruke for å oppfylle kravene ovenfor, er å bruke kilde-NAT, enten implementert som en del av nettverket eller levert av ExpressRoute-operatøren. Kilde-NAT lar deg abstrahere detaljer og privat IP-adressering av Internett-nettverket fra ExpressRoute og; sammen med riktige IP-ruteannonser gir du en enkel mekanisme for å sikre banesymmetri. Hvis du bruker tilstandsfulle nettverksenheter som er spesifikke for ExpressRoute-nodeplasseringer, må du implementere separate NAT-utvalg for hver ExpressRoute-nodenetting for å sikre banesymmetri.
Les mer om Nat-kravene for ExpressRoute.
Legg til endringene for den utgående tilkoblingen i diagrammet for nettverkstopologi.
Utform innkommende tjenestetilkobling
De fleste Microsoft 365-distribusjoner for bedrifter forutsetter en form for innkommende tilkobling fra Microsoft 365 til lokale tjenester, for eksempel for Exchange, SharePoint og Skype for Business hybridscenarioer, postboksoverføringer og godkjenning ved hjelp av ADFS-infrastruktur. Når Du aktiverer en ekstra rutingbane mellom det lokale nettverket og Microsoft for utgående tilkobling, kan disse inngående tilkoblingene utilsiktet bli påvirket av asymmetrisk ruting, selv om du har tenkt å la disse flytene fortsette å bruke Internett. Noen forholdsregler beskrevet nedenfor anbefales for å sikre at det ikke er noen innvirkning på Internett-baserte inngående flyter fra Microsoft 365 til lokale systemer.
For å minimere risikoen for asymmetrisk ruting for innkommende nettverkstrafikkflyter, bør alle innkommende tilkoblinger bruke kilde-NAT før de rutes til segmenter av nettverket, som har rutingsynlighet i ExpressRoute. Hvis innkommende tilkoblinger tillates på et nettverkssegment med rutingsynlighet i ExpressRoute uten kilde-NAT, kommer forespørsler med opprinnelse fra Microsoft 365 inn fra Internett, men svaret som går tilbake til Microsoft 365, foretrekker ExpressRoute-nettverksbanen tilbake til Microsoft-nettverket, noe som forårsaker asymmetrisk ruting.
Du kan vurdere ett av følgende implementeringsmønstre for å oppfylle dette kravet:
Utfør kilde-NAT før forespørsler rutes inn i det interne nettverket ved hjelp av nettverksutstyr, for eksempel brannmurer eller belastningsfordelinger på banen fra Internett til lokale systemer.
Kontroller at ExpressRoute-ruter ikke overføres til nettverkssegmentene der inngående tjenester, for eksempel frontservere eller omvendte proxy-systemer, håndterer Internett-tilkoblinger.
Eksplisitt regnskap for disse scenariene i nettverket og holde alle innkommende nettverkstrafikkflyter over Internett bidrar til å minimere distribusjon og operasjonell risiko for asymmetrisk ruting.
Det kan være tilfeller der du kan velge å dirigere noen inngående flyter over ExpressRoute-tilkoblinger. For disse scenariene må du ta hensyn til følgende ekstra hensyn.
Microsoft 365 kan bare målrette mot lokale endepunkter som bruker offentlige IP-er. Dette betyr at selv om det lokale inngående endepunktet bare eksponeres for Microsoft 365 over ExpressRoute, må det fortsatt ha offentlig IP tilknyttet.
All DNS-navneløsing som Microsoft 365-tjenester utfører for å løse lokale endepunkter, skjer ved hjelp av offentlig DNS. Dette betyr at du må registrere inngående tjenesteendepunkters FQDN til IP-tilordninger på Internett.
Hvis du vil motta inngående nettverkstilkoblinger via ExpressRoute, må de offentlige IP-delnettene for disse endepunktene annonseres til Microsoft via ExpressRoute.
Evaluer disse inngående nettverkstrafikkflytene nøye for å sikre at riktig sikkerhet og nettverkskontroller brukes på dem i henhold til firmaets sikkerhets- og nettverkspolicyer.
Når de lokale inngående endepunktene er annonsert til Microsoft via ExpressRoute, blir ExpressRoute effektivt den foretrukne rutingbanen til disse endepunktene for alle Microsoft-tjenester, inkludert Microsoft 365. Dette betyr at disse delnettene for endepunkt bare må brukes til kommunikasjon med Microsoft 365-tjenester og ingen andre tjenester på Microsoft-nettverket. Ellers vil utformingen føre til asymmetrisk ruting der inngående tilkoblinger fra andre Microsoft-tjenester foretrekker å rute inngående via ExpressRoute, mens returbanen bruker Internett.
Hvis en ExpressRoute-krets eller møt-meg-plassering er nede, må du sørge for at de lokale inngående endepunktene fortsatt er tilgjengelige for å godta forespørsler over en egen nettverksbane. Dette kan bety annonsering av delnett for disse endepunktene gjennom flere ExpressRoute-kretser.
Vi anbefaler at du bruker kilde-NAT for alle innkommende nettverkstrafikkflyter som kommer inn i nettverket via ExpressRoute, spesielt når disse flytene krysser tilstandsfulle nettverksenheter, for eksempel brannmurer.
Noen lokale tjenester, for eksempel ADFS-proxy eller Exchange-autosøk, kan motta inngående forespørsler fra både Microsoft 365-tjenester og brukere fra Internett. For disse forespørslene vil Microsoft 365 rette seg mot samme FQDN som brukerforespørsler via Internett. Å tillate innkommende brukertilkoblinger fra Internett til de lokale endepunktene, samtidig som Microsoft 365-tilkoblinger tvinges til å bruke ExpressRoute, representerer betydelig rutingkompleksitet. For de aller fleste kunder anbefales ikke implementering av slike komplekse scenarier over ExpressRoute på grunn av operasjonelle hensyn. Denne ekstra belastningen omfatter administrasjon av risikoer for asymmetrisk ruting, og krever at du håndterer rutingannonser og policyer nøye på tvers av flere dimensjoner.
Oppdater nettverkstopologiplanen for å vise hvordan du unngår asymmetriske ruter
Du vil unngå asymmetrisk ruting for å sikre at personer i organisasjonen sømløst kan bruke Microsoft 365 samt andre viktige tjenester på Internett. Det finnes to vanlige konfigurasjoner kunder har som forårsaker asymmetrisk ruting. Nå er det på tide å se gjennom nettverkskonfigurasjonen du planlegger å bruke, og kontrollere om ett av disse asymmetriske rutingscenarioene kan finnes.
Til å begynne med skal vi undersøke et par ulike situasjoner knyttet til følgende nettverksdiagram. I dette diagrammet er alle servere som mottar inngående forespørsler, for eksempel ADFS eller lokale hybridservere, i New Jersey-datasenteret og er annonsert til Internett.
Selv om perimeternettverket er sikkert, er det ingen kilde-NAT tilgjengelig for innkommende forespørsler.
Serverne i New Jersey-datasenteret kan se både Internett- og ExpressRoute-ruter.
Vi har også forslag til hvordan du løser dem.
Problem 1: Skybasert til lokal tilkobling via Internett
Diagrammet nedenfor illustrerer den asymmetriske nettverksbanen som tas når nettverkskonfigurasjonen ikke gir NAT for inngående forespørsler fra Microsoft-skyen via Internett.
Den inngående forespørselen fra Microsoft 365 henter IP-adressen til det lokale endepunktet fra offentlig DNS og sender forespørselen til perimeternettverket.
I denne feilkonfigurasjonen er det ingen kilde-NAT konfigurert eller tilgjengelig på perimeternettverket der trafikken sendes, noe som resulterer i at den faktiske kilde-IP-adressen brukes som returmål.
Serveren på nettverket ruter returtrafikken til Microsoft 365 via en hvilken som helst tilgjengelig ExpressRoute-nettverkstilkobling.
Resultatet er en asymmetrisk bane for denne flyten til Microsoft 365, noe som resulterer i en brutt tilkobling.
Løsning 1a: Kilde-NAT
Hvis du legger til en kilde-NAT i den inngående forespørselen, løses dette feilkonfigurerte nettverket. I dette diagrammet:
Den innkommende forespørselen fortsetter å komme inn gjennom New Jersey-datasenterets perimeternettverk. Denne gangen er kilde-NAT tilgjengelig.
Svaret fra serveren ruter tilbake mot IP-adressen som er knyttet til kilde-NAT i stedet for den opprinnelige IP-adressen, noe som resulterer i at svaret returneres langs samme nettverksbane.
Løsning 1b: Rute omfang
Alternativt kan du velge å ikke tillate expressroute BGP-prefikser som skal annonseres, og fjerne den alternative nettverksbanen for disse datamaskinene. I dette diagrammet:
Den innkommende forespørselen fortsetter å komme inn gjennom New Jersey-datasenterets perimeternettverk. Denne gangen er ikke prefiksene annonsert fra Microsoft over ExpressRoute-kretsen tilgjengelige for New Jersey-datasenteret.
Svaret fra serveren ruter tilbake mot IP-adressen som er knyttet til den opprinnelige IP-adressen over den eneste tilgjengelige ruten, noe som resulterer i at svaret returnerer langs samme nettverksbane.
Problem 2: Skybasert til lokal tilkobling via ExpressRoute
Diagrammet nedenfor illustrerer den asymmetriske nettverksbanen som tas når nettverkskonfigurasjonen ikke gir NAT for inngående forespørsler fra Microsoft-skyen over ExpressRoute.
Den inngående forespørselen fra Microsoft 365 henter IP-adressen fra DNS og sender forespørselen til perimeternettverket.
I denne feilkonfigurasjonen er det ingen kilde-NAT konfigurert eller tilgjengelig på perimeternettverket der trafikken sendes, noe som resulterer i at den faktiske kilde-IP-adressen brukes som returmål.
Datamaskinen på nettverket ruter returtrafikken til Microsoft 365 via en hvilken som helst tilgjengelig ExpressRoute-nettverkstilkobling.
Resultatet er en asymmetrisk tilkobling til Microsoft 365.
Løsning 2: Kilde-NAT
Hvis du legger til en kilde-NAT i den inngående forespørselen, løses dette feilkonfigurerte nettverket. I dette diagrammet:
Den innkommende forespørselen fortsetter å komme inn gjennom New York-datasenterets perimeternettverk. Denne gangen er kilde-NAT tilgjengelig.
Svaret fra serveren ruter tilbake mot IP-adressen som er knyttet til kilde-NAT i stedet for den opprinnelige IP-adressen, noe som resulterer i at svaret returneres langs samme nettverksbane.
Papir kontroller at nettverksutformingen har banesymmetri
På dette tidspunktet må du bekrefte på papir at implementeringsplanen tilbyr rutesymmetri for de ulike scenariene der du skal bruke Microsoft 365. Du identifiserer den spesifikke nettverksruten som forventes å bli tatt når en person bruker forskjellige funksjoner i tjenesten. Fra det lokale nettverket og WAN-ruting, til perimeterenhetene, til tilkoblingsbanen; ExpressRoute eller Internett og videre til tilkoblingen til det nettbaserte endepunktet.
Du må gjøre dette for alle Microsoft 365-nettverkstjenestene som tidligere ble identifisert som tjenester som organisasjonen vil ta i bruk.
Det hjelper å gjøre denne papirgjennomgangen av ruter med en annen person. Forklar dem hvor hvert nettverkshopp forventes å få sin neste rute fra, og sørg for at du er kjent med rutingbanene. Husk at ExpressRoute alltid vil gi en mer omfangsfang rute til Microsoft server IP-adresser som gir den lavere rutekostnad enn en Internett-standardrute.
Konfigurasjon av utformingsklienttilkobling
Hvis du bruker en proxy-server for Internett-bundet trafikk, må du justere eventuelle PAC- eller klientkonfigurasjonsfiler for å sikre at klientdatamaskiner på nettverket er riktig konfigurert til å sende ExpressRoute-trafikken du ønsker til Microsoft 365 uten å overføre proxy-serveren, og den gjenværende trafikken, inkludert noe Microsoft 365-trafikk, sendes til den aktuelle proxyen. Les veiledningen vår om administrasjon av Microsoft 365-endepunkter, for eksempel PAC-filer.
Obs!
Endepunktene endres ofte, så ofte som ukentlig. Du bør bare gjøre endringer basert på tjenestene og funksjonene organisasjonen har tatt i bruk for å redusere antall endringer du må gjøre for å holde deg oppdatert. Vær oppmerksom på den gjeldende datoen i RSS-feeden der endringene leses opp, og en post oppbevares av alle tidligere endringer, IP-adresser som leses opp, kan ikke annonseres eller fjernes fra annonser før gjeldende dato er nådd.
Sikre rutesymmetri
Microsoft 365-frontserverne er tilgjengelige både på Internett og ExpressRoute. Disse serverne foretrekker å rute tilbake til lokale kretser over ExpressRoute når begge er tilgjengelige. På grunn av dette er det en mulighet for ruteasymmetri hvis trafikk fra nettverket ditt foretrekker å rute over Internett-kretser. Asymmetriske ruter er et problem fordi enheter som utfører tilstandsfull pakkeinspeksjon, kan blokkere returtrafikk som følger en annen bane enn de utgående pakkene fulgte.
Uavhengig av om du starter en tilkobling til Microsoft 365 via Internett eller ExpressRoute, må kilden være en offentlig rutbar adresse. Med mange kunder som bruker nodefordeling direkte med Microsoft, er det ikke mulig å ha private adresser der duplisering er mulig mellom kunder.
Følgende er scenarioer der kommunikasjon fra Microsoft 365 til det lokale nettverket startes. For å forenkle nettverksutformingen anbefaler vi at du ruter følgende via Internett-banen.
SMTP-tjenester som e-post fra en Exchange Online leier til en lokal vert eller SharePoint Mail sendt fra SharePoint til en lokal vert. SMTP-protokollen brukes bredere i Microsofts nettverk enn ruteprefiksene som deles over ExpressRoute-kretser og annonsering av lokale SMTP-servere over ExpressRoute, vil føre til feil med disse andre tjenestene.
ADFS under passordvalidering for pålogging.
Skype for Business hybrid og/eller Skype for Business forbund.
For at Microsoft skal kunne rute tilbake til nettverket for disse toveis trafikkflytene, må BGP-rutene til de lokale enhetene dine deles med Microsoft. Når du annonserer ruteprefikser til Microsoft over ExpressRoute, bør du følge disse anbefalte fremgangsmåtene:
Ikke annonser det samme offentlige IP-adresseruteprefikset til offentlig Internett og via ExpressRoute. Det anbefales at IP BGP Route Prefix-annonser til Microsoft over ExpressRoute er fra et område som ikke er annonsert til Internett i det hele tatt. Hvis dette ikke er mulig å oppnå på grunn av den tilgjengelige IP-adresseplassen, er det viktig å sikre at du annonserer et mer spesifikt område over ExpressRoute enn noen Internett-kretser.
Bruk separate NAT IP-utvalg per ExpressRoute-krets og atskilt fra Internett-kretser.
Alle ruter som er annonsert til Microsoft, tiltrekker seg nettverkstrafikk fra alle servere i Microsofts nettverk, ikke bare de som ruter er annonsert til nettverket via ExpressRoute. Bare annonser ruter til servere der rutingscenarioer defineres og forstås godt av teamet ditt. Annonser separate IP-adresseruteprefikser på hver av flere ExpressRoute-kretser fra nettverket.
Høy tilgjengelighet og failover med Azure ExpressRoute
Vi anbefaler at du klargjør minst to aktive kretser fra hver utgående effekt med ExpressRoute til ExpressRoute-leverandøren. Dette er det vanligste stedet vi ser feil for kunder, og du kan enkelt unngå det ved å klargjøre et par aktive/aktive ExpressRoute-kretser. Vi anbefaler også minst to aktive/aktive Internett-kretser fordi mange Microsoft 365-tjenester bare er tilgjengelige via Internett.
Inne i utgangspunktet i nettverket er mange andre enheter og kretser som spiller en viktig rolle i hvordan folk oppfatter tilgjengelighet. Disse delene av tilkoblingsscenarioene dekkes ikke av ExpressRoute eller Microsoft 365 SLA-er, men de spiller en viktig rolle i ende-til-ende-tjenestetilgjengelighet som oppfattes av personer i organisasjonen.
Fokuser på personene som bruker og drifter Microsoft 365, hvis en feil i en komponent vil påvirke brukernes opplevelse ved hjelp av tjenesten, se etter måter å begrense den totale prosentandelen av berørte personer på. Hvis en failover-modus er operasjonelt kompleks, bør du vurdere folks opplevelse av lang tid til utvinning og se etter operasjonelt enkle og automatiserte failover-moduser.
Utenfor nettverket har Microsoft 365, ExpressRoute og ExpressRoute-leverandøren alle forskjellige tilgjengelighetsnivåer.
Tjenestetilgjengelighet
Microsoft 365-tjenester dekkes av veldefinerte servicenivåavtaler, som inkluderer oppetid og tilgjengelighetsmåledata for individuelle tjenester. En grunn til at Microsoft 365 kan opprettholde slike høye tilgjengelighetsnivåer for tjenester, er muligheten for individuelle komponenter til sømløst å mislykkes mellom de mange Microsoft-datasentrene, ved hjelp av det globale Microsoft-nettverket. Denne failoveren strekker seg fra datasenteret og nettverket til flere utgående punkter på Internett, og muliggjør failover sømløst fra perspektivet til personene som bruker tjenesten.
ExpressRoute tilbyr en serviceavtale for 99,9 % tilgjengelighet på individuelle dedikerte kretser mellom Microsoft Network Edge og ExpressRoute-leverandøren eller partnerinfrastrukturen. Disse tjenestenivåene brukes på ExpressRoute-kretsnivå, som består av to uavhengige forbindelser mellom det overflødige Microsoft-utstyret og nettverksleverandørutstyret på hver nodeplassering.
Leverandørtilgjengelighet
- Microsofts servicenivåordninger stopper hos ExpressRoute-leverandøren eller -partneren. Dette er også det første stedet du kan foreta valg som vil påvirke tilgjengelighetsnivået ditt. Du bør evaluere arkitekturen, tilgjengeligheten og robusthetsegenskapene som ExpressRoute-leverandøren tilbyr mellom nettverksperimeteren og leverandørtilkoblingen på hver Nodeplassering for Microsoft. Vær oppmerksom på både de logiske og fysiske aspektene ved redundans, nodeutstyr, transportør-leverte WAN-kretser og eventuelle ekstra verditilleggstjenester som NAT-tjenester eller administrerte brannmurer.
Utforme tilgjengelighetsplanen
Vi anbefaler på det sterkeste at du planlegger og utformer høy tilgjengelighet og robusthet i ende-til-ende-tilkoblingsscenarioene for Microsoft 365. En utforming bør inkludere;
Ingen enkle feilpunkter, inkludert både Internett- og ExpressRoute-kretser.
Minimere antall personer som påvirkes, og varigheten av denne innvirkningen for de mest etterlengtede feilmodusene.
Optimalisering for enkel, gjentakende og automatisk gjenopprettingsprosess fra de mest etterlengtede feilmodusene.
Støtte de fulle kravene til nettverkstrafikken og funksjonaliteten gjennom overflødige baner, uten betydelig nedbrytning.
Tilkoblingsscenarioene bør inneholde en nettverkstopologi som er optimalisert for flere uavhengige og aktive nettverksbaner til Microsoft 365. Dette vil gi en bedre ende-til-ende-tilgjengelighet enn en topologi som bare er optimalisert for redundans på individuelt enhets- eller utstyrsnivå.
Tips
Hvis brukerne distribueres på tvers av flere kontinenter eller geografiske områder, og hver av disse plasseringene kobles over redundante WAN-kretser til én enkelt lokal plassering der en enkelt ExpressRoute-krets er plassert, vil brukerne oppleve mindre ende-til-ende-tjenestetilgjengelighet enn en nettverkstopologiutforming som inkluderer uavhengige ExpressRoute-kretser som kobler de forskjellige områdene til nærmeste nodeplassering.
Vi anbefaler at du klargjør minst to ExpressRoute-kretser med hver krets som kobles til med en annen geografisk nodeplassering. Du bør klargjøre dette aktive kretsparet for hvert område der personer skal bruke ExpressRoute-tilkobling for Microsoft 365-tjenester. Dette gjør at hvert område kan forbli tilkoblet under en katastrofe som påvirker en viktig plassering, for eksempel et datasenter eller en nodeplassering. Hvis du konfigurerer dem som aktive/aktive, kan sluttbrukertrafikken distribueres på tvers av flere nettverksbaner. Dette reduserer omfanget av personer som påvirkes under enhets- eller nettverksutstyrsbrudd.
Vi anbefaler ikke å bruke én enkelt ExpressRoute-krets med Internett som en sikkerhetskopi.
Eksempel: Failover og høy tilgjengelighet
Contosos multi-geografiske utforming har gjennomgått en gjennomgang av ruting, båndbredde, sikkerhet, og må nå gå gjennom en gjennomgang av høy tilgjengelighet. Contoso tenker på høy tilgjengelighet som dekker tre kategorier. robusthet, pålitelighet og redundans.
Robusthet gjør det mulig for Contoso å komme seg raskt etter feil. Med pålitelighet kan Contoso tilby et konsekvent resultat i systemet. Med redundans kan Contoso flytte mellom én eller flere speilede forekomster av infrastruktur.
I hver edge-konfigurasjon har Contoso redundante brannmurer, proxyer og IDS. For Nord-Amerika har Contoso én edge-konfigurasjon i sitt Dallas-datasenter og en annen edge-konfigurasjon i sitt Virginia-datasenter. Det overflødige utstyret på hvert sted gir robusthet til dette stedet.
Nettverkskonfigurasjonen hos Contoso er bygget basert på noen viktige prinsipper:
Det finnes flere Azure ExpressRoute-kretser innenfor hvert geografisk område.
Hver krets i et område kan støtte all nettverkstrafikk innenfor dette området.
Ruting foretrekker tydeligvis én eller den andre banen avhengig av tilgjengelighet, plassering og så videre.
Failover mellom Azure ExpressRoute-kretser skjer automatisk uten ekstra konfigurasjon eller handling som kreves av Contoso.
Failover mellom Internett-kretser skjer automatisk uten ekstra konfigurasjon eller handling som kreves av Contoso.
I denne konfigurasjonen, med redundans på fysisk og virtuelt nivå, kan Contoso tilby lokal robusthet, regional robusthet og global robusthet på en pålitelig måte. Contoso valgte denne konfigurasjonen etter å ha evaluert én enkelt Azure ExpressRoute-krets per område, i tillegg til muligheten for å mislykkes over internett.
Hvis Contoso ikke kunne ha flere Azure ExpressRoute-kretser per område, vil ruting av trafikk med opprinnelse i Nord-Amerika til Azure ExpressRoute-kretsen i Asia/Stillehavet legge til et uakseptabelt ventetidsnivå, og den nødvendige KONFIGURASJONen for DNS-videresending gir kompleksitet.
Det anbefales ikke å bruke Internett som sikkerhetskopikonfigurasjon. Dette bryter Contosos pålitelighetsprinsipp, noe som resulterer i en inkonsekvent opplevelse ved hjelp av tilkoblingen. I tillegg må manuell konfigurasjon mislykkes med tanke på BGP-annonsene som er konfigurert, NAT-konfigurasjon, DNS-konfigurasjon og proxy-konfigurasjonen. Denne ekstra failover-kompleksiteten øker tiden for å gjenopprette og reduserer muligheten til å diagnostisere og feilsøke trinnene som er involvert.
Har du fortsatt spørsmål om hvordan du planlegger og implementerer trafikkstyring eller Azure ExpressRoute? Les resten av våre nettverks- og ytelsesveiledninger eller vanlige spørsmål om Azure ExpressRoute.
Bruke sikkerhetskontroller på Azure ExpressRoute for Microsoft 365-scenarioer
Sikring av Azure ExpressRoute-tilkobling starter med de samme prinsippene som sikring av Internett-tilkobling. Mange kunder velger å distribuere nettverks- og perimeterkontroller langs ExpressRoute-banen som kobler det lokale nettverket til Microsoft 365 og andre Microsoft-skyer. Disse kontrollene kan omfatte brannmurer, programproxyer, hindring av datalekkasje, gjenkjenning av inntrenging, systemer for hindring av inntrenging og så videre. I mange tilfeller bruker kunder ulike nivåer av kontroller på trafikk initiert fra lokale til Microsoft, kontra trafikk initiert fra Microsoft går til kundens lokale nettverk, kontra trafikk initiert fra lokale går til en generell Internett-destinasjon.
Her er noen eksempler på integrering av sikkerhet med ExpressRoute-tilkoblingsmodellen du velger å distribuere.
| Integreringsalternativ for ExpressRoute | Perimetermodell for nettverkssikkerhet |
|---|---|
| Kolosset på en skyutveksling |
Installer ny eller bruk eksisterende infrastruktur for sikkerhet/perimeter i samlokaliseringsanlegget der ExpressRoute-tilkoblingen er etablert. Bruk samlokaliseringsanlegget utelukkende for ruting/sammenkoblingsformål og tilbakekoblingstilkoblinger fra samlokaliseringsanlegget til den lokale infrastrukturen for sikkerhet/perimeter. |
| Point-to-Point Ethernet |
Avslutt Point-to-Point ExpressRoute-tilkoblingen i den eksisterende lokale plasseringen for infrastruktur for sikkerhet/perimeter. Installer ny infrastruktur for sikkerhet/perimeter som er spesifikk for ExpressRoute-banen, og avslutt Point-to-Point-tilkoblingen der. |
| Hvilken som helst IPVPN |
Bruk en eksisterende lokal infrastruktur for sikkerhet/perimeter på alle steder som går inn i IPVPN som brukes for ExpressRoute for Microsoft 365-tilkobling. Hårnål IPVPN-en som brukes for ExpressRoute for Microsoft 365 til bestemte lokale plasseringer som er angitt for å fungere som sikkerhet/perimeter. |
Noen tjenesteleverandører tilbyr også administrert sikkerhet/perimeterfunksjonalitet som en del av integreringsløsningene med Azure ExpressRoute.
Når du vurderer topologiplasseringen av alternativene for nettverks-/sikkerhetsperimeter som brukes for ExpressRoute for Microsoft 365-tilkoblinger, er følgende ekstra hensyn
Dybde- og typekontroller for nettverk/sikkerhet kan ha innvirkning på ytelsen og skalerbarheten til Microsoft 365-brukeropplevelsen.
Utgående (lokalt–>Microsoft) og inngående (Microsoft-lokalt>) [hvis aktivert] flyter kan ha ulike krav. Disse er sannsynligvis forskjellig fra utgående til generelle Internett-destinasjoner.
Microsoft 365-krav for porter/protokoller og nødvendige IP-delnett er de samme, uansett om trafikken rutes via ExpressRoute for Microsoft 365 eller via Internett.
Topologisk plassering av kundenettverk/sikkerhetskontroller bestemmer det endelige ende-til-ende-nettverket mellom brukeren og Microsoft 365-tjenesten og kan ha en betydelig innvirkning på nettverksventetid og overbelastning.
Kunder oppfordres til å utforme sikkerhets-/perimetertopologien for bruk med ExpressRoute for Microsoft 365 i samsvar med anbefalte fremgangsmåter for redundans, høy tilgjengelighet og nødgjenoppretting.
Her er et eksempel på Contoso som sammenligner de ulike tilkoblingsalternativene for Azure ExpressRoute med sikkerhetsmodellene for perimeter som er beskrevet ovenfor.
Eksempel: Sikring av Azure ExpressRoute
Contoso vurderer å implementere Azure ExpressRoute, og etter å ha planlagt den optimale arkitekturen for ExpressRoute for Microsoft 365, og etter å ha brukt veiledningen ovenfor for å forstå båndbreddekravene, bestemmer de den beste metoden for å sikre perimeteren.
For Contoso, en multinasjonal organisasjon med plasseringer på flere kontinenter, må sikkerheten strekke seg over alle perimeterer. Det optimale tilkoblingsalternativet for Contoso er en flerpunktstilkobling med flere nodeplasseringer over hele verden for å betjene behovene til de ansatte på hvert kontinent. Hvert kontinent inkluderer redundante Azure ExpressRoute-kretser innenfor kontinentet, og sikkerhet må dekke alle disse.
Contosos eksisterende infrastruktur er pålitelig og kan håndtere det ekstra arbeidet, som et resultat av dette kan Contoso bruke infrastrukturen for azure ExpressRoute- og internettperimetersikkerheten. Hvis dette ikke var tilfelle, kunne Contoso velge å kjøpe mer utstyr for å supplere eksisterende utstyr eller håndtere en annen type tilkobling.
Båndbreddeplanlegging for Azure ExpressRoute
Hver Microsoft 365-kunde har unike båndbreddebehov avhengig av antall personer på hvert sted, hvor aktive de er med hvert Microsoft 365-program og andre faktorer, for eksempel bruk av lokalt eller hybridutstyr og nettverkssikkerhetskonfigurasjoner.
Hvis du har for lite båndbredde, vil det føre til overbelastning, overføring av data og uforutsigbare forsinkelser. Hvis du har for mye båndbredde, vil det føre til unødvendige kostnader. På et eksisterende nettverk refereres båndbredde ofte til når det gjelder mengden tilgjengelig takhøyde på kretsen som en prosentandel. Å ha 10% takhøyde vil sannsynligvis resultere i overbelastning og å ha 80% takhøyde betyr vanligvis unødvendig kostnad. Vanlige måltildelinger for takhøyde er 20 % til 50 %.
Den beste mekanismen er å teste det eksisterende nettverksforbruket for å finne riktig båndbreddenivå. Dette er den eneste måten å få et ekte mål på bruk og behov på, ettersom alle nettverkskonfigurasjoner og programmer på noen måter er unike. Når du måler, bør du følge nøye med på det totale båndbreddeforbruket, ventetiden og TCP-overbelastning for å forstå nettverksbehovene dine.
Når du har en estimert grunnlinje som omfatter alle nettverksprogrammer, kan du prøve ut Microsoft 365 med en liten gruppe som består av de ulike profilene til personer i organisasjonen for å bestemme faktisk bruk, og bruke de to målene til å beregne hvor mye båndbredde du trenger for hver kontorplassering. Hvis det er problemer med ventetid eller TCP-overbelastning i testingen, må du kanskje flytte utgående trafikk nærmere personene som bruker Microsoft 365, eller fjerne intensiv nettverksskanning, for eksempel SSL-dekryptering/inspeksjon.
Alle våre anbefalinger om hvilken type nettverksbehandling som anbefales, gjelder for både ExpressRoute- og Internett-kretser. Det samme gjelder for resten av veiledningen på nettstedet for ytelsesjustering.
Bygg distribusjons- og testprosedyrene dine
Implementeringsplanen bør omfatte planlegging av både testing og tilbakerulling. Hvis implementeringen ikke fungerer som forventet, bør planen utformes for å påvirke minst mulig antall personer før problemer oppdages. Nedenfor finner du noen prinsipper på høyt nivå som planen din bør vurdere.
Fase nettverkssegmentet og brukertjenestepålasting for å minimere forstyrrelser.
Plan for testing av ruter med traceroute og TCP-tilkobling fra en separat Internett-tilkoblet vert.
Fortrinnsvis bør testing av innkommende og utgående tjenester gjøres på et isolert testnettverk med en Test Microsoft 365-leier.
Testing kan også utføres på et produksjonsnettverk hvis kunden ennå ikke bruker Microsoft 365 eller er pilot.
Du kan eventuelt utføre testing under et produksjonsbrudd som er satt til side bare for testing og overvåking.
Du kan også teste ved å kontrollere ruter for hver tjeneste på hver lag 3-ruternode. Denne tilbakefall bør bare brukes hvis ingen annen testing er mulig siden mangel på fysisk testing introduserer risiko.
Bygg distribusjonsprosedyrene dine
Distribusjonsprosedyrene bør rulles ut til små grupper av personer i faser for å tillate testing før du distribuerer til større grupper av personer. Nedenfor finner du flere måter å utføre distribusjonen av ExpressRoute på.
Konfigurer ExpressRoute med Microsoft-nodefordeling, og få ruteannonsene videresendt til én enkelt vert bare for trinnvise testformål.
Annonser ruter til ExpressRoute-nettverket til ett enkelt nettverkssegment først, og utvid ruteannonser etter nettverkssegment eller område.
Hvis du distribuerer Microsoft 365 for første gang, kan du bruke ExpressRoute-nettverksdistribusjonen som pilot for noen få personer.
Hvis du bruker proxy-servere, kan du alternativt konfigurere en TEST PAC-fil til å dirigere noen få personer til ExpressRoute med testing og tilbakemelding før du legger til flere.
Implementeringsplanen bør føre opp hver av distribusjonsprosedyrene som må utføres, eller kommandoer som må brukes til å distribuere nettverkskonfigurasjonen. Når nettverksavbruddstiden kommer, skal alle endringene som gjøres, være fra den skriftlige distribusjonsplanen som ble skrevet på forhånd og fagfellevurdert. Se vår veiledning om den tekniske konfigurasjonen av ExpressRoute.
Oppdatere SPF TXT-postene hvis du har endret IP-adresser for lokale servere som vil fortsette å sende e-post.
Oppdaterer DNS-oppføringer for lokale servere hvis du har endret IP-adresser for å få plass til en ny NAT-konfigurasjon.
Sørg for at du abonnerer på RSS-feeden for Microsoft 365-endepunktvarsler for å opprettholde ruting eller proxy-konfigurasjoner.
Når ExpressRoute-distribusjonen er fullført, skal prosedyrene i testplanen kjøres. Resultater for hver prosedyre bør logges. Du må inkludere prosedyrer for tilbakerulling til det opprinnelige produksjonsmiljøet i tilfelle testplanresultatene indikerer at implementeringen ikke var vellykket.
Bygg testprosedyrene dine
Testprosedyrene bør inneholde tester for hver utgående og inngående nettverkstjeneste for Microsoft 365, både som skal bruke ExpressRoute og de som ikke kommer til å gjøre det. Fremgangsmåtene bør omfatte testing fra hver unike nettverksplassering, inkludert brukere som ikke er lokale på firmanettverket.
Noen eksempler på testaktiviteter inkluderer følgende.
Ping fra den lokale ruteren til nettverksoperatørens ruter.
Valider annonser for 500 + Microsoft 365 og CRM Online IP-adresse mottas av den lokale ruteren.
Valider at innkommende og utgående NAT fungerer mellom ExpressRoute og det interne nettverket.
Bekreft at ruter til NAT blir annonsert fra ruteren.
Valider at ExpressRoute har godtatt de annonserte prefiksene.
- Bruk følgende cmdlet til å bekrefte nodenodingsannonser:
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringValider at det offentlige IP-området for NAT ikke er annonsert til Microsoft via andre ExpressRoute- eller offentlige Internett-nettverkskretser, med mindre det er et bestemt delsett av et større område som i forrige eksempel.
ExpressRoute-kretser er sammenkoblet, og valider at begge BGP-øktene kjører.
Konfigurer én enkelt vert på innsiden av NAT, og bruk ping, tracert og tcpping til å teste tilkoblingen på tvers av den nye kretsen til verten outlook.office365.com. Alternativt kan du bruke et verktøy som Wireshark eller Microsoft Network Monitor 3.4 på en speilvendt port til MSEE for å validere at du kan koble til IP-adressen som er knyttet til outlook.office365.com.
Test programnivåfunksjonalitet for Exchange Online.
Test outlook er i stand til å koble til Exchange Online og sende/motta e-post.
Test outlook er i stand til å bruke tilkoblet modus.
Test smarttelefontilkobling og mulighet for sending/mottak.
- Test programnivåfunksjonalitet for SharePoint
Test OneDrive for Business synkroniseringsklient.
Test SharePoint-webtilgang.
- Test programnivåfunksjonalitet for Skype for Business kallscenarioer:
Bli med i telefonkonferansen som godkjent bruker [invitasjon initiert av sluttbruker].
Inviter bruker til telefonkonferanse [invitasjon sendt fra MCU].
Bli med i konferansen som anonym bruker ved hjelp av Skype for Business webprogram.
Bli med i anrop fra den kablede PC-tilkoblingen, IP-telefonen og mobilenheten.
Kall til organisasjonsbasert bruker o Kall til PSTN-validering: anropet er fullført, samtalekvaliteten er akseptabel, tilkoblingstiden er akseptabel.
Kontroller at tilstedeværelsesstatusen for kontakter er oppdatert for både medlemmer av leieren og brukere i forbund.
Vanlige problemer
Asymmetrisk ruting er det vanligste implementeringsproblemet. Her er noen vanlige kilder du kan se etter:
Bruk en åpen eller flat nettverksrutingstopologi uten at kilde-NAT er på plass.
Bruker ikke SNAT til å rute til inngående tjenester via både Internett- og ExpressRoute-tilkoblinger.
Tester ikke inngående tjenester på ExpressRoute på et testnettverk før du distribuerer bredt.
Distribuere ExpressRoute-tilkobling gjennom nettverket
Fase distribusjonen til ett segment av nettverket om gangen, og rull gradvis ut tilkoblingen til ulike deler av nettverket med en plan for å rulle tilbake for hvert nye nettverkssegment. Hvis distribusjonen er på linje med en Microsoft 365-distribusjon, kan du distribuere til Microsoft 365-pilotbrukerne først og utvide derfra.
Først for testen og deretter for produksjon:
Kjør distribusjonstrinnene for å aktivere ExpressRoute.
Test at du ser nettverksrutene som forventet.
Utfør testing på hver inngående og utgående tjeneste.
Tilbakerulling hvis du oppdager problemer.
Konfigurere en testtilkobling til ExpressRoute med et testnettverkssegment
Nå som du har fullført planen på papir, er det på tide å teste i liten skala. I denne testen skal du opprette én enkelt ExpressRoute-tilkobling med Microsoft Peering til et testdelnett på det lokale nettverket. Du kan konfigurere en prøveversjon av Microsoft 365-tenant med tilkobling til og fra test-delnettet og inkludere alle utgående og inngående tjenester som du skal bruke i produksjon i testundernettet. Konfigurer DNS for testnettverkssegmentet og opprett alle innkommende og utgående tjenester. Utfør testplanen, og sørg for at du er kjent med rutingen for hver tjeneste og ruteoverføringen.
Utfør distribusjons- og testplanene
Når du har fullført elementene som er beskrevet ovenfor, kan du sjekke ut områdene du har fullført, og sørge for at du og gruppen har gjennomgått dem før du utfører distribusjons- og testplanene.
Liste over utgående og inngående tjenester som er involvert i nettverksendringen.
Globalt nettverksarkitekturdiagram som viser både Internett-utgående og ExpressRoute møt-meg-plasseringer.
Nettverksrutingsdiagram som demonstrerer de ulike nettverksbanene som brukes for hver tjeneste som distribueres.
En distribusjonsplan med trinn for å implementere endringene og tilbakerulling om nødvendig.
En testplan for testing av hver Microsoft 365- og nettverkstjeneste.
Fullført papirvalidering av produksjonsruter for innkommende og utgående tjenester.
En fullført test på tvers av et testnettverksegment, inkludert tilgjengelighetstesting.
Velg et avbruddsvindu som er langt nok til å kjøre gjennom hele distribusjonsplanen og testplanen, har litt tid tilgjengelig for feilsøking og tid for tilbakerulling om nødvendig.
Forsiktig!
På grunn av den komplekse rutingen over både Internett og ExpressRoute, anbefales det at det legges til ekstra buffertid i dette vinduet for å håndtere feilsøking av kompleks ruting.
Konfigurer QoS for Skype for Business Online
QoS er nødvendig for å oppnå stemme- og møtefordeler for Skype for Business Online. Du kan konfigurere QoS etter at du har sikret at ExpressRoute-nettverkstilkoblingen ikke blokkerer noen av de andre Microsoft 365-tjenestetilgangene. Konfigurasjon for QoS er beskrevet i artikkelen ExpressRoute og QoS i Skype for Business Online.
Feilsøke implementeringen
Det første stedet å se på er trinnene i denne implementeringsveiledningen, har du gått glipp av implementeringsplanen? Gå tilbake og kjør ytterligere liten nettverkstesting hvis mulig for å replikere feilen og feilsøke den der.
Identifiser hvilke inngående eller utgående tjenester som mislyktes under testing. Hent spesielt IP-adressene og delnettene for hver av tjenestene som mislyktes. Gå videre og gå gjennom diagrammet for nettverkstopologi på papir, og valider rutingen. Valider spesifikt hvor ExpressRoute-rutingen er annonsert til, test rutingen under avbruddet hvis mulig med sporinger.
Kjør PSPing med en nettverkssporing til hvert kundeendepunkt, og evaluer kilde- og mål-IP-adresser for å validere at de er som forventet. Kjør telnet til en hvilken som helst e-postvert som du eksponerer på port 25, og kontroller at SNAT skjuler den opprinnelige kilde-IP-adressen hvis dette er forventet.
Husk at når du distribuerer Microsoft 365 med en ExpressRoute-tilkobling, må du sørge for at både nettverkskonfigurasjonen for ExpressRoute er optimalt utformet, og at du også har optimalisert de andre komponentene på nettverket, for eksempel klientdatamaskiner. I tillegg til å bruke denne planleggingsveiledningen til å feilsøke trinnene du kanskje har gått glipp av, har vi også skrevet et feilsøkingsplan for ytelse for Microsoft 365 .
Her er en kort kobling du kan bruke til å komme tilbake: https://aka.ms/implementexpressroute365
Beslektede emner
Vurdering av Nettverkstilkobling for Microsoft 365
Azure ExpressRoute for Microsoft 365
Ytelse for mediekvalitet og nettverkstilkobling i Skype for Business Online
Optimalisere nettverket for Skype for Business Online
ExpressRoute og QoS i Skype for Business Online
Anropsflyt ved hjelp av ExpressRoute
Ytelsesjustering for Microsoft 365 ved hjelp av opprinnelige planer og ytelseslogg
Feilsøkingsplan for ytelse for Microsoft 365