Översikt över nätverksarkitekturen i App Service-miljöer

Viktigt!

Den här artikeln handlar om App Service-miljön v1. App Service-miljön v1 går i pension 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 v1 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 v1-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 skapas alltid i ett undernät i ett virtuellt nätverk – appar som körs i en App Service-miljön kan kommunicera med privata slutpunkter som finns i samma topologi för virtuella nätverk. Eftersom kunder kan låsa delar av sin infrastruktur för virtuella nätverk är det viktigt att förstå vilka typer av nätverkskommunikationsflöden som uppstår med en App Service-miljön.

Allmänt nätverksflöde

När en App Service-miljön (ASE) använder en offentlig virtuell IP-adress (VIP) för appar, kommer all inkommande trafik till den offentliga VIP:en. Detta omfattar HTTP- och HTTPS-trafik för appar och annan trafik för FTP, fjärrfelsökningsfunktioner och Azure-hanteringsåtgärder. En fullständig lista över de specifika portar (både obligatoriska och valfria) som är tillgängliga på den offentliga VIP-adressen finns i artikeln om att styra inkommande trafik till en App Service-miljön.

App Service-miljön har också stöd för att köra appar som endast är bundna till en intern adress för virtuellt nätverk, även kallad en ILB-adress (intern lastbalanserare). På en ILB-aktiverad ASE-, HTTP- och HTTPS-trafik för appar och fjärrfelsökningsanrop anländer du till ILB-adressen. För de vanligaste ILB-ASE-konfigurationerna kommer FTP/FTPS-trafik också att komma till ILB-adressen. Azure-hanteringsåtgärder flödar dock fortfarande till portarna 454/455 på den offentliga VIP-adressen för en ILB-aktiverad ASE.

Diagrammet nedan visar en översikt över de olika inkommande och utgående nätverksflödena för en App Service-miljön där apparna är bundna till en offentlig virtuell IP-adress:

En App Service-miljön kan kommunicera med privata kundslutpunkter. Appar som körs i App Service-miljön kan till exempel ansluta till databasservrar som körs på virtuella IaaS-datorer i samma topologi för virtuella nätverk.

Viktigt!

Om du tittar på nätverksdiagrammet distribueras "Andra beräkningsresurser" i ett annat undernät än App Service-miljön. Om du distribuerar resurser i samma undernät med ASE blockeras anslutningen från ASE till dessa resurser (förutom för specifik intra-ASE-routning). Distribuera till ett annat undernät i stället (i samma VNET). App Service-miljön kan sedan ansluta. Ingen ytterligare konfiguration krävs.

App Service-miljön kommunicerar också med Sql DB- och Azure Storage-resurser som krävs för att hantera och driva en App Service-miljön. Vissa sql- och lagringsresurser som en App Service-miljön kommunicerar med finns i samma region som App Service-miljön, medan andra finns i fjärranslutna Azure-regioner. Därför krävs alltid utgående anslutning till Internet för att en App Service-miljön ska fungera korrekt.

Eftersom en App Service-miljön distribueras i ett undernät kan nätverkssäkerhetsgrupper användas för att styra inkommande trafik till undernätet. Mer information om hur du styr inkommande trafik till en App Service-miljön finns i följande artikel.

Mer information om hur du tillåter utgående Internetanslutning från en App Service-miljön finns i följande artikel om att arbeta med Express Route. Samma metod som beskrivs i artikeln gäller när du arbetar med plats-till-plats-anslutning och använder tvingad tunneltrafik.

Utgående nätverksadresser

När en App Service-miljön gör utgående anrop associeras alltid en IP-adress med de utgående anropen. Den specifika IP-adress som används beror på om slutpunkten som anropas finns i topologin för det virtuella nätverket eller utanför topologin för det virtuella nätverket.

Om slutpunkten som anropas ligger utanför topologin för det virtuella nätverket är den utgående adressen (även kallad den utgående NAT-adressen) som används den offentliga VIP-adressen för App Service-miljön. Den här adressen finns i portalens användargränssnitt för App Service-miljön i avsnittet Egenskaper.

Den här adressen kan också fastställas för ASE:er som bara har en offentlig VIP genom att skapa en app i App Service-miljön och sedan utföra en nslookup på appens adress. Den resulterande IP-adressen är både offentlig VIP och App Service-miljön utgående NAT-adress.

Om slutpunkten som anropas finns i topologin för det virtuella nätverket är den utgående adressen för den anropande appen den interna IP-adressen för den enskilda beräkningsresurs som kör appen. Det finns dock ingen beständig mappning av interna IP-adresser för virtuella nätverk till appar. Appar kan flyttas mellan olika beräkningsresurser och poolen med tillgängliga beräkningsresurser i en App Service-miljön kan ändras på grund av skalningsåtgärder.

Men eftersom en App Service-miljön alltid finns i ett undernät är du garanterad att den interna IP-adressen för en beräkningsresurs som kör en app alltid ligger inom CIDR-intervallet för undernätet. När detaljerade ACL:er eller nätverkssäkerhetsgrupper används för att skydda åtkomsten till andra slutpunkter i det virtuella nätverket måste därför undernätsintervallet som innehåller App Service-miljön beviljas åtkomst.

Följande diagram visar dessa begrepp mer detaljerat:

I diagrammet ovan:

• Eftersom den offentliga VIP-adressen för App Service-miljön är 192.23.1.2 är det den utgående IP-adressen som används vid anrop till "Internet"-slutpunkter.
• CIDR-intervallet för det innehållande undernätet för App Service-miljön är 10.0.1.0/26. Andra slutpunkter i samma infrastruktur för virtuella nätverk ser anrop från appar som från någonstans inom det här adressintervallet.

Samtal mellan App Service-miljön

Ett mer komplext scenario kan inträffa om du distribuerar flera App Service-miljön i samma virtuella nätverk och gör utgående anrop från en App Service-miljön till en annan App Service-miljön. Dessa typer av anrop mellan App Service-miljön behandlas också som "Internet"-anrop.

Följande diagram visar ett exempel på en arkitektur i flera lager med appar på en App Service-miljön (till exempel "Front door"-webbappar) som anropar appar på en andra App Service-miljön (till exempel interna API-appar för serverdelen som inte är avsedda att vara tillgängliga från Internet).

I exemplet ovan har App Service-miljön "ASE One" en utgående IP-adress på 192.23.1.2. Om en app som körs på den här App Service-miljön gör ett utgående anrop till en app som körs på en andra App Service-miljön ("ASE Two") som finns i samma virtuella nätverk, behandlas det utgående anropet som ett "Internet"-anrop. Därför visas den nätverkstrafik som anländer på den andra App Service-miljön från 192.23.1.2 (dvs. inte undernätets adressintervall för den första App Service-miljön).

Även om anrop mellan olika App Service-miljön behandlas som "Internet"-anrop, kommer nätverkstrafiken att finnas kvar i det regionala Azure-nätverket och inte fysiskt flöda över det offentliga Internet när båda App Service-miljön finns i samma Azure-region. Därför kan du använda en nätverkssäkerhetsgrupp i undernätet för den andra App Service-miljön för att endast tillåta inkommande anrop från den första App Service-miljön (vars utgående IP-adress är 192.23.1.2), vilket säkerställer säker kommunikation mellan App Service-miljön.

Ytterligare länkar och information

Information om inkommande portar som används av App Service-miljön och hur du använder nätverkssäkerhetsgrupper för att styra inkommande trafik finns här.

Information om hur du använder användardefinierade vägar för att bevilja utgående Internetåtkomst till App Service-miljön finns i den här artikeln.