Netwerkoverwegingen voor App Service Environment

Belangrijk

Dit artikel gaat over App Service Environment v2 die wordt gebruikt met geïsoleerde App Service-plannen. App Service Environment v2 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 v2 gebruikt, volgt u de stappen in dit artikel om te migreren naar de nieuwe versie.

Vanaf 29 januari 2024 kunt u vanaf 29 januari 2024 geen nieuwe App Service Environment v2-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.

Zie de buitengebruikstelling van App Service Environment v1/v2 voor de meest recente informatie over de buitengebruikstelling van App Service Environment v1 en v2.

App Service Environment is een implementatie van Azure-app Service in een subnet in uw virtuele Azure-netwerk. Er zijn twee implementatietypen voor een App Service-omgeving:

• Extern: Dit type implementatie maakt de gehoste apps beschikbaar met behulp van een IP-adres dat toegankelijk is op internet. Zie Een externe App Service-omgeving maken voor meer informatie.
• Interne load balancer: Dit type implementatie toont de gehoste apps op een IP-adres in uw virtuele netwerk. Het interne eindpunt is een interne load balancer. Zie Een interne load balancer App Service Environment maken en gebruiken voor meer informatie.

Notitie

Dit artikel gaat over App Service Environment v2, dat wordt gebruikt met geïsoleerde App Service-plannen.

Ongeacht het implementatietype hebben alle App Service-omgevingen een openbaar virtueel IP-adres (VIP). Dit VIP wordt gebruikt voor inkomend beheerverkeer en als het adres wanneer u aanroept van de App Service Environment naar internet. Dergelijke aanroepen verlaten het virtuele netwerk via het VIP dat is toegewezen voor de App Service-omgeving.

Als de apps resources in uw virtuele netwerk of via een VPN aanroepen, is het bron-IP-adres een van de IP-adressen in het subnet. Omdat de App Service-omgeving zich in het virtuele netwerk bevindt, heeft deze ook toegang tot resources binnen het virtuele netwerk zonder extra configuratie. Als het virtuele netwerk is verbonden met uw on-premises netwerk, hebben apps ook toegang tot resources daar zonder extra configuratie.

 

Als u een App Service-omgeving met een externe implementatie hebt, is het openbare VIP ook het eindpunt waarnaar uw apps voor het volgende worden omgezet:

• HTTP/S
• FTP/S
• Web-implementatie
• Foutopsporing op afstand

Als u een App Service-omgeving hebt met een interne load balancer-implementatie, is het adres van het interne adres het eindpunt voor HTTP/S, FTP/S, webimplementatie en externe foutopsporing.

Subnetgrootte

Nadat de App Service Environment is geïmplementeerd, kunt u de grootte van het subnet dat wordt gebruikt om het te hosten, niet meer wijzigen. App Service Environment maakt gebruik van een adres voor elke infrastructuurrol, evenals voor elke geïsoleerde instantie van het App Service-plan. Daarnaast maakt Azure-netwerken gebruik van vijf adressen voor elk subnet dat wordt gemaakt.

Een App Service-omgeving zonder App Service-abonnementen gebruikt 12 adressen voordat u een app maakt. Als u de interne load balancer-implementatie gebruikt, worden er 13 adressen gebruikt voordat u een app maakt. Wanneer u uitschaalt, moet u er rekening mee houden dat infrastructuurrollen worden toegevoegd aan elk veelvoud van 15 en 20 exemplaren van uw App Service-plan.

Belangrijk

Niets anders kan zich in het subnet bevinden, maar in de App Service-omgeving. Zorg ervoor dat u een adresruimte kiest die toekomstige groei mogelijk maakt. U kunt deze instelling later niet meer wijzigen. We raden een grootte aan van /24 256 adressen.

Wanneer u omhoog of omlaag schaalt, worden nieuwe rollen van de juiste grootte toegevoegd en worden uw workloads gemigreerd van de huidige grootte naar de doelgrootte. De oorspronkelijke VM's worden pas verwijderd nadat de workloads zijn gemigreerd. Als u bijvoorbeeld een App Service Environment met 100 Exemplaren van een App Service-plan hebt, is er een periode waarin u het aantal virtuele machines verdubbelt.

