Netwerkconfiguratiedetails voor App Service Environment voor Power Apps met Azure ExpressRoute

Belangrijk

Dit artikel gaat over App Service Environment v1. App Service Environment v1 wordt op 31 augustus 2024 buiten gebruik gesteld. Er is een nieuwe versie van App Service Environment die eenvoudiger te gebruiken is en wordt uitgevoerd op een krachtigere infrastructuur. Voor meer informatie over de nieuwe versie begint u met de inleiding tot de App Service-omgeving. Als u momenteel App Service Environment v1 gebruikt, volgt u de stappen in dit artikel om te migreren naar de nieuwe versie.

Vanaf 29 januari 2024 kunt u geen nieuwe App Service Environment v1-resources meer maken met behulp van een van de beschikbare methoden, waaronder ARM/Bicep-sjablonen, Azure Portal, Azure CLI of REST API. U moet vóór 31 augustus 2024 migreren naar App Service Environment v3 om te voorkomen dat resources worden verwijderd en gegevens verloren gaan.

Klanten kunnen een Azure ExpressRoute-circuit verbinden met hun virtuele netwerkinfrastructuur om hun on-premises netwerk uit te breiden naar Azure. App Service Environment wordt gemaakt in een subnet van de infrastructuur van het virtuele netwerk . Apps die worden uitgevoerd in App Service Environment maken beveiligde verbindingen met back-endresources die alleen toegankelijk zijn via de ExpressRoute-verbinding.

App Service Environment kan worden gemaakt in deze scenario's:

  • Virtuele netwerken van Azure Resource Manager.
  • Klassieke implementatiemodel virtuele netwerken.
  • Virtuele netwerken die gebruikmaken van openbare adresbereiken of RFC1918 adresruimten (dat wil gezegd privéadressen).

Notitie

Hoewel dit artikel naar web-apps verwijst, is het ook van toepassing op API Apps en mobiele apps.

Vereiste netwerkverbinding

App Service Environment heeft vereisten voor netwerkconnectiviteit die in eerste instantie niet voldoen aan een virtueel netwerk dat is verbonden met ExpressRoute.

Voor App Service Environment zijn de volgende netwerkverbindingsinstellingen vereist om goed te functioneren:

  • Uitgaande netwerkconnectiviteit met Azure Storage-eindpunten wereldwijd op zowel poort 80 als poort 443. Deze eindpunten bevinden zich in dezelfde regio als App Service Environment en ook in andere Azure-regio's. Azure Storage-eindpunten worden omgezet in de volgende DNS-domeinen: table.core.windows.net, blob.core.windows.net, queue.core.windows.net en file.core.windows.net.

  • Uitgaande netwerkconnectiviteit met de Azure Files-service op poort 445.

  • Uitgaande netwerkconnectiviteit met Azure SQL Database-eindpunten die zich in dezelfde regio bevinden als App Service Environment. SQL Database-eindpunten worden omgezet in het database.windows.net-domein, waarvoor open toegang is vereist tot poorten 1433, 11000-11999 en 14000-14999. Zie Poorten buiten 1433 voor ADO.NET 4.5 voor meer informatie over het gebruik van SQL Database V12-poorten.

  • Uitgaande netwerkconnectiviteit met de Eindpunten van het Azure-beheervlak (zowel het klassieke Azure-implementatiemodel als azure Resource Manager-eindpunten). Verbinding maken iviteit van deze eindpunten omvat de domeinen management.core.windows.net en management.azure.com.

  • Uitgaande netwerkconnectiviteit met de domeinen ocsp.msocsp.com, mscrl.microsoft.com en crl.microsoft.com. Verbinding maken iviteit van deze domeinen is nodig om TLS-functionaliteit te ondersteunen.

  • De DNS-configuratie voor het virtuele netwerk moet alle eindpunten en domeinen die in dit artikel worden genoemd, kunnen oplossen. Als de eindpunten niet kunnen worden opgelost, mislukt het maken van de App Service-omgeving. Elke bestaande App Service-omgeving is gemarkeerd als beschadigd.

  • Uitgaande toegang op poort 53 is vereist voor communicatie met DNS-servers.

  • Als er een aangepaste DNS-server aan het andere uiteinde van een VPN-gateway bestaat, moet de DNS-server bereikbaar zijn vanaf het subnet dat App Service Environment bevat.

  • Het uitgaande netwerkpad kan niet door interne bedrijfsproxy's worden geleid en kan on-premises niet worden geforceerd geforceerd. Met deze acties wordt het effectieve NAT-adres van uitgaand netwerkverkeer van App Service Environment gewijzigd. Wijzigingen in het NAT-adres van uitgaand netwerkverkeer van App Service Environment veroorzaken verbindingsfouten naar veel van de eindpunten. Het maken van de App Service-omgeving mislukt. Elke bestaande App Service-omgeving is gemarkeerd als beschadigd.

  • Binnenkomende netwerktoegang tot vereiste poorten voor App Service Environment moet zijn toegestaan. Zie Binnenkomend verkeer naar App Service Environment beheren voor meer informatie.

