Nätverksöverväganden för en App Service-miljö

Viktigt!

Den här artikeln handlar om App Service Environment v2 som används med isolerade App Service-planer. App Service Environment v2 dras tillbaka den 31 augusti 2024. Det finns en ny version av App Service Environment som är enklare att använda och körs på kraftfullare infrastruktur. Om du vill veta mer om den nya versionen börjar du med Introduktion till App Service-miljön. Om du för närvarande använder App Service Environment v2 följer du stegen i den här artikeln för att migrera till den nya versionen.

Från och med den 29 januari 2024 kan du inte längre skapa nya App Service Environment v2-resurser med någon av de tillgängliga metoderna, inklusive ARM/Bicep-mallar, Azure Portal, Azure CLI eller REST API. Du måste migrera till App Service Environment v3 före den 31 augusti 2024 för att förhindra resursborttagning och dataförlust.

Den senaste informationen om tillbakadragning av App Service Environment v1/v2 finns i apptjänstmiljön v1 och v2.

App Service Environment är en distribution av Azure App Service till ett undernät i ditt virtuella Azure-nätverk. Det finns två distributionstyper för en App Service-miljö:

• Extern: Den här typen av distribution exponerar värdbaserade appar med hjälp av en IP-adress som är tillgänglig på Internet. Mer information finns i Skapa en extern App Service-miljö.
• Intern lastbalanserare: Den här typen av distribution exponerar värdbaserade appar på en IP-adress i det virtuella nätverket. Den interna slutpunkten är en intern lastbalanserare. Mer information finns i Skapa och använda en intern apptjänstmiljö för lastbalanserare.

Kommentar

Den här artikeln handlar om App Service Environment v2, som används med isolerade App Service-planer.

Oavsett distributionstyp har alla App Service-miljöer en offentlig virtuell IP-adress (VIP). Denna VIP används för inkommande hanteringstrafik och som adress när du gör anrop från App Service-miljön till Internet. Sådana anrop lämnar det virtuella nätverket via den VIP som tilldelats för App Service Environment.

Om apparna anropar resurser i ditt virtuella nätverk eller via ett VPN är käll-IP-adressen en av IP-adresserna i undernätet. Eftersom App Service Environment finns i det virtuella nätverket kan den också komma åt resurser i det virtuella nätverket utan någon ytterligare konfiguration. Om det virtuella nätverket är anslutet till ditt lokala nätverk har appar också åtkomst till resurser där utan ytterligare konfiguration.

 

Om du har en App Service-miljö med en extern distribution är den offentliga VIP:en också den slutpunkt som dina appar löser för följande:

• HTTP/S
• FTP/S
• Webbdistribution
• Fjärrfelsökning

Om du har en App Service-miljö med en intern distribution av lastbalanserare är adressen till den interna adressen slutpunkten för HTTP/S, FTP/S, webbdistribution och fjärrfelsökning.

Storlek på undernät

När App Service-miljön har distribuerats kan du inte ändra storleken på det undernät som används som värd för den. App Service Environment använder en adress för varje infrastrukturroll samt för varje isolerad App Service-planinstans. Dessutom använder Azure-nätverk fem adresser för varje undernät som skapas.

En App Service-miljö utan några App Service-planer alls använder 12 adresser innan du skapar en app. Om du använder den interna distributionen av lastbalanseraren använder den 13 adresser innan du skapar en app. När du skalar ut bör du vara medveten om att infrastrukturroller läggs till vid varje multipel av 15 och 20 av dina App Service-planinstanser.

Viktigt!

Inget annat kan finnas i undernätet förutom App Service-miljön. Se till att välja ett adressutrymme som möjliggör framtida tillväxt. Du kan inte ändra den här inställningen senare. Vi rekommenderar en storlek på /24 med 256 adresser.

När du skalar upp eller ned läggs nya roller av lämplig storlek till och sedan migreras dina arbetsbelastningar från den aktuella storleken till målstorleken. De ursprungliga virtuella datorerna tas bara bort efter att arbetsbelastningarna har migrerats. Om du till exempel hade en App Service-miljö med 100 App Service-planinstanser finns det en tidsperiod då du behöver dubbelt så många virtuella datorer.

Inkommande och utgående beroenden

Följande avsnitt beskriver beroenden som du bör känna till för din App Service-miljö. Ett annat avsnitt beskriver DNS-inställningar.

Inkommande beroenden

För att App Service-miljön ska fungera måste följande portar vara öppna:

