Nätverksöverväganden för en App Service-miljön v2
Anteckning
Den här artikeln handlar om App Service-miljön v2 som används med isolerade App Service planer
Översikt
Azure 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ö (ASE):
- Extern ASE: Exponerar ASE-värdbaserade appar på en Internet-tillgänglig IP-adress. Mer information finns i Skapa en extern ASE.
- ILB ASE: Exponerar ASE-värdbaserade appar på en IP-adress i ditt virtuella nätverk. Den interna slutpunkten är en intern lastbalanserare (ILB), vilket är anledningen till att den kallas för en ILB ASE. Mer information finns i Skapa och använda en ILB ASE.
Alla ASE:er, externa och ILB, har en offentlig VIP som används för inkommande hanteringstrafik och som från-adressen vid anrop från ASE till Internet. Anropen från en ASE som går till Internet lämnar det virtuella nätverket via den VIP som tilldelats för ASE. Den offentliga IP-adressen för denna VIP är käll-IP för alla anrop från ASE som går till Internet. Om apparna i din ASE gör anrop till resurser i ditt virtuella nätverk eller via ett VPN är käll-IP-adressen en av IP-adresserna i undernätet som används av din ASE. Eftersom ASE finns i det virtuella nätverket kan den även 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 i din ASE också åtkomst till resurser där utan ytterligare konfiguration.

Om du har en extern ASE är den offentliga VIP-adressen även den slutpunkt som ase-apparna matchar för:
- HTTP/S
- FTP/S
- Webbdistribution
- Fjärrfelsökning

