Hoe een Azure Web App lokaal bereikt via een VPN

Het uitgaande verzoek van de webapp laat een medewerker achter die je nooit ziet, van een bron die je niet hebt gekozen, en de firewall op kantoor moet dit accepteren. Dat is het hele probleem in één zin. Regionale VNet-integratie geeft de aanvraag een pad naar een virtueel netwerk, en de site-naar-site VPN draagt de aanvraag vanaf daar over. Alles wat daarna misgaat, gaat over welk bronbereik en welke route het pakket daadwerkelijk heeft gebruikt.

Wat de medewerker daadwerkelijk verzendt

App Service voert uw code uit op werknemers die zich buiten de netwerkweergave van uw abonnement bevinden. Als regionale integratie is ingeschakeld, wordt uitgaand verkeer overgedragen aan een gedelegeerd subnet in een VNet in dezelfde regio, en wordt het pakket daar weergegeven voordat het verdergaat. Door de integratie wordt de app niet naar het VNet verplaatst en wordt het inkomende adres niet gewijzigd. Het geeft alleen uitgaande stromen een andere eerste hop.

Standaard volgt alleen privé-adresruimte dat pad, dus gewone internetbestemmingen vertrekken nog steeds rechtstreeks vanaf de medewerker. Alles via het VNet routeren is een aparte instelling en een aparte beslissing, omdat het ook je publieke afhankelijkheden door de tunnel stuurt.

Configuratieverkeer, zoals het ophalen van een containerimage bij het opstarten, volgt zijn eigen routeringsregels en kan mislukken terwijl uw API-aanroepen slagen.

Het integratiesubnet is de bron die u moet toestaan

Het kantoor ziet het adresbereik van het integratiesubnet, of hoe uw apparaat dit ook vertaalt, en niet de openbare uitgaande adressen van de app. Plaats dat bereik in de verkeerskiezers van de VPN-site en in de lokale firewallregel. Als de tunnel op beleid is gebaseerd, laten selectors die deze weglaten het pakket achterwege, zelfs als er een route bestaat.

Laat geen enkel werknemersadres toe dat u toevallig heeft waargenomen. Instanties veranderen met schaalvergroting en platformonderhoud, en een regel die aan één adres is vastgemaakt, gaat op het slechtste moment kapot.

Houd de bestemmingszijde smal: één dienst, één haven, één richting, waarbij het retourpad expliciet is toegestaan.

Peering en gateway-transit zijn expliciet

Als de VPN-gateway zich in een hub-VNet bevindt en het integratiesubnet in een spaak, heeft het pad gateway-doorvoer nodig dat is toegestaan op de hub-peering en moet het gebruik van externe gateways zijn ingeschakeld op de spaak-peering. Peering op zichzelf vervoert verkeer tussen de twee VNets en niets meer. De effectieve routes op het integratie-subnet zijn waar u bevestigt dat de volgende hop-gateway er echt is.

Een hub-and-spoke-ontwerp waarvan de routetabel 0.0.0.0/0 naar een firewall stuurt, is een veel voorkomende variant, en die firewall heeft dan zijn eigen regel nodig voor het lokale voorvoegsel.

Teken het pad op papier voordat u een ticket opent bij het netwerkteam, want dat scheelt een dag gokken. Neem de retourrichting op in de tekening, aangezien dit de helft is die mensen vergeten.

Binnenkomend privé-eindpunt is de andere richting

Een privéeindpunt maakt de app bereikbaar vanuit een VNet. Het doet niets voor de uitgaande oproep van de app naar kantoor, en teams configureren er regelmatig een, terwijl de werkelijke vereiste omgekeerd was.

Oudere documentatie beschrijft de gateway-vereiste integratie gebouwd op punt-naar-site-VPN, een andere functie met zijn eigen vereisten. Microsoft plant de stopzetting van deze functie op 31 maart 2027 en raadt in plaats daarvan regionale integratie aan.

Kopieer geen verouderde punt-naar-site-configuratie alleen maar omdat een oud voorbeeld deze gebruikte.

Verifieer met de eigen context van de app

Test vanuit de geïmplementeerde app, niet vanaf uw laptop en niet vanaf een VM in hetzelfde VNet. Registreer het opgeloste adres, het verbindingsresultaat en de respons op applicatieniveau afzonderlijk, omdat een DNS-fout, een TCP-time-out en een authenticatie-afwijzing bij drie verschillende eigenaren voorkomen. Als de naamomzetting mislukt, herstelt u de privé-DNS voor het VNet voordat u de tunnel aanraakt.

Een groene tunnelstatus bewijst alleen dat de gateway actief is. Er staat niets over selectors, firewallregels of DNS.

Wanneer de aanvraag eindelijk werkt, schrijft u het bronbereik, de doelpoort en de DNS-zone naar het runbook van de app. De volgende persoon die dit zal opsporen, zal starten vanaf uw notitie in plaats van vanaf de statuspagina van de gateway.