Cloud VPN a unha VM de GCP: use o IP interno, non o IP de NAT

Cando unha rede local chega a unha VPC a través de Cloud VPN, o destino dun servizo de Compute Engine adoita ser o enderezo interno da VM. O enderezo IPv4 externo non é un segundo enderezo que poida substituír na mesma ruta privada. A maior parte da confusión neste eido vén de tratar tres enderezos con tres tarefas como se fosen intercambiables, así que comece por nomear cal usa un paquete concreto.

Tres enderezos, tres tarefas

Nomee os tres antes de depurar calquera deles, porque a resposta cambia o obxecto que inspeccionará despois.

O primeiro pertence ao túnel. O segundo pertence ao deseño da súa ruta e da súa devasa. O terceiro pertence ao acceso de entrada desde internet e mapéase, non se axunta. Un deseño que funciona para un deles non di nada sobre os outros dous.

Por que o enderezo externo non é unha segunda interface

A guía de enderezamento é a autoridade sobre como difiren a accesibilidade interna e a externa en Compute Engine. Un IPv4 externo de Compute Engine é unha asignación un a un sobre a única NIC interna da instancia, de modo que o convidado nunca ve unha segunda interface nin un segundo enderezo nesa NIC. O que a VM informa desde dentro segue a ser un enderezo interno primario.

Por iso un cliente privado que encamiña o tráfico polo túnel cara a 10.24.1.7 e un cliente que apunta ao enderezo externo da VM van por camiños distintos. Abrir unha regra de devasa para o enderezo público non cambia nada na ruta da VPC que debe transportar o tráfico do túnel, e editar unha ruta no convidado non move a asignación da plataforma. Escolla o enderezo que nomea a súa ruta e logo revise só os obxectos que a gobernan. Esa disciplina elimina a maior parte das conxecturas deste camiño de resolución de problemas.

Percorra o camiño con gcloud

Comece pola instancia e lea os dous enderezos do mesmo obxecto, para saber de cal fala a súa documentación:

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

Despois confirme o encamiñamento e o permiso dos que depende realmente o camiño:

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

Lea os rangos anunciados e aprendidos do túnel, a ruta da VPC para a subrede da carga de traballo e a regra de devasa que permite a orixe local. Esas tres deben coincidir antes de que un oínte no convidado sexa sequera relevante.

Despois revise o convidado: o servizo escoita no enderezo interno e a súa ruta de retorno volve pasar pola VPC? Un oínte ligado só a un enderezo público fallará esta proba mesmo cando todos os obxectos do lado da nube sexan correctos.

Un prefixo público é outra cuestión

Nada do anterior significa que todo enderezo transportado dentro dunha VPN deba ser RFC1918. Unha rede remota pode numerarse lexitimamente desde o espazo público, sempre que a plataforma admita o encamiñamento e o operador teña a autoridade sobre o enderezo. É unha decisión de deseño normal.

Non é o mesmo que tratar un enderezo NAT externo ordinario como se fose outro enderezo de subrede interna. Un é un prefixo que vostede encamiña; o outro é unha asignación que a plataforma aplica ao acceso de entrada.

O IPv6 externo e os arranxos de enderezos deseñados especialmente teñen a súa propia semántica. Se o seu plan depende dun deles, lea a documentación da plataforma para esa función en lugar de xeneralizar a partir do caso IPv4. A asignación IPv4 é o caso habitual, non o único, e as excepcións teñen cada unha as súas propias regras.

Os rangos solapados son outro problema

Os rangos privados solapados son un motivo real polo que a xente recorre ao enderezo público, e é a panca equivocada. Cambiar o destino ao enderezo NAT da VM non resolve o solapamento; cambia para que enderezo di o paquete que é, sen definir como funciona a ruta de retorno.

Resolva o solapamento a propósito: renumere, use un deseño de tradución compatible ou encamiñe por unha rede onde os prefixos non colidan. Cada unha desas é un deseño cun responsable. O enderezo NAT non é un deseño.

Documente os dous campos por separado

Rexiste o par do túnel e o destino da carga de traballo como dous campos separados do runbook, cada un coa ruta e a regra de devasa que o sosteñen. Un túnel IPsec que se levanta só lle di que as partes están de acordo; non di nada sobre en que enderezo é accesible a carga de traballo nin sobre se a súa ruta privada está completa.

Verifique cun cliente real ao outro lado: resolva o nome, confirme que devolve o enderezo interno, conéctese e comprobe o tráfico de retorno. A documentación de enderezos IP de Compute Engine é a referencia para a distinción entre interno e externo usada arriba.