Om du har en ILB ASE är adressen till ILB-adressen slutpunkten för HTTP/S, FTP/S, webbdistribution och fjärrfelsökning.
ASE-undernätsstorlek
Storleken på undernätet som används som värd för en ASE kan inte ändras när ASE har distribuerats. ASE använder en adress för varje infrastrukturroll samt för varje isolerad App Service plan instans. Dessutom finns det fem adresser som används av Azure-nätverkstjänster för varje undernät som skapas. En ASE utan App Service planer använder 12 adresser innan du skapar en app. Om det är en ILB ASE använder den 13 adresser innan du skapar en app i denna ASE. När du skalar ut din ASE läggs infrastrukturroller till var och en av 15 och 20 av dina App Service plan instanser.
Anteckning
Inget annat kan finnas i undernätet förutom ASE. 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 med lämplig storlek till och sedan migreras dina arbetsbelastningar från den aktuella storleken till målstorleken. De ursprungliga virtuella datorerna tas bara bort när arbetsbelastningarna har migrerats. Om du hade en ASE med 100 ASP-instanser skulle det finnas en period där du behöver dubbla antalet virtuella datorer. Därför rekommenderar vi att du använder en "/24" för att hantera eventuella ändringar som du kan behöva.
ASE-beroenden
ASE-inkommande beroenden
För att ASE ska fungera kräver ASE att följande portar är öppna:
| Användning | Från | Om du vill |
|---|---|---|
| Hantering | App Service hanteringsadresser | ASE-undernät: 454, 455 |
| Intern ASE-kommunikation | ASE-undernät: Alla portar | ASE-undernät: Alla portar |
| Tillåt inkommande azure-lastbalanserare | Azure-lastbalanserare | ASE-undernät: 16001 |
Det finns två andra portar som kan visas som öppna i en portgenomsökning, 7654 och 1221. De svarar med en IP-adress och inget mer. De kan blockeras om du vill.
Inkommande hanteringstrafik ger command and control av ASE utöver systemövervakning. Källadresserna för den här trafiken visas i dokumentet ASE-hanteringsadresser. Nätverkssäkerhetskonfigurationen måste tillåta åtkomst från ASE-hanteringsadresserna på portarna 454 och 455. Om du blockerar åtkomst från dessa adresser kommer din ASE att bli skadad och sedan pausas. TCP-trafiken som kommer in på portarna 454 och 455 måste gå tillbaka från samma VIP, annars uppstår ett problem med asymmetrisk routning.
I ASE-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 ASE-undernätet är tillgängliga från ASE-undernätet.
För kommunikationen mellan Azure-lastbalanseraren och ASE-undernätet är de portar som minst måste vara öppna 454, 455 och 16001. 16001-porten används för att hålla trafiken mellan lastbalanseraren och ASE:en levande. Om du använder en ILB ASE kan du låsa trafiken till portarna 454, 455, 16001. Om du använder en extern ASE måste du ta hänsyn till de vanliga appåtkomstportarna.
De andra portarna som du behöver bekymra dig om är programportarna:
| Användning | Portar |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Visual Studio fjärrfelsökning | 4020, 4022, 4024 |
| Webbtjänst för distribution av webben | 8172 |
Om du blockerar programportarna kan din ASE fortfarande fungera, men appen kanske inte fungerar. Om du använder app-tilldelade IP-adresser med en extern ASE måste du tillåta trafik från DE IP-adresser som tilldelats dina appar till ASE-undernätet på portarna som visas på sidan för ASE->-IP-adresser.
UTGÅENDE ASE-beroenden
För utgående åtkomst är en ASE beroende av flera externa system. Många av dessa systemberoenden definieras med DNS-namn och mappar inte till en fast uppsättning IP-adresser. Ase kräver därför utgående åtkomst från ASE-undernätet till alla externa IP-adresser över en mängd olika portar.
ASE kommunicerar ut till Internet-tillgängliga adresser på följande portar:
| Användningar | Portar |
|---|---|
| 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 dokumentet som beskriver hur du låser App Service-miljön utgående trafik. Om ASE förlorar åtkomst till sina beroenden slutar det att fungera. När det inträffar tillräckligt länge pausas ASE:en.
Kundens DNS
Om det virtuella nätverket har konfigurerats med en kunddefinierad DNS-server använder klientarbetsbelastningarna den. ASE: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 det undernät som innehåller ASE.
Anteckning
Storage monteringar eller containeravbildningar som tas i ASEv2 kommer inte att kunna använda kundens DNS som definierats i det virtuella nätverket eller WEBSITE_DNS_SERVER via appinställningen.
Om du vill testa DNS-upplösningen från webbappen kan du använda konsolkommandonamnetlösen. 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 shell-prompten kan du utfärda kommandonamnetlösen tillsammans med det DNS-namn som du vill leta upp. Resultatet du får tillbaka är detsamma som vad din app får när du gör samma sökning. Om du använder nslookup gör du en sökning med hjälp av Azure DNS stället.
Om du ändrar DNS-inställningen för det virtuella nätverk som ase-enheten finns i måste du starta om ASE. För att undvika att starta om ase-enheten rekommenderar vi starkt att du konfigurerar DNS-inställningarna för ditt virtuella nätverk innan du skapar ase-enheten.
Portalberoenden
Förutom de funktionella ASE-beroendena finns det några extra objekt relaterade till portalupplevelsen. Några av funktionerna i Azure Portal är beroende av direktåtkomst till SCM-webbplatsen. 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 för att få åtkomst till SCM-webbplatsen, som även kallas Kudu-konsolen. Funktioner som använder SCM-webbplatsen är:
- Webbjobb
- Functions
- Loggströmning
- Kudu
- Tillägg
- Processutforskaren
- Konsol
När du använder en ILB ASE är SCM-webbplatsen 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 att använda portalen.
Om din ILB ASE är domännamnet contoso.appserviceenvironment.net appnamnet är testappen, nås appen testapp.contoso.appserviceenvironment.net. Den SCM-webbplats som följer med nås testapp.scm.contoso.appserviceenvironment.net.
ASE IP-adresser
En ASE har några IP-adresser att känna till. De är:
- Offentlig inkommande IP-adress: Används för apptrafik i en extern ASE och hanteringstrafik i både en extern ASE och en ILB ASE.
- Utgående offentlig IP-adress: Används som "från"-IP för utgående anslutningar från DEN ASE som lämnar det virtuella nätverket, som inte dirigeras ned ett VPN.
- ILB IP-adress: ILB IP-adressen finns bara i en ILB ASE.
- App-tilldelade IP-baserade TLS/SSL-adresser: Endast möjligt med en extern ASE och när IP-baserad TLS/SSL-bindning har konfigurerats.
Alla dessa IP-adresser visas i Azure Portal från ASE-användargränssnittet. Om du har en ILB ASE visas IP-adressen för ILB.
Anteckning
Dessa IP-adresser ändras inte så länge din ASE är igång. Om din ASE pausas och återställs ändras de adresser som används av din ASE. Den normala orsaken till att en ASE pausas är om du blockerar inkommande hanteringsåtkomst eller blockerar åtkomst till ett ASE-beroende.

App-tilldelade IP-adresser
Med en extern ASE kan du tilldela IP-adresser till enskilda appar. Du kan inte göra det med en ILB ASE. Mer information om hur du konfigurerar din app så att den har sin 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 ASE två portar för att mappa till den IP-adressen. En port är för HTTP-trafik och den andra porten är för HTTPS. Dessa portar visas i ASE-användargränssnittet i avsnittet IP-adresser. Trafiken måste kunna nå dessa portar från VIP-adressen, 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
Med nätverkssäkerhetsgrupper kan du styra nätverksåtkomsten i ett virtuellt nätverk. När du använder portalen finns det en implicit neka-regel med lägsta möjliga prioritet som nekar allt. Det du skapar är dina egna tillåt-regler.
I en ASE har du inte åtkomst till de virtuella datorer som används som värd för själva ASE:en. De ligger i en prenumeration som Microsoft hanterar. Om du vill begränsa åtkomsten till appar i ASE:n ställer du in NSG:er i ASE-undernätet. Var uppmärksam på ASE-beroendena när du gör det. Om du blockerar eventuella beroenden slutar ASE:n att fungera.
NSG:er kan konfigureras via Azure Portal eller via PowerShell. Informationen här visar Azure Portal. Du skapar och hanterar NSG:er i portalen som en resurs på den översta nivån under Nätverk.
De obligatoriska posterna i en NSG för att en ASE ska fungera ä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 ASE-undernätet till ASE-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 ASE-undernätet på alla portar
Dessa portar inkluderar inte de portar som dina appar kräver för att användningen ska lyckas. Din app kan till exempel behöva 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 Services, kan variera beroende på operativsystemet och finns inte i en väldefinierad lista med adresser. För att förhindra problem med tidssynkronisering måste du tillåta UDP-trafik till alla adresser på port 123. Den utgående TCP-trafiken till port 12000 är till för systemstöd och analys. Slutpunkterna är dynamiska och finns inte i en väldefinierad uppsättning adresser.
De vanliga appåtkomstportarna är:
| Användning | Portar |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Visual Studio fjärrfelsökning | 4020, 4022, 4024 |
| Webbtjänst för distribution av webben | 8172 |
När kraven för inkommande och utgående beaktas bör NSG:erna se ut ungefär som de NSG:er som visas i det här exemplet.