Binnenkomende en uitgaande afhankelijkheden

In de volgende secties worden afhankelijkheden beschreven waarvan u rekening moet houden voor uw App Service Environment. In een andere sectie worden DNS-instellingen besproken.

Binnenkomende afhankelijkheden

De App Service Environment werkt alleen als de volgende poorten open zijn:

Gebruik	Van	Tot
Beheer	App Service-beheeradressen	App Service Environment-subnet: 454, 455
Interne communicatie van App Service Environment	App Service Environment-subnet: alle poorten	App Service Environment-subnet: alle poorten
Inkomend verkeer van Azure Load Balancer toestaan	Azure load balancer	App Service Environment-subnet: 16001

Poorten 7564 en 1221 kunnen worden weergegeven als geopend op een poortscan. Ze reageren met een IP-adres en niets meer. U kunt ze desgewenst blokkeren.

Het binnenkomende beheerverkeer biedt naast systeembewaking opdrachten en controle over de App Service Environment. De bronadressen voor dit verkeer worden vermeld in beheeradressen van App Service Environment. De netwerkbeveiligingsconfiguratie moet toegang toestaan vanuit de beheeradressen van de App Service Environment op poort 454 en 455. Als u de toegang vanaf deze adressen blokkeert, wordt uw App Service-omgeving beschadigd en wordt deze onderbroken. Het TCP-verkeer dat binnenkomt op poorten 454 en 455, moet teruggaan vanaf hetzelfde VIP, of u hebt een asymmetrisch routeringsprobleem.

Binnen het subnet zijn er veel poorten die worden gebruikt voor communicatie met interne onderdelen en kunnen ze veranderen. Hiervoor moeten alle poorten in het subnet toegankelijk zijn vanuit het subnet.

Voor communicatie tussen de Azure Load Balancer en het Subnet app serviceomgeving zijn de minimale poorten die open moeten zijn 454, 455 en 16001. Als u een interne load balancer-implementatie gebruikt, kunt u verkeer vergrendelen tot alleen de poorten 454, 455, 16001. Als u een externe implementatie gebruikt, moet u rekening houden met de normale toegangspoorten voor apps. Dit zijn met name:

Gebruik	Poorten
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Externe foutopsporing in Visual Studio	4020, 4022, 4024
Web-implementatieservice	8172

Als u de toepassingspoorten blokkeert, kan uw App Service Environment nog steeds functioneren, maar uw app is mogelijk niet mogelijk. Als u door apps toegewezen IP-adressen met een externe implementatie gebruikt, moet u verkeer toestaan van de IP-adressen die zijn toegewezen aan uw apps naar het subnet. Ga vanuit de App Service Environment-portal naar IP-adressen en bekijk de poorten van waaruit u verkeer wilt toestaan.

Uitgaande afhankelijkheden

Voor uitgaande toegang is een App Service-omgeving afhankelijk van meerdere externe systemen. Veel van deze systeemafhankelijkheden worden gedefinieerd met DNS-namen en worden niet toegewezen aan een vaste set IP-adressen. De App Service Environment vereist dus uitgaande toegang van het subnet naar alle externe IP-adressen, in verschillende poorten.

App Service Environment communiceert via internet toegankelijke adressen op de volgende poorten:

Gebruikt voor	Poorten
DNS	53
NTP	123
CRL, Windows-updates, Linux-afhankelijkheden, Azure-services	80/443
Azure SQL	1433
Controleren	12000

De uitgaande afhankelijkheden worden vermeld in Het vergrendelen van een App Service-omgeving. Als de App Service-omgeving geen toegang meer heeft tot de afhankelijkheden, werkt deze niet meer. Als dat gebeurt gedurende een lange periode, wordt deze opgeschort.

DNS van klant

