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

Nettappens utgående forespørsel etterlater en arbeider du aldri ser, fra en kilde du ikke har valgt, og kontorets brannmur må godta det. Det er hele problemet i en setning. Regional VNet-integrasjon gir forespørselen en vei inn i et virtuelt nettverk, og sted-til-sted-VPN fører den derfra. Alt som går galt i etterkant handler om hvilket kildeområde og hvilken rute pakken faktisk brukte.

Hva arbeideren faktisk sender

App Service kjører koden din på arbeidere som sitter utenfor abonnementets nettverksvisning. Med regional integrasjon aktivert, overføres utgående trafikk til et delegert subnett i et VNet i samme region, og pakken vises der før den fortsetter. Integrasjonen flytter ikke appen inn i VNet og endrer ikke inngående adresse. Det gir bare utgående flyter et annet første hopp.

Som standard tar bare privat adresserom den banen, så vanlige internettdestinasjoner går fortsatt direkte fra arbeideren. Ruting av alt gjennom VNet er en egen innstilling og en separat beslutning, fordi det også sender dine offentlige avhengigheter over tunnelen.

Konfigurasjonstrafikk, for eksempel en beholderbildetrekk ved oppstart, følger sine egne rutingsregler og kan mislykkes mens API-kallene dine lykkes.

Integrasjonsdelnettet er kilden du må tillate

Kontoret ser adresseområdet til integreringsundernettet, eller hva enheten din oversetter det til, ikke appens offentlige utgående adresser. Sett dette området inn i nettstedets VPN-trafikkvelgere og inn i brannmurregelen på stedet. Hvis tunnelen er policybasert, slipper velgere som utelater den pakken selv når det finnes en rute.

Ikke tillat at en enkelt arbeideradresse du tilfeldigvis observerte. Forekomster endres med skalering og plattformvedlikehold, og en regel festet til én adresse brytes i verste øyeblikk.

Hold destinasjonssiden smal: én tjeneste, én port, én retning, med eksplisitt tillatt returvei.

Peering og gateway-transport er eksplisitte

Hvis VPN-gatewayen sitter i et hub-VNet og integreringsdelnettet i en eiker, må banen tillatt gatewayoverføring på hubbpeering og ekstern gatewaybruk aktivert på eikerpeering. Peering av seg selv fører trafikk mellom de to VNets og ingenting mer. De effektive rutene på integrasjonsundernettet er der du bekrefter at gatewayen neste hopp virkelig er der.

En hub-and-spoke-design hvis rutetabell sender 0.0.0.0/0 til en brannmur er en vanlig variant, og den brannmuren trenger da sin egen regel for prefikset på stedet.

Tegn banen på papir før du åpner en billett med nettverksteamet, fordi det sparer en dag med gjetting. Inkluder returretningen i tegningen, siden det er halvparten folk glemmer.

Innkommende privat endepunkt er den andre retningen

Et privat endepunkt gjør appen tilgjengelig fra innsiden av et VNet. Det gjør ingenting for appens utgående anrop til kontoret, og teamene konfigurerer regelmessig en mens det faktiske kravet var omvendt.

Eldre dokumentasjon beskriver gateway-påkrevd integrasjon bygget på punkt-til-sted VPN, en annen funksjon med egne krav. Microsoft planlegger at funksjonen skal pensjoneres til 31. mars 2027, og anbefaler regional integrasjon i stedet.

Ikke kopier en eldre punkt-til-sted-konfigurasjon bare fordi et gammelt eksempel brukte den.

Bekreft med appens egen kontekst

Test fra den distribuerte appen, ikke fra den bærbare datamaskinen og ikke fra en VM i samme VNet. Logg den løste adressen, tilkoblingsresultatet og responsen på applikasjonsnivå separat, fordi en DNS-feil, et TCP-tidsavbrudd og et autentiseringsavvisningspunkt hos tre forskjellige eiere. Hvis navneløsningen mislykkes, fikser du privat DNS for VNet før du berører tunnelen.

En grønn tunnelstatus beviser bare at gatewayen er oppe. Det står ingenting om velgere, brannmurregler eller DNS.

Når forespørselen endelig fungerer, skriv kildeområdet, destinasjonsporten og DNS-sonen inn i appens runbook. Den neste personen som feilsøker dette vil starte fra notatet ditt i stedet for fra gatewayens statusside.