Per què el VPN punt a lloc d'Azure no canvia la teva IP pública
Un túnel punt a lloc només transporta rutes de la xarxa virtual, així que la teva IP pública continua sent local fins que el túnel forçat i el SNAT del tallafoc mouen la sortida a Azure.
Connecto el client d'Azure VPN en un portàtil Windows, obro una pàgina d'eco d'adreces i veig la mateixa adreça pública que em va assignar el router de casa. Mentrestant, la màquina de salt de 10.20.0.4 respon i un nom de punt final privat es resol, així que el túnel no està trencat. Una passarel·la punt a lloc fa exactament el que diu la seva configuració per defecte: transporta els prefixos privats i deixa la resta a l'enllaç local. Aconseguir una adreça de sortida propietat d'Azure és un canvi de disseny d'encaminament, no una reparació.
Què anuncia la passarel·la per defecte
La passarel·la envia rutes per a l'espai d'adreces de la xarxa virtual, més les xarxes entre iguals on es permet el trànsit de passarel·la i els prefixos locals apresos per una connexió de lloc a lloc o BGP. No hi ha cap 0.0.0.0/0 en aquest conjunt. El teu sistema operatiu manté la ruta per defecte a Wi-Fi o Ethernet, així que un paquet cap a una API pública no entra mai al túnel.
L'adreça que un client rep dins del túnel és un arrendament privat del pool punt a lloc. Identifica el client davant dels recursos de la VNet; no és una adreça que internet pugui veure i mai no apareixerà com a origen d'una petició sortint cap a una API SaaS. Una entrada de llista d'autoritzats construïda al voltant d'aquest arrendament no pot funcionar, per molt que esperis que aparegui als registres del proveïdor.
Túnel dividit i túnel forçat, l'un al costat de l'altre
| 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 |
Només la segona fila canvia l'adreça que veu un servei remot. Tota la resta d'aquesta taula és cost i superfície operativa que acceptes quan la sortida s'ha d'inspeccionar o traduir dins d'Azure. Si algú et demana que la IP pública canviï, està demanant tota la columna de la dreta, no un retoc al client.
Hi ha una opció intermèdia que val la pena esmentar abans de reconstruir res. Una VM de proxy o passarel·la dins de la VNet et dona una adreça d'origen controlada per a les aplicacions que hi puguin apuntar, sense moure la ruta per defecte del client. Això manté la navegació normal local i encara satisfà un soci que només necessita que una crida d'API arribi des d'Azure. Falla quan el requisit és realment sobre tot el trànsit, perquè qualsevol cosa que ignori la configuració del proxy continua sortint localment.
Fes que el túnel porti la ruta per defecte
En una passarel·la de xarxa virtual, la manera suportada de dirigir tot el trànsit d'internet del client cap al túnel és afegir rutes personalitzades a la configuració punt a lloc. Dues meitats cobreixen tot l'espai IPv4, i cadascuna és més específica que la ruta per defecte local, així que el client les prefereix sense esborrar res:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Aquesta línia és il·lustrativa, no completa per copiar i enganxar: primer obtén l'objecte de la passarel·la amb Get-AzVirtualNetworkGateway i substitueix-lo per GWOBJ, i confirma que l'SKU i el model de desplegament accepten rutes personalitzades abans d'executar-lo. Els mateixos prefixos apareixen al portal a la pàgina de configuració punt a lloc, que és el lloc més segur per establir-los si ja no scripts la passarel·la.
Canviar aquests prefixos invalida el paquet del client. Torna a baixar el paquet del client VPN i reinstal·la'l, perquè les rutes viatgen dins del perfil. Un client que es reconnecta amb el seu perfil antic conserva el conjunt de rutes antic, i pots perdre una hora depurant un canvi que mai no li va arribar.
En un hub de WAN virtual protegit, l'equivalent és una ruta per defecte a la taula de rutes del hub associada a la passarel·la punt a lloc, amb Azure Firewall al hub assumint el trànsit. El tallafoc tradueix les connexions cap a internet a les seves pròpies adreces IP públiques, i d'aquesta traducció surt la nova adreça de sortida. Quan un tallafoc té diverses IP públiques, qualsevol d'elles pot aparèixer com a origen, així que la llista d'autoritzats les ha de contenir totes.
Tots dos dissenys de dalt són IPv4. Els dos prefixos /1 no fan res per a IPv6, i el suport IPv6 punt a lloc és prou estret que cal provar la combinació abans de prometre paritat.
Comprova la ruta i després la sortida
Després de reinstal·lar el paquet i reconnectar-te, confirma que el client ha instal·lat realment les meitats. A Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 i la mateixa consulta per a 128.0.0.0/1 haurien de nomenar la interfície del túnel, i route print mostra les dues al costat de la teva ruta per defecte original. A Linux, ip route show ha de llistar els dos prefixos; si no ho fa, el perfil no els va portar mai.
A continuació, torna a comprovar l'adreça pública des del client i llegeix el registre del tallafoc per a la mateixa connexió. L'origen hauria de ser la IP pública del tallafoc amb un port traduït. Un client que encara surt localment mentre existeixen les dues rutes significa que els paquets van arribar a Azure i van sortir per un altre camí: una ruta definida per l'usuari a la subxarxa de la passarel·la, un tallafoc que ell mateix està forçat a túnel cap a local, o una política que descarta el flux abans de la traducció.
Torna a provar una destinació privada a la mateixa sessió. Un amfitrió de salt que deixa de respondre després del canvi és el senyal habitual que els nous prefixos han desplaçat alguna cosa, o bé una ruta local més estreta que abans s'anunciava o bé la resolució de noms que ara va a un resolutor sense reenviador per a les teves zones privades.
Quan deixar el túnel dividit tranquil
Si l'objectiu és només arribar a una API privada, un punt final privat o una pàgina d'administració interna, el comportament per defecte és més barat i més silenciós. El túnel forçat afegeix hores de tallafoc i càrrecs de processament de dades, un camí més llarg i un lloc més on cada flux de client pot fallar. També captura molt més trànsit que la única destinació que t'importava.
Recorre-hi quan el requisit s'expressa en termes de sortida: un soci ha de veure una adreça fixa d'Azure, seguretat vol que les connexions es registrin i s'inspeccionin, o les dades han de sortir per un punt controlat. Fins i tot llavors el disseny dona a cada usuari una sortida compartida, així que la responsabilitat per usuari ha de venir de la identitat a l'aplicació i no de l'adreça d'origen.
Abans de tancar el canvi, confirma quatre coses: el paquet de client instal·lat és el nou, les dues rutes /1 són a la interfície del túnel, una destinació privada encara respon i el registre del servei remot mostra l'adreça del tallafoc.