Hur en Azure Web App når lokalt via ett VPN

Webbappens utgående begäran lämnar en arbetare som du aldrig ser, från en källa som du inte har valt, och kontorets brandvägg måste acceptera den. Det är hela problemet i en mening. Regional VNet-integration ger begäran en väg till ett virtuellt nätverk, och plats-till-plats-VPN tar den därifrån. Allt som blir fel efteråt handlar om vilket källområde och vilken rutt paketet faktiskt använde.

Vad arbetaren faktiskt skickar

App Service kör din kod på arbetare som sitter utanför ditt abonnemangs nätverksvy. Med regional integration aktiverad, skickas utgående trafik till ett delegerat subnät i ett VNet i samma region, och paketet visas där innan det fortsätter. Integrationen flyttar inte appen till VNet och ändrar inte dess inkommande adress. Det ger bara utgående flöden ett annat första hopp.

Som standard tar endast privat adressutrymme den vägen, så vanliga internetdestinationer lämnar fortfarande direkt från arbetaren. Att dirigera allt genom VNet är en separat inställning och ett separat beslut, eftersom det också skickar dina offentliga beroenden över tunneln.

Konfigurationstrafik, till exempel en containerbilddragning vid start, följer sina egna routningsregler och kan misslyckas medan dina API-anrop lyckas.

Integrationsundernätet är källan du måste tillåta

Kontoret ser integreringsundernätets adressintervall, eller vad din enhet nu översätter det till, inte appens offentliga utgående adresser. Lägg det intervallet i webbplatsens VPN:s trafikväljare och i den lokala brandväggsregeln. Om tunneln är policybaserad släpper väljare som utelämnar den paketet även när det finns en rutt.

Tillåt inte en enda arbetaradress som du råkade observera. Förekomster förändras med skalning och plattformsunderhåll, och en regel som är fäst vid en adress avbryts i värsta ögonblicket.

Håll destinationssidan smal: en tjänst, en hamn, en riktning, med returvägen uttryckligen tillåten.

Peering och gatewaytransit är explicit

Om VPN-gatewayen sitter i ett nav-VNet och integreringsundernätet i en eker, behöver sökvägen gatewaytransitering tillåten på hubbpeering och fjärr-gateway-användning aktiverad på ekerpeering. Peering av sig själv bär trafik mellan de två VNet och inget mer. De effektiva rutterna på integreringsundernätet är där du bekräftar att gatewayen nästa hopp verkligen finns där.

En hub-and-spoke-design vars rutttabell skickar 0.0.0.0/0 till en brandvägg är en vanlig variant, och den brandväggen behöver då en egen regel för prefixet på plats.

Rita vägen på papper innan du öppnar en biljett med nätverksteamet, eftersom det sparar en dags gissning. Inkludera returriktningen i ritningen, eftersom det är hälften som människor glömmer.

Inkommande privat slutpunkt är den andra riktningen

En privat slutpunkt gör att appen kan nås inifrån ett VNet. Det gör ingenting för appens utgående samtal till kontoret, och team konfigurerar regelbundet ett medan det faktiska kravet var det omvända.

Äldre dokumentation beskriver gateway-krävd integration byggd på point-to-site VPN, en annan funktion med sina egna krav. Microsoft schemalägger att funktionen går i pension den 31 mars 2027 och rekommenderar regional integration istället.

Kopiera inte en äldre punkt-till-plats-konfiguration bara för att ett gammalt exempel använde den.

Verifiera med appens eget sammanhang

Testa från den distribuerade appen, inte från din bärbara dator och inte från en virtuell dator i samma VNet. Logga den lösta adressen, anslutningsresultatet och applikationsnivåsvaret separat, eftersom ett DNS-fel, en TCP-timeout och en autentiseringsavvisningspunkt hos tre olika ägare. Om namnupplösning misslyckas, fixa privat DNS för VNet innan du rör vid tunneln.

En grön tunnelstatus bevisar bara att gatewayen är uppe. Det står ingenting om väljare, brandväggsregler eller DNS.

När begäran äntligen fungerar, skriv källintervallet, destinationsporten och DNS-zonen i appens runbook. Nästa person som felsöker detta börjar från din anteckning istället för från gatewayens statussida.