Konfigurera App Service-miljö med tvingande dirigering

Artikel
10/17/2024

Viktigt!

Den här artikeln handlar om App Service-miljön v2, som används med isolerade App Service-planer. App Service-miljön v1 och v2 dras tillbaka från och med 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 31 augusti 2024 gäller serviceavtal (SLA) och tjänstkrediter inte längre för App Service-miljön v1- och v2-arbetsbelastningar som fortsätter att vara i produktion eftersom de är tillbakadragna produkter. Avvecklingen av maskinvaran App Service-miljön v1 och v2 har påbörjats, vilket kan påverka tillgängligheten och prestandan för dina appar och data.

Du måste slutföra migreringen till App Service-miljön v3 omedelbart eller så kan dina appar och resurser tas bort. Vi försöker automatiskt migrera eventuella återstående App Service-miljön v1 och v2 på bästa sätt med hjälp av migreringsfunktionen på plats, men Microsoft gör inga anspråk eller garantier om programtillgänglighet efter automatisk migrering. Du kan behöva utföra manuell konfiguration för att slutföra migreringen och optimera ditt SKU-val för App Service-plan för att uppfylla dina behov. Om automatisk migrering inte är möjlig tas dina resurser och associerade appdata bort. Vi uppmanar dig starkt att agera nu för att undvika något av dessa extrema scenarier.

Om du behöver ytterligare tid kan vi erbjuda en respitperiod på 30 dagar för att slutföra migreringen. Mer information och för att begära den här respitperioden finns i översikten över respitperioden och gå sedan till Azure Portal och gå till migreringsbladet för var och en av dina App Service-miljön.

Den senaste informationen om App Service-miljön v1/v2-tillbakadragning finns i App Service-miljön v1- och v2-pensionsuppdateringen.

Azure App Service Environment (ASE) är en distribution av Azure App Service i en kunds virtuella Azure-nätverk. Många kunder konfigurerar sina virtuella Azure-nätverk så att de blir förlängningar av de lokala nätverken med VPN eller Azure ExpressRoute-anslutningar. Tvingad tunneltrafik är när du omdirigerar Internet-bunden trafik till ditt VPN eller en virtuell installation i stället. Virtuella installationer används ofta vid inspektion och granskning av utgående nätverkstrafik.

ASE har ett antal externa beroenden som beskrivs i dokumentet Nätverksarkitektur i App Service Environment. Normalt måste all utgående ASE-beroende trafik gå igenom den VIP som har etablerats med ASE:n. Om du ändrar routningen för trafik till eller från ASE:n utan att följa informationen nedan, kommer din ASE att sluta fungera.

I ett virtuellt Azure-nätverk sker routning baserat på den längsta prefix-matchningen (LPM). Om det finns fler än en väg med samma LPM-matchning väljs en väg baserat på dess ursprung i följande ordning:

Användardefinierad väg (UDR)
BGP-väg (när ExpressRoute används)
Systemväg

Mer information om routning i ett virtuellt nätverk finns i Användardefinierade vägar och IP-vidarebefordring.

Om du vill dirigera din utgående ASE-trafik någon annanstans än direkt till Internet, kan du välja mellan följande:

Aktivera din ASE till direkt Internet-åtkomst
Konfigurera ditt ASE-undernät så att BGP-vägar ignoreras
Konfigurera att ditt ASE-undernät använder tjänstens slutpunkter till Azure SQL och Azure Storage
Lägg till egna IP-adresser i ASE Azure SQL-brandväggen

Aktivera App Service Environment-miljön så att den har direktåtkomst till internet

Om du vill aktivera att din ASE går direkt till Internet, även om ditt virtuella Azure-nätverket har konfigurerats med ExpressRoute, kan du:

Konfigurera ExpressRoute att annonsera 0.0.0.0/0. Som standard dirigeras all utgående trafik lokalt.
Skapa en UDR med adressprefixet 0.0.0.0/0, samt en nexthop-typ för Internet och tillämpa det på ASE-undernätet.