Använd	Från	Till
Hantering	App Service-hanteringsadresser	App Service Environment-undernät: 454, 455
Intern kommunikation i App Service Environment	App Service Environment-undernät: Alla portar	App Service Environment-undernät: Alla portar
Tillåt inkommande Azure-lastbalanserare	Azure-lastbalanserare	App Service Environment-undernät: 16001

Portarna 7564 och 1221 kan visas som öppna vid en portgenomsökning. De svarar med en IP-adress och inget mer. Du kan blockera dem om du vill.

Den inkommande hanteringstrafiken ger kommando och kontroll över App Service-miljön, utöver systemövervakning. Källadresserna för den här trafiken visas i Hanteringsadresser för App Service Environment. Nätverkssäkerhetskonfigurationen måste tillåta åtkomst från App Service Environment-hanteringsadresserna på portarna 454 och 455. Om du blockerar åtkomsten från dessa adresser blir App Service-miljön inte felfri och pausas sedan. Den TCP-trafik som kommer in på portarna 454 och 455 måste gå tillbaka ut från samma VIP, annars har du ett asymmetriskt routningsproblem.

I undernätet finns det många portar som används för intern komponentkommunikation och de kan ändras. Detta kräver att alla portar i undernätet är tillgängliga från undernätet.

För kommunikation mellan Azure-lastbalanseraren och App Service Environment-undernätet är de minsta portarna som måste vara öppna 454, 455 och 16001. Om du använder en intern lastbalanserare kan du låsa trafiken till bara portarna 454, 455 och 16001. Om du använder en extern distribution måste du ta hänsyn till de normala portarna för appåtkomst. Mer specifikt är följande:

Använd	Hamnar
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Fjärrfelsökning i Visual Studio	4020, 4022, 4024
Webbdistributionstjänst	8172

Om du blockerar programportarna kan din App Service-miljö fortfarande fungera, men det kanske inte är din app. Om du använder apptilldelade IP-adresser med en extern distribution måste du tillåta trafik från IP-adresser som tilldelats dina appar till undernätet. Från App Service Environment-portalen går du till IP-adresser och ser de portar som du behöver tillåta trafik från.

Utgående beroenden

För utgående åtkomst är en App Service-miljö beroende av flera externa system. Många av dessa systemberoenden definieras med DNS-namn och mappas inte till en fast uppsättning IP-adresser. App Service-miljön kräver därför utgående åtkomst från undernätet till alla externa IP-adresser över en mängd olika portar.

App Service Environment kommunicerar ut till internettillgängliga adresser på följande portar:

Användningar	Hamnar
DNS	53
NTP	123
CRL, Windows-uppdateringar, Linux-beroenden, Azure-tjänster	80/443
Azure SQL	1433
Övervakning	12000

De utgående beroendena visas i Låsa en App Service-miljö. Om App Service-miljön förlorar åtkomsten till dess beroenden slutar den att fungera. När det händer under en tillräckligt lång tidsperiod pausas det.

Kundens DNS

Om det virtuella nätverket har konfigurerats med en kunddefinierad DNS-server använder klientorganisationsarbetsbelastningarna den. App Service Environment använder Azure DNS i hanteringssyfte. Om det virtuella nätverket har konfigurerats med en kundvald DNS-server måste DNS-servern kunna nås från undernätet.

Kommentar

Lagringsmonteringar eller containeravbildningshämtningar i App Service Environment v2 kan inte använda kunddefinierad DNS i det virtuella nätverket eller via appinställningen WEBSITE_DNS_SERVER .

Om du vill testa DNS-matchning från webbappen kan du använda konsolkommandot nameresolver. Gå till felsökningsfönstret på din scm webbplats för din app eller gå till appen i portalen och välj konsol. Från kommandotolken kan du utfärda kommandot nameresolver, tillsammans med det DNS-namn som du vill söka efter. Resultatet du får tillbaka är detsamma som din app skulle få när du gjorde samma sökning. Om du använder nslookupgör du en sökning med hjälp av Azure DNS i stället.

Om du ändrar DNS-inställningen för det virtuella nätverk som apptjänstmiljön finns i måste du starta om. För att undvika omstart är det en bra idé att konfigurera DNS-inställningarna för ditt virtuella nätverk innan du skapar din App Service-miljö.

Portalberoenden

Förutom de beroenden som beskrivs i föregående avsnitt finns det några extra överväganden som du bör känna till som är relaterade till portalupplevelsen. Vissa av funktionerna i Azure-portalen är beroende av direkt åtkomst till SCM-webbplatsen (source control manager). För varje app i Azure App Service finns det två URL:er. Den första URL:en är att komma åt din app. Den andra URL:en är att komma åt SCM-webbplatsen, som även kallas Kudu-konsolen. Funktioner som använder SCM-webbplatsen är:

