Cloud VPN para uma VM no GCP: use o IP interno, não o IP de NAT

Quando uma rede local chega a uma VPC por meio do Cloud VPN, o destino de um serviço do Compute Engine costuma ser o endereço interno da VM. O endereço IPv4 externo não é um segundo endereço que se possa substituir na mesma rota privada. A maior parte da confusão nessa área vem de tratar três endereços com três funções como intercambiáveis, então comece nomeando qual deles um determinado pacote usa.

Três endereços, três funções

Nomeie os três antes de depurar qualquer um deles, porque a resposta muda o objeto que você inspeciona em seguida.

O primeiro pertence ao túnel. O segundo pertence ao projeto da rota e do firewall. O terceiro pertence ao acesso de entrada da internet e é mapeado, não anexado. Um projeto que funciona para um deles não diz nada sobre os outros dois.

Por que o endereço externo não é uma segunda interface

O guia de endereçamento é a autoridade sobre como a acessibilidade interna e a externa diferem no Compute Engine. Um IPv4 externo do Compute Engine é um mapeamento um-para-um sobre a única NIC interna da instância, então o convidado nunca vê uma segunda interface nem um segundo endereço nessa NIC. O que a VM relata por dentro continua sendo um endereço interno primário.

É por isso que um cliente privado que roteia pelo túnel para 10.24.1.7 e um cliente que aponta para o endereço externo da VM estão em caminhos diferentes. Abrir uma regra de firewall para o endereço público não muda nada na rota da VPC que precisa transportar o tráfego do túnel, e editar uma rota no convidado não desloca o mapeamento da plataforma. Escolha o endereço que a sua rota nomeia e depois inspecione apenas os objetos que o governam. Essa disciplina remove a maior parte das suposições desse caminho de solução de problemas.

Percorra o caminho com o gcloud

Comece pela instância e leia os dois endereços do mesmo objeto, para saber de qual a sua documentação está falando:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Depois confirme o roteamento e a permissão dos quais o caminho realmente depende:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Leia os intervalos anunciados e aprendidos do túnel, a rota da VPC para a sub-rede da carga de trabalho e a regra de firewall que permite a origem local. Esses três precisam concordar antes que um ouvinte no convidado seja sequer relevante.

Depois verifique o convidado: o serviço escuta no endereço interno, e o caminho de retorno passa de novo pela VPC? Um ouvinte vinculado apenas a um endereço público falhará neste teste mesmo quando todo objeto do lado da nuvem estiver correto.

Um prefixo público é outra questão

Nada disso significa que todo endereço transportado dentro de uma VPN precise ser RFC1918. Uma rede remota pode ser numerada legitimamente a partir do espaço público, desde que a plataforma suporte o roteamento e o operador detenha a autoridade sobre o endereço. É uma escolha de projeto normal.

Isso não é o mesmo que tratar um endereço NAT externo comum como se fosse outro endereço de sub-rede interna. Um é um prefixo que você roteia; o outro é um mapeamento que a plataforma aplica ao acesso de entrada.

O IPv6 externo e os arranjos de endereços projetados especialmente têm a sua própria semântica. Se o seu plano depende de um deles, leia a documentação da plataforma para esse recurso em vez de generalizar a partir do caso IPv4. O mapeamento IPv4 é o caso comum, não o único, e as exceções têm cada uma as suas próprias regras.

Intervalos sobrepostos são outro problema

Intervalos privados sobrepostos são um motivo real para as pessoas recorrerem ao endereço público, e é a alavanca errada. Mudar o destino para o endereço NAT da VM não resolve a sobreposição; muda para qual endereço o pacote afirma ser, sem definir como o caminho de retorno funciona.

Resolva a sobreposição de propósito: renumerar, usar um projeto de tradução compatível ou rotear por uma rede onde os prefixos não colidam. Cada uma dessas é um projeto com um responsável. O endereço NAT não é um projeto.

Documente os dois campos separadamente

Registre o par do túnel e o destino da carga de trabalho como dois campos separados do runbook, cada um com a rota e a regra de firewall que o sustentam. Um túnel IPsec que sobe só informa que as partes concordam; não diz nada sobre em qual endereço a carga de trabalho é acessível, nem sobre se a rota privada dela está completa.

Verifique com um cliente real do outro lado: resolva o nome, confirme que ele retorna o endereço interno, conecte-se e confira o tráfego de retorno. A documentação de endereços IP do Compute Engine é a referência para a distinção entre interno e externo usada acima.