Netwerkoverwegingen voor een App Service Environment v2

Overzicht

Azure 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 (ASE):

• Externe ASE: toont de door ASE gehoste apps op een IP-adres dat toegankelijk is via internet. Zie Create an External ASE (Een externe ASE maken) voor meer informatie.
• ILB AS-omgeving: toont de door ASE gehoste apps op een IP-adres in uw virtuele netwerk. Het interne eindpunt is een interne load balancer (ILB), daarom wordt het een ILB AS-account genoemd. Zie Create and use an ILB ASE (Een ILB ASEmaken en gebruiken) voor meer informatie.

Alle AS-adressen, Extern en ILB, hebben een openbaar VIP dat wordt gebruikt voor inkomende beheerverkeer en als het adres bij het maken van aanroepen van de ASE naar internet. De aanroepen van een AS-omgeving die naar internet gaan, verlaten het virtuele netwerk via het VIP dat is toegewezen voor de AS-omgeving. Het openbare IP-adres van dit VIP is het bron-IP-adres voor alle aanroepen van de ASE die naar internet gaan. Als de apps in uw ASE resources in uw virtuele netwerk of via een VPN aanroepen, is het bron-IP-adres een van de IP-adressen in het subnet dat wordt gebruikt door uw AS-omgeving. Omdat de AS-omgeving zich binnen het virtuele netwerk, 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 in uw AS-omgeving ook toegang tot resources zonder aanvullende configuratie.

Als u een externe ASE hebt, is het openbare VIP ook het eindpunt waar uw ASE-apps naar oplossen:

• HTTP/S
• FTP/S
• Webimplementatie
• Foutopsporing op afstand

Als u een ILB AS-adres hebt, is het adres van het ILB-adres het eindpunt voor HTTP/S, FTP/S, webimplementatie en externe debugging.

AsE-subnetgrootte

De grootte van het subnet dat wordt gebruikt om een ASE te hosten, kan niet worden gewijzigd nadat de ASE is geïmplementeerd. De ASE gebruikt een adres voor elke infrastructuurrol en voor elk exemplaar van het isolated App Service plan. Daarnaast zijn er vijf adressen die worden gebruikt door Azure-netwerken voor elk subnet dat wordt gemaakt. Een ASE zonder App Service gebruikt 12 adressen voordat u een app maakt. Als het een ILB AS-adres is, worden er 13 adressen gebruikt voordat u een app in die ASE maakt. Wanneer u uw ASE uitschaalt, worden elke veelvoud van 15 en 20 van uw App Service toegevoegd.

Wanneer u omhoog of omlaag schaalt, worden er nieuwe rollen met 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 een ASE met 100 ASP-exemplaren hebt, is er een periode waarin u het dubbele van het aantal VM's nodig hebt. Daarom raden we het gebruik van een '/24' aan om eventuele wijzigingen aan te kunnen.

ASE-afhankelijkheden

Inkomende afhankelijkheden van ASE

Alleen als de ASE werkt, moeten de volgende poorten zijn geopend voor de ASE:

Er zijn twee andere poorten die kunnen worden weer geven als open op een poortscan, 7654 en 1221. Ze antwoorden met een IP-adres en niets meer. Indien gewenst kunnen ze worden geblokkeerd.

Het binnenkomende beheerverkeer biedt command and control van de ASE naast systeembewaking. De bronadressen voor dit verkeer worden vermeld in het document ASE-beheeradressen. De netwerkbeveiligingsconfiguratie moet toegang toestaan vanaf de ASE-beheeradressen op de poorten 454 en 455. Als u de toegang tot die adressen blokkeert, wordt uw ASE niet in orde en wordt deze vervolgens geblokkeerd. Het TCP-verkeer dat binnenkomt op de poorten 454 en 455 moet teruggaan van hetzelfde VIP, anders hebt u een asymmetrisch routeringsprobleem.

Binnen het ASE-subnet worden veel poorten gebruikt voor interne onderdeelcommunicatie en deze kunnen worden gewijzigd. Hiervoor moeten alle poorten in het ASE-subnet toegankelijk zijn vanaf het ASE-subnet.