• Webbjobb
• Funktioner
• Loggdirektuppspelning
• Kudu
• Tillägg
• Processutforskaren
• Konsol

När du använder en intern lastbalanserare är SCM-platsen inte tillgänglig utanför det virtuella nätverket. Vissa funktioner fungerar inte från appportalen eftersom de kräver åtkomst till SCM-webbplatsen för en app. Du kan ansluta till SCM-webbplatsen direkt i stället för med hjälp av portalen.

Om den interna lastbalanseraren är domännamnet contoso.appserviceenvironment.netoch appnamnet är testappen nås appen på testapp.contoso.appserviceenvironment.net. SCM-platsen som medföljer nås på testapp.scm.contoso.appserviceenvironment.net.

IP-adresser

En App Service-miljö har några IP-adresser att känna till. Dessa är:

• Offentlig inkommande IP-adress: Används för apptrafik i en extern distribution och hanteringstrafik i både interna och externa distributioner.
• Utgående offentlig IP-adress: Används som "från"-IP för utgående anslutningar som lämnar det virtuella nätverket. De här anslutningarna dirigeras inte ned från ett VPN.
• Ip-adress för intern lastbalanserare: Den här adressen finns bara i en intern distribution.
• Apptilldelade IP-baserade TLS/SSL-adresser: Dessa adresser är endast möjliga med en extern distribution och när IP-baserad TLS/SSL-bindning har konfigurerats.

Alla dessa IP-adresser visas i Azure-portalen från App Service Environment-användargränssnittet. Om du har en intern distribution visas IP-adressen för den interna lastbalanseraren.

Kommentar

Dessa IP-adresser ändras inte så länge apptjänstmiljön körs. Om apptjänstmiljön pausas och sedan återställs ändras de adresser som används. Den normala orsaken till en avstängning är om du blockerar åtkomst till inkommande hantering eller om du blockerar åtkomst till ett beroende.

Apptilldelade IP-adresser

Med en extern distribution kan du tilldela IP-adresser till enskilda appar. Du kan inte göra det med en intern distribution. Mer information om hur du konfigurerar din app för att ha en egen IP-adress finns i Skydda ett anpassat DNS-namn med en TLS/SSL-bindning i Azure App Service.

När en app har en egen IP-baserad SSL-adress reserverar App Service Environment två portar för mappning till den IP-adressen. En port är för HTTP-trafik och den andra porten är för HTTPS. Dessa portar visas i avsnittet IP-adresser i App Service Environment-portalen. Trafiken måste kunna nå dessa portar från VIP:en. Annars är apparna otillgängliga. Det här kravet är viktigt att komma ihåg när du konfigurerar nätverkssäkerhetsgrupper (NSG:er).

Nätverkssäkerhetsgrupper

NSG:er ger möjlighet att styra nätverksåtkomsten i ett virtuellt nätverk. När du använder portalen finns det en implicit neka-regel med den lägsta prioriteten för att neka allt. Det du skapar är dina tillåtna regler.

Du har inte åtkomst till de virtuella datorer som används som värd för själva App Service-miljön. De finns i en prenumeration som Microsoft hanterar. Om du vill begränsa åtkomsten till apparna anger du NSG:er i undernätet. Var noga med beroendena när du gör det. Om du blockerar eventuella beroenden slutar App Service Environment att fungera.

Du kan konfigurera NSG:er via Azure-portalen eller via PowerShell. Informationen här visar Azure-portalen. Du skapar och hanterar NSG:er i portalen som en resurs på den översta nivån under Nätverk.

De poster som krävs i en NSG är att tillåta trafik:

Inkommande

• TCP från IP-tjänsttaggen AppServiceManagement på portarna 454, 455
• TCP från lastbalanseraren på port 16001
• Från App Service Environment-undernätet till App Service Environment-undernätet på alla portar

Utgående

• UDP till alla IP-adresser på port 53
• UDP till alla IP-adresser på port 123
• TCP till alla IP-adresser på portarna 80, 443
• TCP till IP-tjänsttaggen Sql på port 1433
• TCP till alla IP-adresser på port 12000
• Till App Service Environment-undernätet på alla portar

