Kvifor Azure Point-to-Site VPN ikkje endrar den offentlege IP-en din

Eg koplar til Azure VPN-klienten på ein Windows-berbar, opnar ei adresse-ekko-side og ser den same offentlege adressa som heimerutaren min delte ut. I mellomtida svarar jumpboksen på 10.20.0.4, og eit privat endepunktnamn blir løyst opp, så tunnelen er ikkje øydelagd. Ein point-to-site-gateway gjer nøyaktig det standardkonfigurasjonen seier: han fraktar dei private prefiksa og lèt alt anna bli verande på den lokale lenkja. Å få ei Azure-eigd utgangsadresse er ei endring av rutingsdesignet, ikkje ein reparasjon.

Kva gatewayen annonserer som standard

Gatewayen skyt ruter for adresserommet til det virtuelle nettverket, i tillegg til peer-nettverk der gateway-transitt er tillaten og lokale prefiks lærde over ei site-to-site-forbinding eller BGP. Det er ingen 0.0.0.0/0 i det settet. Operativsystemet ditt held standardruta på Wi-Fi eller Ethernet, så ein pakke til ein offentleg API kjem aldri inn i tunnelen.

Adressa ein klient får inne i tunnelen, er ein privat leige frå point-to-site-poolen. Ho identifiserer klienten overfor ressursar i VNet; ho er ikkje ei adresse internett kan sjå, og ho vil aldri dukke opp som kjelda til ein utgåande førespurnad til ein SaaS-API. Ein allowlist-oppføring bygd rundt den leiga kan ikkje fungere, uansett kor lenge du ventar på at ho skal dukke opp i loggane til leverandøren.

Delt tunnel og tvungen tunellering side om side

Berre den andre rada endrar adressa ein ekstern teneste ser. Alt anna i den tabellen er kostnad og driftsflate du godtek når utgangen må inspiserast eller setjast om inne i Azure. Viss nokon ber deg få den offentlege IP-en til å endre seg, ber dei om heile høgre kolonne, ikkje ei lita justering på klienten.

Det finst eit mellomalternativ som er verdt å nemne før du byggjer noko på nytt. Ein proxy- eller gateway-VM inne i VNet gir deg ei kontrollert kjeldeadresse for applikasjonane som kan peikast dit, utan å flytte standardruta til klienten. Det held vanleg surfing lokalt og tilfredsstiller framleis ein partnar som berre treng at eitt API-kall kjem frå Azure. Det feilar når kravet eigenleg gjeld all trafikk, fordi alt som ignorerer proxyinnstillinga framleis går ut lokalt.

Få tunnelen til å bera standardruta

På ein virtuell nettverksgateway er den støtta måten å styre all internettrafikken til klienten inn i tunnelen å leggje til eigendefinerte ruter i point-to-site-konfigurasjonen. To halvdelar dekkjer heile IPv4-rommet, og kvar er meir spesifikk enn den lokale standardruta, så klienten føretrekkjer dei utan å sletta noko:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Den linja er illustrerande og ikkje komplett for kopiering: hent gateway-objektet først med Get-AzVirtualNetworkGateway og set det inn i staden for GWOBJ, og stadfest at SKU-en og distribusjonsmodellen godtek eigendefinerte ruter før du køyrer han. Dei same prefiksa viser seg i portalen på point-to-site-konfigurasjonssida, som er den tryggare staden å setje dei viss du ikkje allereie skriptstyrer gatewayen.

Endring av desse prefiksa gjer klientpakka ugild. Last ned VPN-klientpakka på nytt og installer ho på nytt, fordi rutene reiser inne i profilen. Ein klient som koplar til på nytt med den gamle profilen sin, held på det gamle rutessettet, og du kan miste ein time på å feilsøkje ei endring som aldri nådde han.

I eit sikra virtuelt WAN-hub er ekvivalenten ei standardrute i hub-rutetabellen knytt til point-to-site-gatewayen, medan Azure Firewall i huben tek trafikken. Brannmuren set om internettretta samband til sine eigne offentlege IP-adresser, og det er den omsetjinga den nye utgangsadressa kjem frå. Når ein brannmur har fleire offentlege IP-ar, kan kven som helst av dei visast som kjelda, så ei allowlist må innehalde alle.

Båe designa over er IPv4. Dei to /1-prefiksa gjer ingenting for IPv6, og point-to-site-IPv6-støtta er smal nok til at du bør teste kombinasjonen før du lovar paritet.

Sjekk ruta, deretter utgangen

Etter å ha installert pakka på nytt og kopla til, stadfest at klienten faktisk installerte halvdelane. På Windows bør Get-NetRoute -DestinationPrefix 0.0.0.0/1 og den same spørjinga for 128.0.0.0/1 namngje tunnelgrensesnittet, og route print viser båe ved sida av den opphavlege standardruta di. På Linux må ip route show liste dei to prefiksa; viss ikkje har profilen aldri bore dei.

Sjekk deretter den offentlege adressa frå klienten på nytt og les brannmurloggen for den same forbindinga. Kjelda bør vere den offentlege IP-en til brannmuren med ein omsett port. Ein klient som framleis går ut lokalt medan båe rutene finst, tyder at pakkane nådde Azure og forlét via ein annan veg: ei brukardefinert rute på gateway-subnettet, ein brannmur som sjølv er tvinga i tunnel til det lokale nettverket, eller ein policy som slepp straumen før omsetjinga.

Test ein privat destinasjon på nytt i same økta. Ein jump-host som sluttar å svare etter endringa er det vanlege teiknet på at dei nye prefiksa har fortrengt noko, anten ei smalare lokal rute som tidlegare vart annonsert, eller namneoppløysing som no går til ein resolver utan vidaresendar for dei private sonene dine.

Når du skal la den delte tunnelen vere i fred

Viss målet berre er å nå ein privat API, eit privat endepunkt eller ei intern admin-side, er standardåtferda billegare og stillare. Tvungen tunellering legg til brannmurtimar og databehandlingskostnader, ein lengre veg og ein stad til der kvar klientstraum kan feile. Det fangar òg langt meir trafikk enn den eine destinasjonen du brydde deg om.

Grip til han når kravet er formulert i høve til utgang: ein partnar må sjå ei fast Azure-adresse, tryggleiken vil at forbindingane skal loggast og inspiserast, eller data må forlate gjennom eitt kontrollert punkt. Sjølv då gir designet kvar brukar ein delt utgang, så ansvarlegheit per brukar må kome frå identitet i applikasjonen snarare enn frå kjeldeadressa.

Før du lukkar endringa, stadfest fire ting: den installerte klientpakka er den nye, dei to /1-rutene sit på tunnelgrensesnittet, ein privat destinasjon svarar framleis, og loggen til den eksterne tenesta viser brannmuradressa.