Voor de communicatie tussen de Azure load balancer en het ASE-subnet zijn 454, 455 en 16001 de poorten die open moeten zijn. De poort 16001 wordt gebruikt voor het behouden van verkeer tussen de load balancer en de ASE. Als u een ILB ASE gebruikt, kunt u verkeer vergrendelen tot alleen de poorten 454, 455 en 16001. Als u een externe ASE gebruikt, moet u rekening houden met de normale toegangspoorten voor apps.

De andere poorten die u voor uzelf moet gebruiken, zijn de toepassingspoorten:

Als u de toepassingspoorten blokkeert, kan uw ASE nog steeds functioneren, maar uw app mogelijk niet. Als u door de app toegewezen IP-adressen gebruikt met een externe ASE, moet u verkeer toestaan van de IP-adressen die zijn toegewezen aan uw apps naar het ASE-subnet op de poorten die worden weergegeven op de pagina IP-adressen van de ASE-portal > IP-adressen.

Uitgaande afhankelijkheden van ASE

Voor uitgaande toegang is een ASE afhankelijk van meerdere externe systemen. Veel van deze systeemafhankelijkheden worden gedefinieerd met DNS-namen en zijn niet toe te voegen aan een vaste set IP-adressen. Daarom vereist de ASE uitgaande toegang van het ASE-subnet naar alle externe IP's via verschillende poorten.

De ASE communiceert via de volgende poorten met adressen die toegankelijk zijn voor internet:

De uitgaande afhankelijkheden worden vermeld in het document waarin het vergrendelen van App Service Environment uitgaand verkeer wordt beschreven. Als de ASE geen toegang meer heeft tot de afhankelijkheden, werkt deze niet meer. Als dat lang genoeg gebeurt, wordt de ASE tijdelijk opgeschort.

KLANT-DNS

Als het virtuele netwerk is geconfigureerd met een door de klant gedefinieerde DNS-server, gebruiken de tenantworkloads deze. De ASE gebruikt 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 dat de ASE bevat.

Als u de DNS-resolutie van uw web-app wilt testen, kunt u de consoleopdrachtnaamresolver gebruiken. Ga naar het foutopsporingsvenster op uw SCM-site voor uw app of ga naar de app in de portal en selecteer console. Vanaf de shell-prompt kunt u de opdrachtnaamresolver geven, samen met de DNS-naam die u wilt op zoeken. Het resultaat dat u krijgt, is hetzelfde als wat uw app zou krijgen terwijl u dezelfde zoekactie zou maken. Als u nslookup gebruikt, kunt u in plaats daarvan een zoekactie Azure DNS.

Als u de DNS-instelling van het virtuele netwerk waarin uw AS-omgeving zich in zich, moet u de AS-omgeving opnieuw opstarten. Om te voorkomen dat uw ASE opnieuw wordt opgestart, wordt u ten zeerste aangeraden uw DNS-instellingen voor uw virtuele netwerk te configureren voordat u uw AS-omgeving maakt.

Portal dependencies (Portal-afhankelijkheden)

Naast de functionele afhankelijkheden van ASE zijn er enkele extra items die betrekking hebben op de portalervaring. Sommige van de mogelijkheden in de Azure Portal zijn afhankelijk van directe toegang tot de SCM-site. 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
• Functions
• Logboekstreaming
• Kudu
• Uitbreidingen
• Procesverkenner
• Console

Wanneer u een ILB AS-omgeving 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 de portal te gebruiken.

Als uw ILB AS-domein de domeinnaam is contoso.appserviceenvironment.net en uw app-naam testapp is, wordt de app bereikt op testapp.contoso.appserviceenvironment.net. De SCM-site die bij deze site past, wordt bereikt op testapp.scm.contoso.appserviceenvironment.net.

IP-adressen van ASE

Een ASE heeft een aantal IP-adressen om rekening mee te houden. Dit zijn:

