Del via


Konfigurere ExpressRoute til Power Platform

Power Platform-tjenester og -miljøer behøver ikke at være konfigureret for at bruge ExpressRoute. Hvis du vil bruge ExpressRoute, skal du dog konfigurere netværksrouting i organisationen for at sikre, at Power Platform trafik dirigeres gennem ExpressRoute-kredsløbet.

ExpressRoute håndterer trafik på Microsoft-netværket ved at distribuere reklamer for bestemte IP-undernet til den ExpressRoute, de er konfigureret i forhold til. Da der annonceres for routing via en BGP-forbindelse (Border Gateway Protocol), vælges den typisk som den mest effektive forbindelse til destinationen, i stedet for at den distribueres via internettet.

På kundesiden reklamerer BGP-forbindelsen for IP-præfikserne for tjenesterne for hver peering-type, der er konfigureret for den pågældende ExpressRoute-rute.

Fastlæggelse af, hvilken yderligere netværkskonfiguration du skal bruge, afhænger af, hvilke interaktioner du vil distribuere via ExpressRoute. I denne artikel beskrives de forskellige typer trafik, der kan dirigeres gennem ExpressRoute, og hvordan du konfigurerer netværksrouting for at sikre, at trafikken dirigeres korrekt.

Servertrafik

Servertrafik er trafikken mellem Power Platform tjenester og andre tjenester, såsom servere i det lokale miljø eller andre Microsoft cloud-tjenester. Denne trafik kan enten være indgående eller udgående, afhængigt af forbindelsens retning.

Indgående trafik (til Power Platform-tjenester)

Konfigurer intern routing i datacenteret, så du foretrækker forbindelser via ExpressRoute for trafik til Microsoft-tjenester.

Udgående trafik (fra Power Platform-tjenester)

Hvor trafik dirigeres tilbage gennem ExpressRoute, f.eks. til en det lokale miljø-server, er der ingen kontrolelementer i ExpressRoute, der kan låse de tjenester, der foretager forbindelser, ned. Da routing foretages på netværksniveau, og derfor valideres den bestemte tjeneste, der foretager forespørgslen, ikke, før der distribueres trafik.

Øvrige tjenester kan sende anmodninger til en kundeservice. Det er ikke muligt at låse anmodninger til et bestemt sæt maskiner. Den bedste fremgangsmåde er at betragte trafik gennem ExpressRoute som noget, der kommer fra en ekstern kilde. Selvom det kommer fra et Microsoft datacenter, styrer Microsoft ikke kilden til anmodningerne. Andre kundeservicer kan forsøge at oprette forbindelse. Kontrollér alle forbindelser, som om de kommer fra en ekstern gateway.

Diagram, der viser udgående trafik, der dirigeres tilbage gennem ExpressRoute for Power Platform.

Hvis en trafiktjeneste skal dirigeres tilbage til ExpressRoute, skal den tilknyttede tjeneste:

  • Hav en webadresse, der kan registreres offentligt.
  • Hav en offentlig IP-adresse, der svarer til et undernet, der er konfigureret for en ExpressRoute-peering-definition.
  • Vær i det samme område som den anmodende service, hvis ExpressRoute (standard) bruges, eller i et hvilket som helst område, hvis ExpressRoute Premium bruges.

Denne fremgangsmåde er værdifuld i mange almindelige integrationsscenarier mellem online og lokale tjenester.

IP-destinationsadressen for udgående trafik fra en Power Platform-ressource skal være en offentlig IP-adresse, der annonceres via en ExpressRoute-adresse. Da Microsoft cloud service er delt, skal al trafik behandles, som om den stammer fra internettet. Brug en omvendt proxy- eller program gateway skal derfor som regel bruges til at inspicere og kontrollere indgående trafik fra ExpressRoute.

Du kan finde oplysninger om de IP-undernet, der bruges, ved at gå til Systemkrav, begrænsninger og konfigurationsværdier for Power Apps og IP-adressekonfiguration for Power Automate.

Klienttrafik

Trafik på klientenheder, f.eks. pc'er på firmanetværket eller mobilenheder på offentlige forbindelser, er typisk indgående til Microsoft-tjenester i stedet for udgående til klienten. ExpressRoute håndhæves ikke som den eneste rute til Power Platform. Power Platform blokerer ikke trafik, der er modtaget direkte fra internettet, og ExpressRoute blokerer ikke svar fra trafik, der oprindeligt er modtaget direkte fra internettet. Power Platform-tjenesten vil stadig blive annonceret offentligt på internettet, så der vil være distributionsstier til den service, der er tilgængelige separat fra ExpressRoute.

