Hvordan en Azure Web App når lokalt via en VPN

Webappens udgående anmodning efterlader en arbejder, du aldrig ser, fra en kilde, du ikke har valgt, og kontorets firewall skal acceptere den. Det er hele problemet i én sætning. Regional VNet-integration giver anmodningen en sti til et virtuelt netværk, og site-to-site VPN fører den derfra. Alt, hvad der går galt bagefter, handler om hvilket kildeområde og hvilken rute pakken faktisk brugte.

Hvad arbejderen faktisk sender

App Service kører din kode på arbejdere, der sidder uden for dit abonnements netværksvisning. Med regional integration aktiveret, videregives udgående trafik til et delegeret undernet i et VNet i samme region, og pakken vises der, før den fortsætter. Integrationen flytter ikke appen ind i VNet og ændrer ikke dens indgående adresse. Det giver kun udgående flows et andet første hop.

Som standard tager kun privat adresserum den vej, så almindelige internetdestinationer forlader stadig direkte fra arbejderen. At dirigere alt gennem VNet er en separat indstilling og en separat beslutning, fordi det også sender dine offentlige afhængigheder hen over tunnelen.

Konfigurationstrafik, såsom et containerbillede ved opstart, følger sine egne routingregler og kan mislykkes, mens dine API-kald lykkes.

Integrationsundernettet er den kilde, du skal tillade

Kontoret ser integrationsundernettets adresseinterval, eller hvad din enhed nu oversætter det til, ikke appens offentlige udgående adresser. Indsæt dette interval i webstedets VPN's trafikvælgere og i den lokale firewall-regel. Hvis tunnelen er politikbaseret, dropper vælgere, der udelader den, pakken, selv når der findes en rute.

Tillad ikke en enkelt arbejderadresse, du tilfældigvis har observeret. Forekomster ændrer sig med skalering og platformsvedligeholdelse, og en regel, der er fastgjort til én adresse, går i stykker i det værste øjeblik.

Hold destinationssiden smal: én tjeneste, én havn, én retning, med eksplicit tilladt retursti.

Peering og gateway-transit er eksplicit

Hvis VPN-gatewayen sidder i et hub-VNet og integrationsundernettet i en eger, skal stien have gatewaytransit tilladt på hub-peering og ekstern gateway-brug aktiveret på eger-peering. Peering af sig selv fører trafik mellem de to VNets og intet mere. De effektive ruter på integrationsundernettet er, hvor du bekræfter, at gatewayen næste hop virkelig er der.

Et hub-and-spoke-design, hvis rutetabel sender 0.0.0.0/0 til en firewall, er en almindelig variant, og den firewall har så brug for sin egen regel for det lokale præfiks.

Tegn stien på papir, før du åbner en billet med netværksteamet, for det sparer en dag med gætteri. Inkluder returretningen i tegningen, da det er den halvdel, folk glemmer.

Indgående privat slutpunkt er den anden retning

Et privat slutpunkt gør appen tilgængelig fra et VNet. Det gør intet for appens udgående opkald til kontoret, og teams konfigurerer regelmæssigt et, mens det faktiske krav var det omvendte.

Ældre dokumentation beskriver gateway-påkrævet integration bygget på point-to-site VPN, en anden funktion med sine egne krav. Microsoft planlægger, at denne funktion trækkes tilbage til den 31. marts 2027 og anbefaler regional integration i stedet.

Kopiér ikke en ældre punkt-til-sted-konfiguration, bare fordi et gammelt eksempel brugte den.

Bekræft med appens egen kontekst

Test fra den installerede app, ikke fra din bærbare computer og ikke fra en VM i det samme VNet. Log den løste adresse, forbindelsesresultatet og applikationsniveausvaret separat, fordi en DNS-fejl, en TCP-timeout og et godkendelsesafvisningspunkt hos tre forskellige ejere. Hvis navneopløsningen mislykkes, skal du rette privat DNS til VNet, før du rører ved tunnelen.

En grøn tunnelstatus beviser kun, at gatewayen er oppe. Der står intet om vælgere, firewall-regler eller DNS.

Når anmodningen endelig virker, skal du skrive kildeområdet, destinationsporten og DNS-zonen i appens runbook. Den næste person, der fejlretter dette, starter fra din note i stedet for fra gatewayens statusside.