• Openbaar binnenkomende IP-adres: wordt gebruikt voor app-verkeer in een externe ASE en beheerverkeer in zowel een externe ASE als een ILB ASE.
• Uitgaand openbaar IP-adres: wordt gebruikt als het 'van'-IP-adres voor uitgaande verbindingen van de ASE die het virtuele netwerk verlaten, die niet via een VPN worden gerouteerd.
• IP-adres van ILB: het IP-adres van de ILB bestaat alleen in een ILB AS-adres.
• Door de app toegewezen TLS/SSL-adressen op basis van IP: dit is alleen mogelijk met een externe ASE en wanneer TLS/SSL-binding op basis van IP is geconfigureerd.

Al deze IP-adressen zijn zichtbaar in de Azure Portal van de ASE-gebruikersinterface. Als u een ILB AS-adres hebt, wordt het IP-adres voor de ILB weergegeven.

Door de app toegewezen IP-adressen

Met een externe ASE kunt u IP-adressen toewijzen aan afzonderlijke apps. U kunt dat niet doen met een ILB ASE. Zie Een aangepaste DNS-naam beveiligen met een TLS/SSL-binding inAzure App Service voor meer informatie over het configureren van uw app om een eigen IP-adres te Azure App Service.

Wanneer een app een eigen SSL-adres op basis van IP heeft, reserveert de ASE twee poorten om aan dat IP-adres toe te staan. De ene poort is voor HTTP-verkeer en de andere voor HTTPS. Deze poorten worden vermeld in de ASE-gebruikersinterface in de sectie IP-adressen. Verkeer moet deze poorten kunnen bereiken via het VIP, anders zijn de apps niet toegankelijk. Deze vereiste is belangrijk om te onthouden wanneer u netwerkbeveiligingsgroepen (NSG's) configureert.

Netwerkbeveiligingsgroepen

Netwerkbeveiligingsgroepen bieden de mogelijkheid om netwerktoegang binnen een virtueel netwerk te controleren. Wanneer u het portal gebruikt, is er een impliciete regel voor weigeren met de laagste prioriteit om alles te weigeren. Wat u bouwt, zijn uw regels voor toestaan.

In een ASE hebt u geen toegang tot de VM's die worden gebruikt om de ASE zelf te hosten. Ze maken gebruik van een door Microsoft beheerd abonnement. Als u de toegang tot de apps op de ASE wilt beperken, stelt u NSG's in op het ASE-subnet. Let daarbij goed op de ASE-afhankelijkheden. Als u afhankelijkheden blokkeert, werkt de ASE niet meer.

NSG's kunnen worden geconfigureerd via de 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, om een ASE te laten functioneren, zijn om verkeer toe te staan:

Inkomend verkeer

• TCP van de IP-servicetag AppServiceManagement op poort 454.455
• TCP vanaf de load balancer op poort 16001
• van het ASE-subnet naar het ASE-subnet op alle poorten

Uitgaand

• UDP naar alle IP's op poort 53
• UDP naar alle IP's op poort 123
• TCP naar alle IP's op poorten 80, 443
• TCP naar de IP-servicetag Sql op poorten 1433
• TCP naar alle IP's op poort 12000
• naar het ASE-subnet op alle poorten

Deze poorten bevatten niet de poorten die uw apps nodig hebben voor een geslaagd gebruik. Uw app moet bijvoorbeeld mogelijk een MySQL-server 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 Services, kunnen variëren met het besturingssysteem en staan niet in een goed gedefinieerde lijst met adressen. Om problemen met tijdsynchronisatie te 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 staan niet in een goed gedefinieerde set adressen.

De normale toegangspoorten voor apps zijn:

Wanneer rekening wordt gehouden met de vereisten voor binnenkomende en uitgaande verkeer, moeten de NSG's er ongeveer uitzien als de NSG's die in dit voorbeeld worden weergegeven.

Met een standaardregel kunnen de IP's in het virtuele netwerk met het ASE-subnet praten. Een andere standaardregel stelt de load balancer, ook wel bekend als het openbare VIP, in staat om te communiceren met de ASE. Als u de standaardregels wilt zien, selecteert u Standaardregels naast het pictogram Toevoegen. Als u een regel voor alles weigeren gebruikt vóór de standaardregels, voorkomt u verkeer tussen het VIP en de ASE. Als u wilt voorkomen dat verkeer afkomstig is van het virtuele netwerk, voegt u uw eigen regel toe om inkomende gegevens toe te staan. Gebruik een bron die gelijk is aan AzureLoadBalancer met de bestemming Any en een poortbereik van * . Omdat de NSG-regel wordt toegepast op het ASE-subnet, hoeft u niet specifiek te zijn in het doel.

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 App Service Environment > IP-adressen.

Alle items die worden weergegeven in de volgende uitgaande regels zijn nodig, met uitzondering van het laatste item. Ze maken netwerktoegang mogelijk tot de ASE-afhankelijkheden die eerder in dit artikel zijn genoteerd. Als u een van deze blokkeert, werkt uw ASE niet meer. Met het laatste item in de lijst kan uw ASE communiceren met andere resources in uw virtuele netwerk.

Nadat uw NSG's zijn gedefinieerd, wijst u deze toe aan het subnet waar uw AS-omgeving zich in heeft. Als u het virtuele ase-netwerk of subnet niet meer weet, kunt u het zien op de pagina van de ASE-portal. Als u de NSG aan uw subnet wilt toewijzen, gaat u naar de gebruikersinterface van het subnet en selecteert u de NSG.

Routes

Bij geforceerd tunnelen stelt u routes in uw virtuele netwerk in, zodat het uitgaande verkeer niet rechtstreeks naar internet gaat, maar naar een andere plaats, zoals een ExpressRoute-gateway of een virtueel apparaat. Als u uw ASE op een dergelijke manier moet configureren, zie Uw App Service Environment configureren met Geforceerd tunnelen. In dit document ziet u welke opties beschikbaar zijn om te werken met ExpressRoute en geforceerd tunnelen.

Wanneer u een ASE maakt in de portal, maken we ook een set routetabellen in het subnet dat met de ASE wordt gemaakt. Deze routes zeggen alleen dat uitgaand verkeer rechtstreeks naar internet wordt verzenden.
Als u dezelfde routes handmatig wilt maken, volgt u deze stappen:

1. Ga naar Azure Portal. Selecteer > Netwerkroutetabellen.

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

3. Selecteer routes toevoegen in de gebruikersinterface van de > routetabel.

4. Stel het hoptype Volgende in op Internet en het Adres-voorvoegsel op 0.0.0.0/0. Selecteer Opslaan.

   Vervolgens ziet u iets dat er als volgt uit ziet:

   

5. Nadat u de nieuwe routetabel hebt maken, gaat u naar het subnet dat uw ASE bevat. Selecteer uw routetabel in de lijst in de portal. Nadat u de wijziging hebt op slaan, ziet u de NSG's en routes die bij uw subnet zijn vermeld.

   

Service-eindpunten

Met service-eindpunten kunt u de toegang tot multitenant-services beperken tot een reeks virtuele Azure-netwerken en subnetten. In de documentatie Virtual Network Service Endpoints (Service-eindpunten voor virtuele netwerken) vindt u meer informatie over service-eindpunten.

Wanneer u service-eindpunten voor een bron inschakelt, worden er routes gemaakt die een hogere prioriteit hebben dan alle andere routes. Als u service-eindpunten gebruikt op een Azure-service, met een geforceerd getunnelde ASE, wordt het verkeer naar deze services niet geforceerd getunneld.

Als Service-eindpunten in een subnet met een Azure SQL-exemplaar is ingeschakeld, moet Service-eindpunten zijn ingeschakeld op alle Azure SQL-exemplaren waarmee vanuit dat subnet een verbinding wordt gemaakt. 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 enkele andere Azure-service gedraagt zich als Azure SQL met betrekking tot service-eindpunten. Wanneer u Service-eindpunten met Azure Storage inschakelt, kunt u de toegang tot die resource vanuit uw subnet vergrendelen en toegang behouden tot andere Azure Storage-accounts, zelfs als Service-eindpunten op die accounts niet is ingeschakeld.