Als het virtuele netwerk is geconfigureerd met een door de klant gedefinieerde DNS-server, gebruiken de tenantworkloads het. De App Service Environment maakt gebruik van Azure DNS voor beheerdoeleinden. Als het virtuele netwerk is geconfigureerd met een door de klant geselecteerde DNS-server, moet de DNS-server bereikbaar zijn vanaf het subnet.

Notitie

Opslagkoppelingen of containerinstallatiekopie-pulls in App Service Environment v2 kunnen geen door de klant gedefinieerde DNS gebruiken in het virtuele netwerk of via de WEBSITE_DNS_SERVER app-instelling.

Als u DNS-omzetting wilt testen vanuit uw web-app, kunt u de consoleopdracht nameresolvergebruiken. Ga naar het foutopsporingsvenster op uw scm site voor uw app of ga naar de app in de portal en selecteer console. Vanaf de shellprompt kunt u de opdracht nameresolveruitvoeren, samen met de DNS-naam die u wilt opzoeken. Het resultaat dat u terugkrijgt, is hetzelfde als wat uw app zou krijgen terwijl u dezelfde zoekactie maakt. Als u gebruikt nslookup, voert u in plaats daarvan een zoekopdracht uit met behulp van Azure DNS.

Als u de DNS-instelling wijzigt van het virtuele netwerk waarin uw App Service-omgeving zich bevindt, moet u opnieuw opstarten. Om opnieuw opstarten te voorkomen, is het een goed idee om uw DNS-instellingen voor uw virtuele netwerk te configureren voordat u uw App Service Environment maakt.

Portal dependencies (Portal-afhankelijkheden)

Naast de afhankelijkheden die in de vorige secties worden beschreven, zijn er enkele extra overwegingen die u moet kennen die betrekking hebben op de portalervaring. Sommige mogelijkheden in Azure Portal zijn afhankelijk van directe toegang tot de SCM-site (Source Control Manager). Voor elke app in Azure-app Service zijn er twee URL's. De eerste URL is om toegang te krijgen tot uw app. De tweede URL is voor toegang tot de SCM-site, die ook wel de Kudu-console wordt genoemd. Functies die gebruikmaken van de SCM-site zijn onder andere:

• WebJobs
• Functies
• Logboekstreaming
• Kudu
• Uitbreidingen
• Procesverkenner
• Console

Wanneer u een interne load balancer gebruikt, is de SCM-site niet toegankelijk van buiten het virtuele netwerk. Sommige mogelijkheden werken niet vanuit de app-portal omdat ze toegang nodig hebben tot de SCM-site van een app. U kunt rechtstreeks verbinding maken met de SCM-site in plaats van via de portal.

Als uw interne load balancer de domeinnaam contoso.appserviceenvironment.netis en uw app-naam testapp is, wordt de app bereikt op testapp.contoso.appserviceenvironment.net. De SCM-site die ermee gaat, wordt bereikt op testapp.scm.contoso.appserviceenvironment.net.

IP-adressen

Een App Service Environment heeft een aantal IP-adressen waar u rekening mee moet houden. Dit zijn:

• Openbaar binnenkomende IP-adres: wordt gebruikt voor app-verkeer in een externe implementatie en beheerverkeer in zowel interne als externe implementaties.
• Uitgaand openbaar IP-adres: wordt gebruikt als het 'van'-IP voor uitgaande verbindingen die het virtuele netwerk verlaten. Deze verbindingen worden niet gerouteerd naar een VPN.
• Ip-adres van interne load balancer: dit adres bestaat alleen in een interne implementatie.
• Door de app toegewezen TLS/SSL-adressen op basis van IP: deze adressen zijn alleen mogelijk met een externe implementatie en wanneer een TLS/SSL-binding op basis van IP is geconfigureerd.

Al deze IP-adressen zijn zichtbaar in Azure Portal vanuit de gebruikersinterface van de App Service Environment. Als u een interne implementatie hebt, wordt het IP-adres voor de interne load balancer vermeld.

Notitie