Zorg ervoor dat een geldige DNS-infrastructuur is geconfigureerd en onderhouden voor het virtuele netwerk om aan de DNS-vereisten te voldoen. Als de DNS-configuratie wordt gewijzigd nadat App Service Environment is gemaakt, kunnen ontwikkelaars afdwingen dat App Service Environment de nieuwe DNS-configuratie ophaalt. U kunt het opnieuw opstarten van een rolling omgeving activeren met behulp van het pictogram Opnieuw opstarten onder App Service Environment-beheer in Azure Portal. Het opnieuw opstarten zorgt ervoor dat de omgeving de nieuwe DNS-configuratie ophaalt.

Als u wilt voldoen aan de vereisten voor binnenkomende netwerktoegang, configureert u een netwerkbeveiligingsgroep (NSG) in het Subnet app Service Environment. De NSG staat de vereiste toegang toe om inkomend verkeer naar App Service Environment te beheren.

Uitgaande netwerkconnectiviteit

Standaard kondigt een nieuw gemaakt ExpressRoute-circuit een standaardroute aan waarmee uitgaande internetverbinding mogelijk is. App Service Environment kan deze configuratie gebruiken om verbinding te maken met andere Azure-eindpunten.

Een algemene klantconfiguratie is het definiëren van hun eigen standaardroute (0.0.0.0/0), waardoor uitgaand internetverkeer on-premises stroomt. Deze verkeersstroom breekt altijd de App Service-omgeving. Het uitgaande verkeer wordt on-premises geblokkeerd of NAT wordt geblokkeerd naar een onherkenbare set adressen die niet meer werken met verschillende Azure-eindpunten.