Om du gör dessa två ändringar kommer trafik med Internet som mål som kommer från undernätet i App Service Environment inte tvingas till ExpressRoute-anslutningen.

Om nätverket redan dirigerar trafik lokalt måste du skapa det undernät som ska vara värd för ASE och konfigurera UDR för det innan du distribuerar ASE.

Viktigt!

Vägarna som definieras i en UDR måste vara tillräckligt specifika för att få företräde framför eventuella vägar som annonseras av ExpressRoute-konfigurationen. Föregående exempel använder det breda adressintervallet 0.0.0.0/0. Det kan eventuellt åsidosättas av misstag av vägannonseringar som använder mer specifika adressintervall.

App Service Environment-miljöer stöds inte med ExpressRoute-konfigurationer som korsannonserar vägar från den offentliga peering-vägen till den privata peering-vägen. ExpressRoute-konfigurationer med offentlig peering har konfigurerats för att få vägannonseringar från Microsoft. Reklamen innehåller ett stort antal adressintervall för Microsoft Azure. Om adressintervallen korsannonseras på den privata peering-vägen kommer alla utgående nätverkspaket från undernätet för App Service Environment att dirigeras till en kunds lokala nätverksinfrastruktur. Det här nätverksflödet stöds inte som standard i App Service Environment. En lösning på detta problem är att stoppa korsannonsering av vägar från den offentliga peering-vägen till den privata peering-vägen. En annan lösning är att göra det möjligt för App Service Environment att arbeta i en konfiguration med tvingande dirigering.

Direkt Internet-åtkomst

Konfigurera ditt ASE-undernät så att BGP-vägar ignoreras

Du kan konfigurera ditt ASE-undernät så att alla BGP-vägar ignoreras. När ASE har konfigurerats att ignorera BGP-vägar kan det komma åt sina beroenden utan problem. Du måste dock skapa UDR:er så att apparna kan komma åt lokala resurser.

Så här konfigurerar du ditt ASE-undernät så att BGP-vägar ignoreras:

Skapa en UDR och tilldela den till ditt ASE-undernät om du inte redan har en.
Öppna Azure Portal och öppna gränssnittet för routningstabellen som tilldelats till ASE-undernätet. Välj Konfiguration. Ange Routningsspridning för virtuell nätverksgateway till Inaktiverad. Klicka på Spara. Inaktiveringen är dokumenterad i dokumentet Skapa en routningstabell.

När du har konfigurerat ASE-undernätet att ignorera alla BGP-vägar kan dina appar inte längre nå resurser lokalt. Om du vill göra så att apparna kan komma åt resurser lokalt redigerar du UDR som tilldelats till ASE-underlätet och lägger till vägar för dina lokala adressintervall. Nästa hopptyp bör ställas in som Virtuell nätverksgateway.

Konfigurera din ASE med tjänstens slutpunkter

Utför följande steg för att dirigera all utgående trafik från din ASE, förutom den som går till Azure SQL och Azure Storage:

Skapa en routningstabell och tilldela den till ditt ASE-undernät. Hitta adresserna som matchar din region här Hanteringsadresser för App Service Environment. Skapa vägar för dessa adresser eller använd taggen AppServiceManagement-tjänst med nästa hopp på Internet. De här vägarna behövs eftersom App Service Environments inkommande hanteringstrafik måste svara från samma adress som den skickades till.
Aktivera tjänstslutpunkter med Azure SQL och Azure Storage med ASE-undernätet. När det här steget har slutförts kan du konfigurera ditt virtuella nätverk med tvingad tunneltrafik.

Mer information om hur du distribuerar ASE med en mall finns i Skapa en App Service-miljö med hjälp av en mall.

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änstens slutpunkter med tvingad tunneltrafik för ASE, kommer hanteringstrafiken för Azure SQL och Azure Storage inte omfattas av den tvingade tunneltrafiken. Annan ASE-beroende trafik blir tvingad tunneltrafik och kan antingen förloras, eller så fungerar inte ASE ordentligt.

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. Azure Storage fungerar inte på samma sätt som Azure SQL. 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.