En standardregel gör att IP-adresser i det virtuella nätverket kan prata med ASE-undernätet. En annan standardregel gör att lastbalanseraren, även kallat offentlig VIP, kan kommunicera med ASE. Om du vill se standardreglerna väljer du Standardregler bredvid ikonen Lägg till. Om du nekar allt annat före standardreglerna förhindrar du trafik mellan VIP och ASE. Om du vill förhindra att trafik kommer inifrån det virtuella nätverket lägger du till en egen regel för att tillåta inkommande trafik. Använd en källa som är lika med AzureLoadBalancer med målet Alla och portintervallet * . Eftersom NSG-regeln tillämpas på ASE-undernätet behöver du inte vara specifik i målet.
Om du har tilldelat en IP-adress till din app ska du se till att portarna är öppna. Om du vill se portarna väljer du App Service-miljön > IP-adresser.
Alla objekt som visas i följande regler för utgående trafik behövs, förutom det sista objektet. De ger nätverksåtkomst till DE ASE-beroenden som noterades tidigare i den här artikeln. Om du blockerar någon av dem slutar din ASE att fungera. Det sista objektet i listan gör att DIN ASE kan kommunicera med andra resurser i det virtuella nätverket.

När dina NSG:er har definierats tilldelar du dem till det undernät som ASE är på. Om du inte kommer ihåg det virtuella ASE-nätverket eller undernätet kan du se det från ASE-portalsidan. 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 ditt virtuella nätverk så att den utgående trafiken inte går direkt till Internet utan någon annanstans, till exempel en ExpressRoute-gateway eller en virtuell installation. Om du behöver konfigurera din ASE på ett sådant sätt läser du dokumentet om att konfigurera din App Service-miljö med tvingad tunneltrafik. Det här dokumentet innehåller information om de alternativ som är tillgängliga för arbete med ExpressRoute och tvingad tunneling.
När du skapar en ASE i portalen skapar vi också en uppsättning vägtabeller i undernätet som skapas med ASE. Dessa vägar säger bara att utgående trafik ska skickas direkt till Internet.
Följ dessa steg om du vill skapa samma vägar manuellt:
Gå till Azure-portalen. Välj > Nätverksvägtabeller.
Skapa en ny vägtabell i samma region som det virtuella nätverket.
I användargränssnittet för din vägtabell väljer du Vägar Lägg > till.
Ange Nästa hopptyp till Internet och Adressprefix 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 vägtabellen går du till det undernät som innehåller din ASE. Välj din vägtabell i listan i portalen. När du har sparat ändringen bör du se NSG:er och vägar som anges med undernätet.

Tjänstslutpunkter
Med tjänstens slutpunkter kan du begränsa åtkomsten för tjänster med flera innehavare till en uppsättning virtuella Azure-nätverk och undernät. Du kan läsa mer om tjänstslutpunkter i dokumentationen Tjänstslutpunkter för virtuellt nätverk.
När du aktiverar tjänstens slutpunkter för en resurs, finns det vägar som skapats med högre prioritet än andra vägar. Om du använder tjänstslutpunkter i en Azure-tjänst med en ASE med tvingad tunneltrafik kommer trafiken till de tjänsterna inte att få tvingad tunneltrafik.
När tjänstens slutpunkter är aktiverade på ett undernät med en Azure SQL-instans, måste alla Azure SQL-instanser som är anslutna från undernätet ha aktiverat tjänstens slutpunkter. Om du vill ha åtkomst till flera Azure SQL-instanser från samma undernät kan du inte aktivera tjänstens slutpunkter på en Azure SQL-instans och inte på en annan. Ingen annan Azure-tjänst fungerar som Azure SQL med avseende på tjänstslutpunkter. När du aktiverar tjänstens slutpunkter med Azure Storage kan du låsa åtkomsten till resursen från undernätet, men du kan ändå använda andra Azure Storage-konton även om de inte har aktiverat tjänstens slutpunkter.