De oplossing is het definiëren van een (of meer) door de gebruiker gedefinieerde routes (UDR's) in het subnet dat App Service Environment bevat. Een UDR definieert subnetspecifieke routes die worden gehonoreerd in plaats van de standaardroute.

Gebruik indien mogelijk de volgende configuratie:

  • De ExpressRoute-configuratie adverteert 0.0.0.0/0. De configuratie forceert standaard al het uitgaande verkeer on-premises.
  • De UDR die is toegepast op het subnet dat App Service Environment bevat, definieert 0.0.0.0/0 met een volgend hoptype internet. Verderop in dit artikel wordt een voorbeeld van deze configuratie beschreven.

Het gecombineerde effect van deze configuratie is dat de UDR op subnetniveau voorrang heeft op de ExpressRoute-geforceerde tunneling. Uitgaande internettoegang vanuit App Service Environment is gegarandeerd.

Belangrijk

De routes die in een UDR zijn gedefinieerd, moeten specifiek genoeg zijn om voorrang te krijgen op alle routes die worden geadverteerd door de ExpressRoute-configuratie. In het voorbeeld dat in de volgende sectie wordt beschreven, wordt het adresbereik breed 0.0.0.0/0 gebruikt. Dit bereik kan per ongeluk worden overschreven door routeadvertenties die meer specifieke adresbereiken gebruiken.

App Service Environment wordt niet ondersteund met ExpressRoute-configuraties waarmee routes van het openbare peeringpad naar het privépeeringspad kruislings worden geadverteerd. ExpressRoute-configuraties waarvoor openbare peering is geconfigureerd, ontvangen routeadvertenties van Microsoft voor een grote set IP-adresbereiken van Microsoft Azure. Als deze adresbereiken kruislings worden geadverteerd op het pad naar persoonlijke peering, worden alle uitgaande netwerkpakketten van het Subnet van de App Service Environment geforceerd getunneld naar de on-premises netwerkinfrastructuur van de klant. Deze netwerkstroom wordt momenteel niet ondersteund met App Service Environment. Een oplossing is om cross-advertising routes van het openbare peeringpad naar het privépeeringspad te stoppen.

Zie Routering voor virtueel netwerkverkeer voor achtergrondinformatie over door de gebruiker gedefinieerde routes.

Zie Netwerkverkeer routeren met een routetabel met behulp van PowerShell voor meer informatie over het maken en configureren van door de gebruiker gedefinieerde routes.

UDR-configuratie

In deze sectie ziet u een voorbeeld van een UDR-configuratie voor App Service Environment.

Vereisten

  • Installeer Azure PowerShell vanaf de pagina Azure Downloads. Kies een download met een datum van juni 2015 of hoger. Selecteer Onder Opdrachtregelprogramma's>Windows PowerShell de optie Installeren om de nieuwste PowerShell-cmdlets te installeren.

  • Maak een uniek subnet voor exclusief gebruik door App Service Environment. Het unieke subnet zorgt ervoor dat de UDR's die zijn toegepast op het subnet alleen uitgaand verkeer voor App Service Environment openen.

Belangrijk

Implementeer App Service Environment alleen nadat u de configuratiestappen hebt voltooid. De stappen zorgen ervoor dat uitgaande netwerkconnectiviteit beschikbaar is voordat u App Service Environment implementeert.

Stap 1: Een routetabel maken

Maak een routetabel met de naam DirectInternetRouteTable in de Azure-regio VS - west, zoals wordt weergegeven in dit fragment:

New-AzureRouteTable -Name 'DirectInternetRouteTable' -Location uswest

Stap 2: Routes maken in de tabel

Voeg routes toe aan de routetabel om uitgaande internettoegang mogelijk te maken.

Uitgaande toegang tot internet configureren. Definieer een route voor 0.0.0.0/0, zoals wordt weergegeven in dit fragment:

Get-AzureRouteTable -Name 'DirectInternetRouteTable' | Set-AzureRoute -RouteName 'Direct Internet Range 0' -AddressPrefix 0.0.0.0/0 -NextHopType Internet

0.0.0.0/0 is een breed adresbereik. Het bereik wordt overschreven door adresbereiken die worden aangekondigd door ExpressRoute die specifieker zijn. Een UDR met een route 0.0.0.0/0 moet worden gebruikt in combinatie met een ExpressRoute-configuratie waarmee alleen 0.0.0.0/0 wordt geadverteerd.

Als alternatief kunt u een huidige, uitgebreide lijst met CIDR-bereiken downloaden die door Azure worden gebruikt. Het XML-bestand voor alle Ip-adresbereiken van Azure is beschikbaar via het Microsoft Downloadcentrum.

Notitie

De Ip-adresbereiken van Azure veranderen in de loop van de tijd. Door de gebruiker gedefinieerde routes hebben periodieke handmatige updates nodig om gesynchroniseerd te blijven.

Eén UDR heeft een standaard bovengrens van 100 routes. U moet de Azure IP-adresbereiken 'samenvatten' zodat deze binnen de limiet van 100 routes passen. UDR-gedefinieerde routes moeten specifieker zijn dan routes die worden geadverteerd door uw ExpressRoute-verbinding.

Stap 3: De tabel koppelen aan het subnet

Koppel de routetabel aan het subnet waar u App Service Environment wilt implementeren. Met deze opdracht wordt de Tabel DirectInternetRouteTable gekoppeld aan het ASESubnet-subnet dat App Service Environment bevat.

Set-AzureSubnetRouteTable -VirtualNetworkName 'YourVirtualNetworkNameHere' -SubnetName 'ASESubnet' -RouteTableName 'DirectInternetRouteTable'

Stap 4: De route testen en bevestigen

Nadat de routetabel is gebonden aan het subnet, test en bevestigt u de route.

Implementeer een virtuele machine in het subnet en bevestig deze voorwaarden:

  • Uitgaand verkeer naar de Azure- en niet-Azure-eindpunten die in dit artikel worden beschreven, loopt niet omlaag in het ExpressRoute-circuit. Als uitgaand verkeer van het subnet on-premises wordt geforceerd getunneld, mislukt het maken van de App Service-omgeving altijd.
  • DNS-zoekopdrachten voor de eindpunten die in dit artikel worden beschreven, worden allemaal correct omgezet.

Nadat u de configuratiestappen hebt voltooid en de route hebt bevestigd, verwijdert u de virtuele machine. Het subnet moet leeg zijn wanneer App Service Environment wordt gemaakt.

Nu bent u klaar om App Service Environment te implementeren.

Volgende stappen

Zie Inleiding tot App Service Environment voor App Service Environment voor Power Apps om aan de slag te gaan met App Service Environment.