Hvorfor Azure Point-to-Site VPN ikke endrer din offentlige IP

Jeg kobler til Azure VPN-klienten på en Windows-bærbar, åpner en adresse-ekko-side og ser den samme offentlige adressen som hjemmeruteren min delte ut. I mellomtiden svarer jumpboksen på 10.20.0.4, og et privat endepunktnavn løses opp, så tunnelen er ikke ødelagt. En point-to-site-gateway gjør nøyaktig det standardkonfigurasjonen sier: den frakter de private prefiksene og lar alt annet bli på den lokale lenken. Å få en Azure-eid utgangsadresse er en endring av rutingsdesignet, ikke en reparasjon.

Hva gatewayen annonserer som standard

Gatewayen skyver ruter for det virtuelle nettverkets adresserom, i tillegg til peer-nettverk der gateway-transitt er tillatt og lokale prefikser lært over en site-to-site-forbindelse eller BGP. Det er ingen 0.0.0.0/0 i det settet. Operativsystemet ditt beholder standardruten på Wi-Fi eller Ethernet, så en pakke til en offentlig API kommer aldri inn i tunnelen.

Adressen en klient får inne i tunnelen, er en privat lease fra point-to-site-poolen. Den identifiserer klienten overfor ressurser i VNet; den er ikke en adresse internett kan se, og den vil aldri dukke opp som kilden til en utgående forespørsel til en SaaS-API. En allowlist-oppføring bygget rundt den leasen kan ikke fungere, uansett hvor lenge du venter på at den skal dukke opp i leverandørens logger.

Delt tunnel og tvungen tunneling side om side

Bare den andre raden endrer adressen en ekstern tjeneste ser. Alt annet i den tabellen er kostnad og driftsflate du godtar når utgangen må inspiseres eller oversettes inne i Azure. Hvis noen ber deg få den offentlige IP-en til å endre seg, ber de om hele høyre kolonne, ikke en liten justering på klienten.

Det finnes et mellomalternativ som er verdt å nevne før du bygger noe på nytt. En proxy- eller gateway-VM inne i VNet gir deg en kontrollert kildeadresse for applikasjonene som kan pekes dit, uten å flytte klientens standardrute. Det holder vanlig surfing lokalt og tilfredsstiller fortsatt en partner som bare trenger at ett API-kall kommer fra Azure. Det feiler når kravet egentlig gjelder all trafikk, fordi alt som ignorerer proxyinnstillingen fortsatt går ut lokalt.

Få tunnelen til å bære standardruten

På en virtuell nettverksgateway er den støttede måten å styre all klientens internettrafikk inn i tunnelen å legge til egendefinerte ruter i point-to-site-konfigurasjonen. To halvdeler dekker hele IPv4-rommet, og hver er mer spesifikk enn den lokale standardruten, så klienten foretrekker dem uten å slette noe:

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

Den linjen er illustrerende og ikke komplett for kopiering: hent gateway-objektet først med Get-AzVirtualNetworkGateway og sett det inn i stedet for GWOBJ, og bekreft at SKU-en og distribusjonsmodellen godtar egendefinerte ruter før du kjører den. De samme prefiksene vises i portalen på point-to-site-konfigurasjonssiden, som er det tryggere stedet å sette dem hvis du ikke allerede skriptstyrer gatewayen.

Endring av disse prefiksene gjør klientpakken ugyldig. Last ned VPN-klientpakken på nytt og installer den på nytt, fordi rutene reiser inne i profilen. En klient som kobler til på nytt med sin gamle profil, beholder det gamle rutessettet, og du kan miste en time på å feilsøke en endring som aldri nådde den.

I et sikret virtuelt WAN-hub er ekvivalenten en standardrute i hub-rutetabellen knyttet til point-to-site-gatewayen, mens Azure Firewall i huben tar trafikken. Brannmuren oversetter internettrettede forbindelser til sine egne offentlige IP-adresser, og det er den oversettelsen den nye utgangsadressen kommer fra. Når en brannmur har flere offentlige IP-er, kan enhver av dem vises som kilden, så en allowlist må inneholde alle.

Begge designene over er IPv4. De to /1-prefiksene gjør ingenting for IPv6, og point-to-site-IPv6-støtten er smal nok til at du bør teste kombinasjonen før du lover paritet.

Sjekk ruten, deretter utgangen

Etter å ha installert pakken på nytt og koblet til, bekreft at klienten faktisk installerte halvdelene. På Windows bør Get-NetRoute -DestinationPrefix 0.0.0.0/1 og den samme spørringen for 128.0.0.0/1 navngi tunnelgrensesnittet, og route print viser begge ved siden av den opprinnelige standardruten din. På Linux må ip route show liste de to prefiksene; hvis ikke har profilen aldri båret dem.

Sjekk deretter den offentlige adressen fra klienten på nytt og les brannmurloggen for den samme forbindelsen. Kilden bør være brannmurens offentlige IP med en oversatt port. En klient som fortsatt går ut lokalt mens begge rutene finnes, betyr at pakkene nådde Azure og forlot via en annen vei: en brukerdefinert rute på gateway-subnettet, en brannmur som selv er tvunget i tunnel til det lokale nettverket, eller en policy som slipper strømmen før oversettelsen.

Test en privat destinasjon på nytt i samme økt. En jump-host som slutter å svare etter endringen er det vanlige tegnet på at de nye prefiksene har fortrengt noe, enten en smalere lokal rute som tidligere ble annonsert, eller navneoppløsning som nå går til en resolver uten videresender for de private sonene dine.

Når du skal la den delte tunnelen være i fred

Hvis målet bare er å nå en privat API, et privat endepunkt eller en intern admin-side, er standardatferden billigere og stillere. Tvungen tunneling legger til brannmurtimer og databehandlingskostnader, en lengre vei og ett sted til der hver klientstrøm kan feile. Den fanger også langt mer trafikk enn den ene destinasjonen du brydde deg om.

Grip til den når kravet er formulert i forhold til utgang: en partner må se en fast Azure-adresse, sikkerhet vil at forbindelsene skal logges og inspiseres, eller data må forlate gjennom ett kontrollert punkt. Selv da gir designet hver bruker en delt utgang, så ansvarlighet per bruker må komme fra identitet i applikasjonen snarere enn fra kildeadressen.

Før du lukker endringen, bekreft fire ting: den installerte klientpakken er den nye, de to /1-rutene sitter på tunnelgrensesnittet, en privat destinasjon svarer fortsatt, og loggen til den eksterne tjenesten viser brannmuradressen.