Por que a VPN de punto a sitio de Azure non cambia o teu IP público

Conecto o cliente de Azure VPN nun portátil Windows, abro unha páxina de eco de enderezo e vexo o mesmo enderezo público que me deu o router da casa. Mentres tanto, o jump box en 10.20.0.4 responde e un nome de punto final privado resólvese, así que o túnel non está roto. Unha pasarela de punto a sitio fai exactamente o que di a súa configuración predeterminada: transporta os prefixos privados e deixa todo o demais na ligazón local. Conseguir un enderezo de saída propiedade de Azure é un cambio de deseño de enrutamento, non unha reparación.

Que anuncia a pasarela por defecto

A pasarela empuxa rutas para o espazo de enderezos da rede virtual, ademais das redes emparelladas onde se permite o tránsito de pasarela e os prefixos locais aprendidos por unha conexión de sitio a sitio ou BGP. Non hai 0.0.0.0/0 nese conxunto. O teu sistema operativo mantén a súa ruta predeterminada en Wi-Fi ou Ethernet, así que un paquete cara a unha API pública nunca entra no túnel.

O enderezo que recibe un cliente dentro do túnel é un arrendamento privado do pool de punto a sitio. Identifica o cliente ante os recursos da VNet; non é un enderezo que internet poida ver e nunca aparecerá como orixe dunha solicitude saínte cara a unha API SaaS. Unha entrada de lista de permitidos construída arredor dese arrendamento non pode funcionar, por moito que esperes a que apareza nos rexistros do provedor.

Túnel dividido e túnel forzado un xunto ao outro

Só a segunda fila cambia o enderezo que ve un servizo remoto. Todo o demais nesa táboa é custo e superficie operativa que aceptas cando a saída debe inspeccionarse ou traducirse dentro de Azure. Se alguén che pide que o IP público cambie, está a pedir toda a columna dereita, non un axuste no cliente.

Hai unha opción intermedia que merece ser nomeada antes de reconstruír nada. Unha VM de proxy ou pasarela dentro da VNet dálle un enderezo de orixe controlado ás aplicacións que se poidan apuntar a ela, sen mover a ruta predeterminada do cliente. Iso mantén a navegación normal local e segue satisfacendo un socio que só necesita que unha chamada á API chegue desde Azure. Falla cando o requisito é realmente sobre todo o tráfico, porque calquera cousa que ignore a configuración do proxy segue saíndo localmente.

Fai que o túnel transporte a ruta predeterminada

Nunha pasarela de rede virtual, a forma admitida de dirixir todo o tráfico de internet do cliente ao túnel é engadir rutas personalizadas á configuración de punto a sitio. Dúas metades cobren todo o espazo IPv4, e cada unha é máis específica que a ruta predeterminada local, así que o cliente prefire esas sen borrar nada:

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

Esa liña é ilustrativa e non está completa para copiar e pegar: obtén primeiro o obxecto da pasarela con Get-AzVirtualNetworkGateway e substitúeo por GWOBJ, e confirma que a SKU e o modelo de despregamento aceptan rutas personalizadas antes de executalo. Os mesmos prefixos aparecen no portal na páxina de configuración de punto a sitio, que é o lugar máis seguro para fixalos se aínda non automatizas a pasarela.

Cambiar eses prefixos invalida o paquete do cliente. Descarga de novo o paquete do cliente VPN e reinstálao, porque as rutas viaxan dentro do perfil. Un cliente que se reconecta co seu perfil antigo conserva o conxunto de rutas antigo, e podes perder unha hora depurando un cambio que nunca lle chegou.

Nun hub de WAN virtual protexido, o equivalente é unha ruta predeterminada na táboa de rutas do hub asociada á pasarela de punto a sitio, co Azure Firewall no hub collendo o tráfico. A devasa traduce as conexións cara a internet aos seus propios enderezos IP públicos, e desa tradución vén o novo enderezo de saída. Cando unha devasa ten varias IP públicas, calquera delas pode aparecer como orixe, así que unha lista de permitidos ten que contelas todas.

Ambos os deseños anteriores son IPv4. Os dous prefixos /1 non fan nada por IPv6, e o soporte IPv6 de punto a sitio é o bastante estreito como para que probes a combinación antes de prometer paridade.

Comproba a ruta e despois a saída

Trala reinstalación do paquete e a reconexión, confirma que o cliente instalou realmente as metades. En Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 e a mesma consulta para 128.0.0.0/1 deberían nomear a interface do túnel, e route print mostra ambas xunto á túa ruta predeterminada orixinal. En Linux, ip route show debe listar os dous prefixos; se non o fai, o perfil nunca os transportou.

Despois volve comprobar o enderezo público desde o cliente e le o rexistro da devasa para a mesma conexión. A orixe debería ser o IP público da devasa cun porto traducido. Un cliente que segue saíndo localmente mentres existen as dúas rutas significa que os paquetes chegaron a Azure e saíron por outro camiño: unha ruta definida polo usuario na subrede da pasarela, unha devasa que á súa vez está forzada a tunelizar cara á rede local, ou unha política que descarta o fluxo antes da tradución.

Volta probar un destino privado na mesma sesión. Un host de salto que deixa de responder tras o cambio é o sinal habitual de que os novos prefixos desprazaron algo, xa sexa unha ruta local máis estreita que antes se anunciaba ou a resolución de nomes que agora vai a un resolutor sen reenviador para as túas zonas privadas.

Cando deixar o túnel dividido en paz

Se o obxectivo é só chegar a unha API privada, un punto final privado ou unha páxina de administración interna, o comportamento predeterminado é máis barato e máis silencioso. O túnel forzado engade horas de devasa e cargos de procesamento de datos, un camiño máis longo e un lugar máis onde cada fluxo de cliente pode fallar. Tamén captura moito máis tráfico que o único destino que che importaba.

Recorre a el cando o requisito se expón en termos de saída: un socio debe ver un enderezo Azure fixo, seguridade quere as conexións rexistradas e inspeccionadas, ou os datos teñen que saír por un punto controlado. Aínda así, o deseño dá a cada usuario unha saída compartida, así que a responsabilidade por usuario debe vir da identidade na aplicación e non do enderezo de orixe.

Antes de pechar o cambio, confirma catro cousas: o paquete de cliente instalado é o novo, as dúas rutas /1 están na interface do túnel, un destino privado segue respondendo e o rexistro do servizo remoto mostra o enderezo da devasa.