Varför Azure Point-to-Site VPN inte ändrar din offentliga IP
En point-to-site-tunnel transporterar bara rutter för det virtuella nätverket, så din offentliga IP förblir lokal tills påtvingad tunneling och brandväggens SNAT flyttar utgången till Azure.
Jag ansluter Azure VPN-klienten på en Windows-bärbar, öppnar en adressekosida och ser samma offentliga adress som min hemrouter delade ut. Under tiden svarar jumpboxen på 10.20.0.4 och ett privat slutpunktsnamn löses upp, så tunneln är inte trasig. En point-to-site-gateway gör exakt det som standardkonfigurationen säger: den transporterar de privata prefixen och låter allt annat stanna på den lokala länken. Att få en Azure-ägd utgångsadress är en ändring av routingdesignen, inte en reparation.
Vad gatewayen annonserar som standard
Gatewayen skjuter ut rutter för det virtuella nätverkets adressutrymme, plus peer-nätverk där gateway-transit är tillåten och lokala prefix som lärts in via en site-to-site-anslutning eller BGP. Det finns ingen 0.0.0.0/0 i den uppsättningen. Ditt operativsystem behåller sin standardrutt på Wi-Fi eller Ethernet, så ett paket till ett offentligt API kommer aldrig in i tunneln.
Adressen en klient får inne i tunneln är en privat lease från point-to-site-poolen. Den identifierar klienten för resurser i VNet; den är inte en adress som internet kan se, och den kommer aldrig att dyka upp som källan till en utgående begäran till ett SaaS-API. En allowlist-post byggd kring den leasen kan inte fungera, hur länge du än väntar på att den ska dyka upp i leverantörens loggar.
Delad tunnel och påtvingad tunneling sida vid sida
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
Bara den andra raden ändrar den adress som en fjärrtjänst ser. Allt annat i den tabellen är kostnad och driftsyta som du accepterar när utgången måste inspekteras eller översättas inne i Azure. Om någon ber dig få den offentliga IP:n att ändras ber de om hela den högra kolumnen, inte en liten justering av klienten.
Det finns ett mellanting som är värt att nämna innan du bygger om något. En proxy- eller gateway-VM i VNet ger dig en kontrollerad källadress för de program som kan pekas dit, utan att flytta klientens standardrutt. Det håller vanlig surfning lokal och tillfredsställer fortfarande en partner som bara behöver att ett API-anrop kommer från Azure. Det misslyckas när kravet verkligen gäller all trafik, eftersom allt som ignorerar proxyinställningen ändå går ut lokalt.
Få tunneln att bära standardrutten
På en virtuell nätverksgateway är det stödda sättet att styra all klientens internettrafik in i tunneln att lägga till anpassade rutter i point-to-site-konfigurationen. Två halvor täcker hela IPv4-rymden, och var och en är mer specifik än den lokala standardrutten, så klienten föredrar dem utan att radera något:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Den raden är illustrativ och inte komplett att kopiera: hämta först gateway-objektet med Get-AzVirtualNetworkGateway och sätt in det i stället för GWOBJ, och bekräfta innan du kör den att SKU:n och distributionsmodellen accepterar anpassade rutter. Samma prefix visas i portalen på sidan för point-to-site-konfiguration, vilket är den säkrare platsen att sätta dem om du inte redan skriptar gatewayen.
Att ändra dessa prefix gör klientpaketet ogiltigt. Ladda ner VPN-klientpaketet igen och installera om det, eftersom rutterna reser inuti profilen. En klient som återansluter med sin gamla profil behåller den gamla ruttuppsättningen, och du kan förlora en timme på att felsöka en ändring som aldrig nådde den.
I ett skyddat virtuellt WAN-nav är motsvarigheten en standardrutt i navets rutttabell som är kopplad till point-to-site-gatewayen, där Azure Firewall i navet tar trafiken. Brandväggen översätter internetbundna anslutningar till sina egna offentliga IP-adresser, och det är den översättningen den nya utgångsadressen kommer från. När en brandvägg har flera offentliga IP:n, kan vilken som helst av dem visas som källan, så en allowlist måste innehålla alla.
Båda designerna ovan är IPv4. De två /1-prefixen gör ingenting för IPv6, och point-to-site-IPv6-stödet är tillräckligt smalt för att du bör testa kombinationen innan du lovar paritet.
Kontrollera rutten och sedan utgången
När du har installerat om paketet och återanslutit, bekräfta att klienten faktiskt installerade halvorna. På Windows bör Get-NetRoute -DestinationPrefix 0.0.0.0/1 och samma fråga för 128.0.0.0/1 namnge tunnelgränssnittet, och route print visar båda bredvid din ursprungliga standardrutt. På Linux måste ip route show lista de två prefixen; om inte har profilen aldrig burit dem.
Kontrollera sedan den offentliga adressen från klienten igen och läs brandväggsloggen för samma anslutning. Källan bör vara brandväggens offentliga IP med en översatt port. En klient som fortfarande går ut lokalt medan båda rutterna finns betyder att paketen nådde Azure och lämnade via en annan väg: en användardefinierad rutt på gateway-undernätet, en brandvägg som själv är påtvingat tunnlad till det lokala nätverket, eller en princip som släpper flödet före översättningen.
Testa en privat destination igen i samma session. En jump-host som slutar svara efter ändringen är det vanliga tecknet på att de nya prefixen har trängt undan något, antingen en smalare lokal rutt som tidigare annonserades eller namnmatchning som nu går till en resolver utan vidarebefordrare för dina privata zoner.
När du ska låta den delade tunneln vara
Om målet bara är att nå ett privat API, en privat slutpunkt eller en intern adminsida är standardbeteendet billigare och tystare. Påtvingad tunneling lägger till brandväggstimmar och databehandlingskostnader, en längre väg och ännu en plats där varje klientflöde kan misslyckas. Den fångar också mycket mer trafik än den enda destination du brydde dig om.
Använd den när kravet formuleras i termer av utgång: en partner måste se en fast Azure-adress, säkerheten vill att anslutningarna loggas och inspekteras, eller data måste lämna genom en kontrollerad punkt. Även då ger designen varje användare en delad utgång, så ansvarighet per användare måste komma från identitet i applikationen snarare än från källadressen.
Innan du stänger ändringen, bekräfta fyra saker: det installerade klientpaketet är det nya, de två /1-rutterna sitter på tunnelgränssnittet, en privat destination svarar fortfarande, och loggen för fjärrtjänsten visar brandväggens adress.