Nätverksöverväganden för en App Service-miljö
Viktigt!
Den här artikeln handlar om App Service-miljön v2 som används med isolerade App Service-planer. App Service-miljön v2 dras tillbaka den 31 augusti 2024. Det finns en ny version av App Service-miljön som är enklare att använda och köra 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-miljön 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-miljön 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-miljön v3 före den 31 augusti 2024 för att förhindra resursborttagning och dataförlust.
App Service-miljön ä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ön:
- 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ön.
- 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 lastbalanserare App Service-miljön.
Kommentar
Den här artikeln handlar om App Service-miljön v2, som används med isolerade App Service-planer.
Oavsett distributionstyp har alla App Service-miljön 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-miljön.
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-miljön 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ön 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ön med en intern 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 det. App Service-miljön 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ön som inte har 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, men 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ön 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 dina App Service-miljön. 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 | To |
|---|---|---|
| Hantering | App Service-hanteringsadresser | App Service-miljön undernät: 454, 455 |
| App Service-miljön intern kommunikation | App Service-miljön undernät: Alla portar | App Service-miljön undernät: Alla portar |
| Tillåt inkommande Azure-lastbalanserare | Azure-lastbalanserare | App Service-miljön 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, förutom systemövervakning. Källadresserna för den här trafiken visas i App Service-miljön hanteringsadresser. Nätverkssäkerhetskonfigurationen måste tillåta åtkomst från App Service-miljön hanteringsadresser på portarna 454 och 455. Om du blockerar åtkomsten från dessa adresser blir din 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-miljön undernät ä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ön fortfarande fungera, men appen kanske inte gör det. 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-miljön-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ön beroende av flera externa system. Många av dessa systemberoenden definieras med DNS-namn och mappas inte till en fast uppsättning IP-adresser. Därför kräver App Service-miljön utgående åtkomst från undernätet till alla externa IP-adresser över en mängd olika portar.
App Service-miljön 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ön. Om App Service-miljön förlorar åtkomsten till dess beroenden slutar det 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-miljön 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 containeravbildningar som hämtas i App Service-miljön v2 kan inte använda kunddefinierad DNS i det virtuella nätverket eller via appinställningenWEBSITE_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 din App Service-miljö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 App Service-miljön.
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ön 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-miljön 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 App Service-miljön körs. Om din App Service-miljö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-miljön 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-miljön-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 beroenden slutar App Service-miljön 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
AppServiceManagementpå portarna 454, 455 - TCP från lastbalanseraren på port 16001
- Från App Service-miljön-undernätet till App Service-miljön-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
Sqlpå port 1433 - TCP till alla IP-adresser på port 12000
- Till App Service-miljön-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-miljön. Om du vill se standardreglerna väljer du Standardregler (bredvid ikonen Lägg till).
Om du lägger en neka allt annat regel 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 App Service-miljön> IP-adresser.
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-miljön-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 App Service-miljön på ett sådant sätt kan du läsa Konfigurera App Service-miljön med tvingad tunneltrafik.
När du skapar en App Service-miljön 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:
Gå till Azure-portalen och välj Routningstabeller för>nätverk.
Skapa en ny routningstabell i samma region som ditt virtuella nätverk.
Från användargränssnittet för routningstabellen väljer du Vägar>Lägg till.
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:
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 tvingad tunneltrafik App Service-miljön, ä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.