Hvis klienttrafikken skal dirigeres hen over ExpressRoute, er udfordringen for netværksteamet først at distribuere trafik internt fra klienten via LAN eller WAN til det undernet, der er forbundet med ExpressRoute. Det er også dit teams ansvar at sikre, at denne trafik ikke "slipper ud" ved en fejl og opretter forbindelse til det offentlige internet.

Brug proxyer i virksomhedens netværk, og tilføj muligvis en VPN til mobile enheder for at tvinge dem til at oprette forbindelse til virksomhedens netværk først. Denne konfiguration sikrer, at trafikken dirigerer gennem firmaets ExpressRoute-kredsløb. Bemærk dog, at denne tilgang kan medføre, at du får direkte adgang til skytjenesterne via et lokalt internetudbrud.

Det er vigtigt at forstå, at ExpressRoute ikke sikrer, at trafik på firmanetværket bruger ExpressRoute. Proxy- og distributionsreglerne på firmanetværket bestemmer dette, og du skal konfigurere dem for at sikre, at anmodninger fra firmanetværket bruger ExpressRoute.

ExpressRoute kan ikke forhindre, at andre forbindelser - f.eks. brugere på internettet - går direkte til Power Platform.

Diagram, der viser, at Power Platform og ExpressRoute ikke forhindrer direkte adgang, og ExpressRoute ikke sikrer, at direkte adgang er deaktiveret.

Ekstern forbindelse er et problem, der bekymrer mobilbrugere, især fra mobilenheder, f.eks. bærbare computere, tablets og telefoner. Du har et par muligheder:

  • Hvis din organisation bruger organisationsnetværket, skal du sikre, at der kun er adgang til AD FS (Active Directory Federation Services), når der er oprettet en VPN-forbindelse til firmanetværket.

  • Brug betinget Microsoft Entra-adgang og Intune kan kontrollere, hvilke enheder og placeringer der har adgang, og til at styre enhedens konfiguration, f.eks. proxyer, VPN og routing.

Diagram over mobile medarbejdere, der opretter direkte forbindelse til Power Platform, mens kontormedarbejdere bruger wi-fi eller VPN og adgang via ExpressRoute.

Begrænsninger af ExpressRoute

Når du overvejer at implementerer ExpressRoute, er det vigtigt at forstå, hvad det ikke gør, som det gør.

Konfiguration af distribution af kundenetværk

ExpressRoute håndterer konfigurationen af trafik i Microsoft-netværket. Det ændrer ikke routing af trafik i dit netværk. Du skal konfigurere netværksrouting i netværket til direkte trafik, der er bundet til Microsoft Cloud Services, til det undernet, der er forbundet med ExpressRoute, og derefter over ExpressRoute-ruten.

Vi annoncer flere specifikke ruter til Microsoft 365 via ExpressRoute end de ruter, vi annoncerer på det offentlige internet. Hvis du spreder de specifikke ruter fra os til deres netværk, distribueres brugerens trafik til ExpressRoute på grund af reglen for præfikstilpasning af præfikser.

Du kan støde på en eller begge af følgende udfordringer, når du konfigurerer ExpressRoute:

  • Den interne netværksrouting er ukorrekt konfigureret til at dirigere trafikken til ExpressRoute-forbindelsespunkt.

  • Du har asymmetrisk routing, hvor forespørgsels- og responstrafik dirigeres forskelligt. Trafik sendes f.eks. direkte til Microsoft-cloudtjenester via internettet, men vender derefter tilbage via ExpressRoute, hvilket udløser firewallundtagelser, der blokerer returtrafikken.

Ydeevnen

ExpressRoute alene vil normalt ikke give større fordele i ydeevnen i forhold til en effektiv netværksforbindelse med ledig kapacitet. En dedikeret og privat forbindelse via din forbindelsesudbyder kan resultere i en mere optimeret forbindelse end en delt internetforbindelse.

Gennemløb for dataindlæsning til Power Platform

Da netværket sjældent er flaskehalsen, når data indlæses Power Platform – det er mere sandsynligt, at programmet-behandlingen skal optimeres – bidrager ExpressRoute sjældent direkte til et større gennemløb af data i Power Platform. ExpressRoute gør dog trafik mere forudsigelig og sikrer, at data ikke sendes via det offentlige internet.

Næste trin