Korleis ein Azure-webapp når lokale nettverk gjennom ein VPN

Nettappens utgåendei forespørsel etterlater en arbeider du aldri ser, frå en kildei du ikkje har valgt, og kontorets brannmur må godta det. Det er hele problemet i en setning. Regional VNet-integrasjon gjev 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ådei og hvilken rute pakken faktisk brukte.

Hva arbeideren faktisk sender

App Service kjører koden din på arbeidere som sit utenfor abonnementets nettverksvisning. Med regional integrasjon aktivert, overføres utgåendei trafikk til et delegert subnett i et VNet i samme region, og pakken vises der før den fortsetter. Integrasjonen flyttar ikkje appen inn i VNet og endrar ikkje inngåendei adresse. Det gjev berre utgåendei flyter et anna første hopp.

Som standard tek berre privat adresserom den banen, så vanlege internettdestinasjoner går fortsett direkte frå arbeideren. Ruting av alt gjennom VNet er en egen innstilling og en separat beslutning, fordi det òg sendar 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 kva enheten din overset det til, ikkje appens offentlige utgåendei 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 arbeideradressjå du tilfeldigvis observerte. Forekomster endres med skalering og plattformvedlikehold, og en regel festet til én adressjå brytes i verste øyeblikk.

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

Peering og gateway-transport er eksplisitte

Hvis VPN-gatewayen sit 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 dei 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 viss rutetabell sendar 0.0.0.0/0 til en brannmur er en vanleg variant, og den brannmuren trenge da sin egen regel for prefikset på stedet.

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

Innkommendei privat endepunkt er den andre retningen

Et privat endepunkt gjer appen tilgjengelig frå innsidan av et VNet. Det gjer ingenting for appens utgåendei anrop til kontoret, og teamene konfigurerer regelmessig en mens det faktiske kravet var omvendt.

Eldre dokumentasjon skildrar gateway-påkrevd integrasjon bygget på punkt-til-sted VPN, en annan 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 berre fordi et gammelt eksempel brukte den.

Bekreft med appens egen kontekst

Test frå den distribuerte appen, ikkje frå den bærberre datamaskinen og ikkje frå 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 berre 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 frå notatet ditt i stedet for frå gatewayens statusside.