Om du konfigurerar tvingad tunneltrafik med en nätverksfilterinstallation måste du komma ihåg att ASE har ytterligare beroenden utöver Azure SQL och Azure Storage. Om trafik till dessa beroenden blockeras fungerar inte ASE korrekt.

Tvingad tunneltrafik med tjänstens slutpunkter

Lägg till egna IP-adresser i ASE Azure SQL-brandväggen

Utför följande steg för att tunnla all utgående trafik från din ASE, förutom den som går till Azure SQL och Azure Storage:

Skapa en routningstabell och tilldela den till ditt ASE-undernät. Hitta adresserna som matchar din region här Hanteringsadresser för App Service Environment. Skapa vägar för dessa adresser med ett nexthop för Internet. De här vägarna behövs eftersom App Service Environments inkommande hanteringstrafik måste svara från samma adress som den skickades till.
Aktivera tjänstens slutpunkter för Azure Storage med ditt ASE-undernät
Hämta de adresser som ska användas för all utgående trafik från din App Service Environment till Internet. Om du dirigerar trafiken lokalt är dessa adresser dina NAT- eller gateway-IP-adresser. Om du vill dirigera den utgående trafiken för App Service Environment genom en NVA är den utgående adressen den offentliga IP-adressen för NVA.
Ange utgående adresser i en befintlig App Service-miljön: Gå till resources.azure.com och gå till Prenumeration/<prenumerations-ID>/resourceGroups/<ase resursgrupp>/providers/Microsoft.Web/hostingEnvironments/<ase name>. Du kan då se den JSON som beskriver App Service Environment. Kontrollera att det står läsa/skriva längst upp. Välj Redigera. Gå längst ned på sidan. Ändra värdet i userWhitelistedIpRanges från null till något som liknar följande. Använd de adresser som du vill ange som utgående adressintervall.
```
"userWhitelistedIpRanges": ["11.22.33.44/32", "55.66.77.0/24"]
```
Välj PUT längst upp. Det här alternativet utlöser en skalningsåtgärd i App Service Environment och justerar brandväggen.

Skapa din ASE med utgående adresser: Följ instruktionerna i Skapa en App Service Environment med en mall och hämta lämplig mall. Redigera avsnittet ”resurser” i filen azuredeploy.json, men inte i blocket ”egenskaper”, och inkludera en rad för userWhitelistedIpRanges med dina värden.

"resources": [
    {
        "apiVersion": "2015-08-01",
        "type": "Microsoft.Web/hostingEnvironments",
        "name": "[parameters('aseName')]",
        "kind": "ASEV2",
        "location": "[parameters('aseLocation')]",
        "properties": {
            "name": "[parameters('aseName')]",
            "location": "[parameters('aseLocation')]",
            "ipSslAddressCount": 0,
            "internalLoadBalancingMode": "[parameters('internalLoadBalancingMode')]",
            "dnsSuffix" : "[parameters('dnsSuffix')]",
            "virtualNetwork": {
                "Id": "[parameters('existingVnetResourceId')]",
                "Subnet": "[parameters('subnetName')]"
            },
            "userWhitelistedIpRanges":  ["11.22.33.44/32", "55.66.77.0/30"]
        }
    }
]

Dessa ändringar skickar trafik till Azure Storage direkt från ASE:n och tillåter åtkomst till Azure SQL från fler adresser än VIP för ASE.

Tvingad tunnel med SQL allowlist

Förhindra problem

Om kommunikationen mellan ASE och dess beroenden är bruten, hamnar ASE:n i ett feltillstånd. Om felet fortgår för länge inaktiveras ASE:n. Om du vill aktivera ASE:n igen följer du instruktionerna i ASE-portalen.

Förutom att bryta kommunikationen kan du försämra din ASE genom att ha för lång svarstid. För lång svarstid kan uppstå om din ASE är för långt ifrån ditt lokala nätverk. Avståndet är till exempel för långt om kommunikationen måste gå över ett hav eller en kontinent för att nå det lokala nätverket. Svarstid kan också påverkas vid överbelastning av intranätet eller utgående bandbreddsbegränsningar.

Dela via