De här portarna innehåller inte de portar som dina appar kräver för lyckad användning. Anta till exempel att din app måste anropa en MySQL-server på port 3306. Network Time Protocol (NTP) på port 123 är det tidssynkroniseringsprotokoll som används av operativsystemet. NTP-slutpunkterna är inte specifika för App Service, kan variera med operativsystemet och finns inte i en väldefinierad lista med adresser. För att förhindra problem med tidssynkronisering måste du sedan tillåta UDP-trafik till alla adresser på port 123. Den utgående TCP-till-port 12000-trafiken är avsedd för systemstöd och analys. Slutpunkterna är dynamiska och finns inte i en väldefinierad uppsättning adresser.

De normala appåtkomstportarna är:

Använd	Hamnar
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Fjärrfelsökning i Visual Studio	4020, 4022, 4024
Webbdistributionstjänst	8172

En standardregel gör att IP-adresserna i det virtuella nätverket kan kommunicera med undernätet. En annan standardregel gör det möjligt för lastbalanseraren, även kallad offentlig VIP, att kommunicera med App Service Environment. Om du vill se standardreglerna väljer du Standardregler (bredvid ikonen Lägg till).

Om du anger att allt annat ska nekas före standardreglerna förhindrar du trafik mellan VIP och App Service-miljön. Om du vill förhindra att trafik kommer inifrån det virtuella nätverket lägger du till din egen regel för att tillåta inkommande trafik. Använd en källa som är lika AzureLoadBalancermed , med ett mål för Alla och ett portintervall på *. Eftersom NSG-regeln tillämpas på undernätet behöver du inte vara specifik i målet.

Om du har tilldelat en IP-adress till din app kontrollerar du att portarna är öppna. Om du vill se portarna väljer du IP-adresser för App Service Environment>.  

När NSG:erna har definierats tilldelar du dem till undernätet. Om du inte kommer ihåg det virtuella nätverket eller undernätet kan du se det från App Service Environment-portalen. Om du vill tilldela NSG:n till undernätet går du till undernätets användargränssnitt och väljer NSG.

Vägar

Tvingad tunneltrafik är när du anger vägar i det virtuella nätverket så att den utgående trafiken inte går direkt till Internet. I stället går trafiken någon annanstans, till exempel en Azure ExpressRoute-gateway eller en virtuell installation. Om du behöver konfigurera Din App Service-miljö på ett sådant sätt kan du läsa Konfigurera Din App Service-miljö med tvingad tunneltrafik.

När du skapar en App Service-miljö i portalen skapar du automatiskt en uppsättning routningstabeller i undernätet. Dessa vägar säger helt enkelt att skicka utgående trafik direkt till Internet.

Följ dessa steg för att skapa samma vägar manuellt:

1. Gå till Azure-portalen och välj Routningstabeller för>nätverk.

2. Skapa en ny routningstabell i samma region som ditt virtuella nätverk.

3. Från användargränssnittet för routningstabellen väljer du Vägar>Lägg till.

4. Ange Typen Nästa hopp till Internet och adressprefixet till 0.0.0.0/0. Välj Spara.

   Sedan ser du något som liknar följande:

   

5. När du har skapat den nya routningstabellen går du till undernätet. Välj routningstabellen i listan i portalen. När du har sparat ändringen bör du sedan se NSG:er och vägar som anges med ditt undernät.

   

Tjänstslutpunkter

Med tjänstslutpunkter kan du begränsa åtkomsten till tjänster för flera klientorganisationer till en uppsättning virtuella Azure-nätverk och undernät. Mer information finns i Tjänstslutpunkter för virtuellt nätverk.

När du aktiverar tjänstslutpunkter på en resurs skapas vägar med högre prioritet än alla andra vägar. Om du använder tjänstslutpunkter på någon Azure-tjänst, med en apptjänstmiljö med tvingad tunneltrafik, är trafiken till dessa tjänster inte tvingad tunneltrafik.

När tjänstslutpunkter är aktiverade i ett undernät med en instans av Azure SQL måste alla Azure SQL-instanser som är anslutna till från det undernätet ha tjänstslutpunkter aktiverade. Om du vill ha åtkomst till flera Azure SQL-instanser från samma undernät kan du inte aktivera tjänstslutpunkter på en Azure SQL-instans och inte på en annan. Ingen annan Azure-tjänst fungerar som Azure SQL när det gäller tjänstslutpunkter. När du aktiverar tjänstslutpunkter med Azure Storage låser du åtkomsten till resursen från undernätet. Du kan dock fortfarande komma åt andra Azure Storage-konton, även om de inte har tjänstslutpunkter aktiverade.