Hvorfor Azure Point-to-Site VPN ikke ændrer din offentlige IP

Jeg forbinder Azure VPN-klienten på en Windows-bærbar, åbner en adresse-ekko-side og ser den samme offentlige adresse, som min hjemmerouter uddelte. Imens svarer jumpboksen på 10.20.0.4, og et privat endpoint-navn opløses, så tunnelen er ikke brudt. En point-to-site-gateway gør præcis det, dens standardkonfiguration siger: den bærer de private præfikser og lader alt andet blive på det lokale link. At få en Azure-ejet udgangsadresse er en ændring af routingdesignet, ikke en reparation.

Hvad gatewayen annoncerer som standard

Gatewayen skubber ruter for det virtuelle netværks adresserum plus peered-netværk, hvor gateway-transit er tilladt, og lokale præfikser lært over en site-to-site-forbindelse eller BGP. Der er ingen 0.0.0.0/0 i det sæt. Dit styresystem beholder sin standardrute på Wi-Fi eller Ethernet, så en pakke til en offentlig API kommer aldrig ind i tunnelen.

Den adresse, en klient får inde i tunnelen, er en privat leasing fra point-to-site-puljen. Den identificerer klienten over for ressourcer i VNet; den er ikke en adresse, internettet kan se, og den vil aldrig optræde som kilden til en udgående anmodning til en SaaS-API. En allowlist-post bygget op omkring den leasing kan ikke virke, uanset hvor længe du venter på, at den dukker op i leverandørens logfiler.

Split tunnel og tvungen tunneling side om side

Kun den anden række ændrer den adresse, en fjern tjeneste ser. Alt andet i den tabel er omkostninger og driftsflade, du accepterer, når udgangen skal inspiceres eller oversættes inde i Azure. Hvis nogen beder dig få den offentlige IP til at skifte, beder de om hele højre kolonne, ikke om en justering af klienten.

Der er en mellemvej, der er værd at nævne, før du bygger noget om. En proxy- eller gateway-VM inde i VNet giver dig en kontrolleret kildeadresse til de applikationer, der kan peges på den, uden at flytte klientens standardrute. Det holder almindelig browsing lokal og tilfredsstiller stadig en partner, der kun har brug for, at ét API-kald ankommer fra Azure. Den fejler, når kravet reelt handler om al trafik, fordi alt, der ignorerer proxyindstillingen, stadig forlader netværket lokalt.

Få tunnelen til at bære standardruten

På en virtuel netværksgateway er den understøttede måde at styre al klientens internettrafik ind i tunnelen at tilføje brugerdefinerede ruter til point-to-site-konfigurationen. To halvdele dækker hele IPv4-rummet, og hver er mere specifik end den lokale standardrute, så klienten foretrækker dem uden at slette noget:

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

Den linje er illustrativ snarere end klar til kopiering: hent først gateway-objektet med Get-AzVirtualNetworkGateway, og indsæt det i stedet for GWOBJ, og bekræft, at SKU'en og implementeringsmodellen accepterer brugerdefinerede ruter, før du kører den. De samme præfikser vises i portalen på point-to-site-konfigurationssiden, som er det sikrere sted at sætte dem, hvis du ikke allerede scriptstyrer gatewayen.

Ændring af disse præfikser ugyldiggør klientpakken. Download VPN-klientpakken igen, og geninstaller den, fordi ruterne rejser inde i profilen. En klient, der genopretter forbindelse med sin gamle profil, beholder det gamle rutessæt, og du kan miste en time på at fejlfinde en ændring, der aldrig nåede den.

I et sikret virtuelt WAN-hub er ækvivalenten en standardrute i hub-rutetabellen, der er knyttet til point-to-site-gatewayen, mens Azure Firewall i hubben tager trafikken. Firewallen oversætter internetrettede forbindelser til sine egne offentlige IP-adresser, og det er den oversættelse, den nye udgangsadresse kommer fra. Når en firewall har flere offentlige IP'er, kan enhver af dem optræde som kilden, så en allowlist skal indeholde dem alle.

Begge designs ovenfor er IPv4. De to /1-præfikser gør intet for IPv6, og point-to-site-IPv6-understøttelse er smal nok til, at du bør teste kombinationen, før du lover paritet.

Tjek ruten, og derefter udgangen

Når du har geninstalleret pakken og genoprettet forbindelsen, skal du bekræfte, at klienten faktisk installerede halvdelene. På Windows bør Get-NetRoute -DestinationPrefix 0.0.0.0/1 og den samme forespørgsel for 128.0.0.0/1 navngive tunnelgrænsefladen, og route print viser begge ved siden af din oprindelige standardrute. På Linux skal ip route show liste de to præfikser; hvis ikke, har profilen aldrig båret dem.

Tjek derefter den offentlige adresse fra klienten igen, og læs firewall-loggen for den samme forbindelse. Kilden bør være firewallens offentlige IP med en oversat port. En klient, der stadig går ud lokalt, mens begge ruter findes, betyder, at pakkerne nåede Azure og forlod ad en anden vej: en brugerdefineret rute på gateway-undernettet, en firewall, der selv er tvunget gennem tunnel til det lokale netværk, eller en politik, der dropper flowet før oversættelsen.

Genafprøv én privat destination i samme session. En jump-host, der holder op med at svare efter ændringen, er det sædvanlige tegn på, at de nye præfikser har fortrængt noget, enten en mere snæver lokal rute, der tidligere blev annonceret, eller navneopløsning, der nu går til en resolver uden forwarder til dine private zoner.

Hvornår du skal lade split-tunnelen være

Hvis målet kun er at nå en privat API, et privat endpoint eller en intern admin-side, er standardadfærden billigere og mere stille. Tvungen tunneling tilføjer firewall-timer og databehandlingsomkostninger, en længere vej og endnu et sted, hvor hvert klientflow kan fejle. Den fanger også langt mere trafik end den ene destination, du bekymrede dig om.

Grib efter den, når kravet er formuleret i forhold til udgang: en partner skal se en fast Azure-adresse, sikkerhed vil have forbindelserne logget og inspiceret, eller data skal forlade gennem ét kontrolleret punkt. Selv da giver designet hver bruger en delt udgang, så ansvarlighed pr. bruger skal komme fra identitet i applikationen snarere end fra kildeadressen.

Før du lukker ændringen, skal du bekræfte fire ting: den installerede klientpakke er den nye, de to /1-ruter sidder på tunnelgrænsefladen, en privat destination svarer stadig, og den eksterne tjenestes log viser firewall-adressen.