Deze IP-adressen worden niet gewijzigd, zolang uw App Service-omgeving wordt uitgevoerd. Als uw App Service-omgeving wordt onderbroken en vervolgens wordt hersteld, worden de gebruikte adressen gewijzigd. De normale oorzaak van een schorsing is als u de toegang tot inkomend beheer blokkeert of als u de toegang tot een afhankelijkheid blokkeert.

Door de app toegewezen IP-adressen

Met een externe implementatie kunt u IP-adressen toewijzen aan afzonderlijke apps. Dat kunt u niet doen met een interne implementatie. Zie Een aangepaste DNS-naam beveiligen met een TLS/SSL-binding in Azure-app Service voor meer informatie over het configureren van uw app voor een eigen IP-adres.

Wanneer een app een eigen OP IP gebaseerd SSL-adres heeft, behoudt de App Service Environment zich twee poorten voor om aan dat IP-adres toe te wijzen. De ene poort is voor HTTP-verkeer en de andere poort is voor HTTPS. Deze poorten worden vermeld in de sectie IP-adressen van uw App Service Environment-portal. Verkeer moet deze poorten kunnen bereiken vanaf het VIP. Anders zijn de apps niet toegankelijk. Deze vereiste is belangrijk om te onthouden wanneer u netwerkbeveiligingsgroepen (NSG's) configureert.

Netwerkbeveiligingsgroepen

NSG's bieden de mogelijkheid om netwerktoegang binnen een virtueel netwerk te beheren. Wanneer u de portal gebruikt, is er een impliciete weigeringsregel met de laagste prioriteit om alles te weigeren. Wat u bouwt, zijn uw regels voor toestaan.

U hebt geen toegang tot de VM's die worden gebruikt om de App Service Environment zelf te hosten. Ze bevinden zich in een abonnement dat Door Microsoft wordt beheerd. Als u de toegang tot de apps wilt beperken, stelt u NSG's in op het subnet. Let daarbij goed op de afhankelijkheden. Als u afhankelijkheden blokkeert, werkt de App Service Environment niet meer.

U kunt NSG's configureren via Azure Portal of via PowerShell. De informatie hier toont de Azure-portal. U maakt en beheert NSG's in de portal als een resource op het hoogste niveau onder Netwerken.

De vereiste vermeldingen in een NSG zijn om verkeer toe te staan:

Inkomend

• TCP van de IP-servicetag AppServiceManagement op poorten 454, 455
• TCP van de load balancer op poort 16001
• Van het subnet App Service Environment naar het subnet App Service Environment op alle poorten

Uitgaand

• UDP voor alle IP-adressen op poort 53
• UDP voor alle IP-adressen op poort 123
• TCP naar alle IP-adressen op poorten 80, 443
• TCP naar de IP-servicetag Sql op poort 1433
• TCP naar alle IP-adressen op poort 12000
• Naar het Subnet van de App Service Environment op alle poorten

Deze poorten bevatten niet de poorten die uw apps nodig hebben voor succesvol gebruik. Stel dat uw app een MySQL-server moet aanroepen op poort 3306. Network Time Protocol (NTP) op poort 123 is het tijdsynchronisatieprotocol dat wordt gebruikt door het besturingssysteem. De NTP-eindpunten zijn niet specifiek voor App Service, kunnen variëren met het besturingssysteem en bevinden zich niet in een goed gedefinieerde lijst met adressen. Als u problemen met tijdsynchronisatie wilt voorkomen, moet u UDP-verkeer naar alle adressen op poort 123 toestaan. Het uitgaande TCP-naar-poort 12000-verkeer is voor systeemondersteuning en -analyse. De eindpunten zijn dynamisch en bevinden zich niet in een goed gedefinieerde set adressen.

De normale toegangspoorten voor apps zijn:

Gebruik	Poorten
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Externe foutopsporing in Visual Studio	4020, 4022, 4024
Web Deploy-service	8172

Met een standaardregel kunnen de IP-adressen in het virtuele netwerk met het subnet communiceren. Met een andere standaardregel kan de load balancer, ook wel het openbare VIP genoemd, communiceren met de App Service Environment. Als u de standaardregels wilt zien, selecteert u Standaardregels (naast het pictogram Toevoegen ).

Als u een regel voor weigeren plaatst vóór de standaardregels, voorkomt u verkeer tussen het VIP en de App Service-omgeving. Als u wilt voorkomen dat verkeer afkomstig is van het virtuele netwerk, voegt u uw eigen regel toe om inkomend verkeer toe te staan. Gebruik een bron die gelijk is aan AzureLoadBalancer, met een doel van Any en een poortbereik van *. Omdat de NSG-regel wordt toegepast op het subnet, hoeft u niet specifiek te zijn in de bestemming.

Als u een IP-adres aan uw app hebt toegewezen, moet u ervoor zorgen dat de poorten geopend blijven. Als u de poorten wilt zien, selecteert u IP-adressen van App Service Environment>.  

Nadat uw NSG's zijn gedefinieerd, wijst u deze toe aan het subnet. Als u het virtuele netwerk of subnet niet meer weet, kunt u het zien vanuit de App Service Environment-portal. Als u de NSG wilt toewijzen aan uw subnet, gaat u naar de gebruikersinterface van het subnet en selecteert u de NSG.

Routes

Geforceerde tunneling is wanneer u routes instelt in uw virtuele netwerk, zodat het uitgaande verkeer niet rechtstreeks naar internet gaat. In plaats daarvan gaat het verkeer ergens anders heen, zoals een Azure ExpressRoute-gateway of een virtueel apparaat. Als u uw App Service-omgeving op een dergelijke manier wilt configureren, raadpleegt u Het configureren van uw App Service-omgeving met geforceerde tunneling.

Wanneer u een App Service Environment maakt in de portal, maakt u automatisch een set routetabellen op het subnet. Deze routes zeggen dat uitgaand verkeer rechtstreeks naar internet moet worden verzonden.

Als u dezelfde routes handmatig wilt maken, voert u de volgende stappen uit:

1. Ga naar Azure Portal en selecteer Netwerkroutetabellen>.

2. Maak een nieuwe routetabel in dezelfde regio als uw virtuele netwerk.

3. Selecteer Routes>toevoegen vanuit de gebruikersinterface van de routetabel.

4. Stel het type Volgende hop in op Internet en het adresvoorvoegsel op 0.0.0.0/0. Selecteer Opslaan.

   Vervolgens ziet u iets als het volgende:

   

5. Nadat u de nieuwe routetabel hebt gemaakt, gaat u naar het subnet. Selecteer uw routetabel in de lijst in de portal. Nadat u de wijziging hebt opgeslagen, ziet u de NSG's en routes die zijn genoteerd met uw subnet.

   

Service-eindpunten

Met service-eindpunten kunt u de toegang tot services met meerdere tenants beperken tot een set virtuele Netwerken en subnetten van Azure. Zie Service-eindpunten voor virtueel netwerk voor meer informatie.

Wanneer u service-eindpunten voor een resource inschakelt, worden er routes met een hogere prioriteit gemaakt dan alle andere routes. Als u service-eindpunten gebruikt voor een Azure-service, met een geforceerde App Service-omgeving, wordt het verkeer naar deze services niet geforceerd geforceerd getunneld.

Wanneer service-eindpunten zijn ingeschakeld op een subnet met een exemplaar van Azure SQL, moeten alle Azure SQL-exemplaren die zijn verbonden met dat subnet, service-eindpunten hebben ingeschakeld. Als u vanuit hetzelfde subnet toegang wilt hebben tot meerdere Azure SQL-exemplaren, is het niet mogelijk om service-eindpunten wel op het ene Azure SQL-exemplaar in te schakelen en niet op een ander. Geen andere Azure-service gedraagt zich als Azure SQL met betrekking tot service-eindpunten. Wanneer u service-eindpunten inschakelt met Azure Storage, vergrendelt u de toegang tot die resource vanuit uw subnet. U hebt nog steeds toegang tot andere Azure Storage-accounts, zelfs als er geen service-eindpunten zijn ingeschakeld.