Porque é que a VPN ponto a site do Azure não altera o teu IP público

Ligo o cliente Azure VPN num portátil Windows, abro uma página de eco de endereço e vejo o mesmo endereço público que o router de casa atribuiu. Entretanto, o jump box em 10.20.0.4 responde e um nome de ponto final privado resolve-se, pelo que o túnel não está partido. Um gateway ponto a site faz exatamente o que diz a configuração predefinida: transporta os prefixos privados e deixa tudo o resto na ligação local. Obter um endereço de saída pertencente ao Azure é uma mudança de desenho de encaminhamento, não uma reparação.

O que o gateway anuncia por predefinição

O gateway envia rotas para o espaço de endereços da rede virtual, mais as redes emparelhadas onde o trânsito de gateway é permitido e os prefixos locais aprendidos através de uma ligação site-to-site ou BGP. Não existe 0.0.0.0/0 nesse conjunto. O teu sistema operativo mantém a rota predefinida em Wi-Fi ou Ethernet, pelo que um pacote para uma API pública nunca entra no túnel.

O endereço que um cliente recebe dentro do túnel é um aluguer privado do pool ponto a site. Identifica o cliente perante os recursos na VNet; não é um endereço que a internet possa ver e nunca aparecerá como origem de um pedido de saída para uma API SaaS. Uma entrada de lista de permitidos construída em torno desse aluguer não pode funcionar, por muito que esperes que apareça nos registos do fornecedor.

Túnel dividido e túnel forçado lado a lado

Só a segunda linha altera o endereço que um serviço remoto vê. Tudo o resto nessa tabela é custo e superfície operacional que aceitas quando a saída tem de ser inspecionada ou traduzida dentro do Azure. Se alguém te pedir para alterar o IP público, está a pedir a coluna direita inteira, não um ajuste no cliente.

Há uma opção intermédia que vale a pena nomear antes de reconstruíres algo. Uma VM de proxy ou gateway dentro da VNet dá-te um endereço de origem controlado para as aplicações que possam apontar para ela, sem mover a rota predefinida do cliente. Isso mantém a navegação normal local e continua a satisfazer um parceiro que só precisa de uma chamada de API vinda do Azure. Falha quando o requisito é realmente sobre todo o tráfego, porque tudo o que ignorar a definição de proxy continua a sair localmente.

Faz o túnel transportar a rota predefinida

Num gateway de rede virtual, a forma suportada de encaminhar todo o tráfego de internet do cliente para o túnel é adicionar rotas personalizadas à configuração ponto a site. Duas metades cobrem todo o espaço IPv4, e cada uma é mais específica do que a rota predefinida local, pelo que o cliente as prefere sem apagar nada:

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

Essa linha é ilustrativa, não está completa para copiar e colar: obtém primeiro o objeto do gateway com Get-AzVirtualNetworkGateway e substitui o GWOBJ por ele, e confirma que o SKU e o modelo de implementação aceitam rotas personalizadas antes de o executar. Os mesmos prefixos aparecem no portal na página de configuração ponto a site, que é o local mais seguro para os definir se ainda não automatizas o gateway.

Alterar esses prefixos invalida o pacote do cliente. Descarrega novamente o pacote do cliente VPN e reinstala-o, porque as rotas viajam dentro do perfil. Um cliente que se reconecte com o perfil antigo mantém o conjunto de rotas antigo, e podes perder uma hora a depurar uma alteração que nunca lhe chegou.

Num hub de WAN virtual protegido, o equivalente é uma rota predefinida na tabela de rotas do hub associada ao gateway ponto a site, com o Azure Firewall no hub a assumir o tráfego. A firewall traduz as ligações para a internet nos seus próprios endereços IP públicos, e é dessa tradução que vem o novo endereço de saída. Quando uma firewall tem vários IP públicos, qualquer um deles pode aparecer como origem, pelo que uma lista de permitidos tem de os conter todos.

Ambos os desenhos acima são IPv4. Os dois prefixos /1 não fazem nada pelo IPv6, e o suporte IPv6 ponto a site é suficientemente estreito para que devas testar a combinação antes de prometer paridade.

Verifica a rota e depois a saída

Depois de reinstalar o pacote e reconectar, confirma que o cliente instalou realmente as metades. No Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 e a mesma consulta para 128.0.0.0/1 devem indicar a interface do túnel, e route print mostra ambas ao lado da tua rota predefinida original. No Linux, ip route show tem de listar os dois prefixos; se não o fizer, o perfil nunca os transportou.

Em seguida, verifica novamente o endereço público a partir do cliente e lê o registo da firewall para a mesma ligação. A origem deve ser o IP público da firewall com uma porta traduzida. Um cliente que ainda sai localmente enquanto ambas as rotas existem significa que os pacotes chegaram ao Azure e saíram por outro caminho: uma rota definida pelo utilizador na sub-rede do gateway, uma firewall que ela própria está forçada em túnel para a rede local, ou uma política que descarta o fluxo antes da tradução.

Testa novamente um destino privado na mesma sessão. Um anfitrião de salto que deixa de responder após a alteração é o sinal habitual de que os novos prefixos deslocaram algo, ou uma rota local mais estreita que antes era anunciada, ou a resolução de nomes que agora vai para um resolver sem reencaminhador para as tuas zonas privadas.

Quando deixar o túnel dividido em paz

Se o objetivo for apenas chegar a uma API privada, um ponto final privado ou uma página de administração interna, o comportamento predefinido é mais barato e mais silencioso. O túnel forçado acrescenta horas de firewall e custos de processamento de dados, um caminho mais longo e mais um local onde cada fluxo de cliente pode falhar. Também captura muito mais tráfego do que o único destino que te preocupava.

Recorre a ele quando o requisito é formulado em termos de saída: um parceiro tem de ver um endereço Azure fixo, a segurança quer as ligações registadas e inspecionadas, ou os dados têm de sair por um único ponto controlado. Mesmo assim, o desenho dá a cada utilizador uma saída partilhada, pelo que a responsabilidade por utilizador tem de vir da identidade na aplicação e não do endereço de origem.

Antes de fechar a alteração, confirma quatro coisas: o pacote de cliente instalado é o novo, as duas rotas /1 estão na interface do túnel, um destino privado ainda responde e o registo do serviço remoto mostra o endereço da firewall.