Cloud VPN a una VM de GCP: use la IP interna, no la IP de NAT

Cuando una red local llega a una VPC a través de Cloud VPN, el destino de un servicio de Compute Engine suele ser la dirección interna de la VM. La dirección IPv4 externa no es una segunda dirección que pueda sustituirse en la misma ruta privada. La mayor parte de la confusión en este terreno viene de tratar tres direcciones con tres tareas como si fueran intercambiables, así que empiece por nombrar cuál usa un paquete concreto.

Tres direcciones, tres tareas

Nombre las tres antes de depurar cualquiera de ellas, porque la respuesta cambia el objeto que inspeccionará a continuación.

La primera pertenece al túnel. La segunda pertenece al diseño de su ruta y su cortafuegos. La tercera pertenece al acceso de entrada desde internet y se mapea, no se adjunta. Un diseño que funciona para una de ellas no dice nada sobre las otras dos.

Por qué la dirección externa no es una segunda interfaz

La guía de direccionamiento es la autoridad sobre cómo difieren la accesibilidad interna y la externa en Compute Engine. Una IPv4 externa de Compute Engine es una asignación uno a uno sobre la única NIC interna de la instancia, de modo que el invitado nunca ve una segunda interfaz ni una segunda dirección en esa NIC. Lo que la VM informa desde dentro sigue siendo una dirección interna primaria.

Por eso un cliente privado que encamina el tráfico por el túnel hacia 10.24.1.7 y un cliente que apunta a la dirección externa de la VM van por caminos distintos. Abrir una regla de cortafuegos para la dirección pública no cambia nada en la ruta de la VPC que debe transportar el tráfico del túnel, y editar una ruta en el invitado no mueve la asignación de la plataforma. Elija la dirección que nombra su ruta y luego revise solo los objetos que la gobiernan. Esa disciplina elimina la mayor parte de las conjeturas de este camino de resolución de problemas.

Recorra el camino con gcloud

Empiece por la instancia y lea ambas direcciones del mismo objeto, para saber de cuál habla su documentación:

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

Después confirme el enrutamiento y el permiso de los que depende realmente el camino:

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 los rangos anunciados y aprendidos del túnel, la ruta de la VPC para la subred de la carga de trabajo y la regla de cortafuegos que permite el origen local. Esas tres deben coincidir antes de que un oyente en el invitado sea siquiera relevante.

Después revise el invitado: ¿el servicio escucha en la dirección interna y su ruta de retorno vuelve a pasar por la VPC? Un oyente vinculado solo a una dirección pública fallará esta prueba incluso cuando todos los objetos del lado de la nube sean correctos.

Un prefijo público es otra cuestión

Nada de lo anterior significa que toda dirección transportada dentro de una VPN deba ser RFC1918. Una red remota puede numerarse legítimamente desde espacio público, siempre que la plataforma admita el enrutamiento y el operador tenga la autoridad sobre la dirección. Es una decisión de diseño normal.

No es lo mismo que tratar una dirección NAT externa ordinaria como si fuera otra dirección de subred interna. Una es un prefijo que usted encamina; la otra es una asignación que la plataforma aplica al acceso de entrada.

La IPv6 externa y los arreglos de direcciones diseñados especialmente tienen su propia semántica. Si su plan depende de uno de ellos, lea la documentación de la plataforma para esa función en lugar de generalizar a partir del caso IPv4. La asignación IPv4 es el caso habitual, no el único, y las excepciones tienen cada una sus propias reglas.

Los rangos superpuestos son otro problema

Los rangos privados superpuestos son un motivo real por el que la gente recurre a la dirección pública, y es la palanca equivocada. Cambiar el destino a la dirección NAT de la VM no resuelve la superposición; cambia para qué dirección dice el paquete que es, sin definir cómo funciona la ruta de retorno.

Resuelva la superposición a propósito: renumere, use un diseño de traducción compatible o encamine por una red donde los prefijos no colisionen. Cada una de esas es un diseño con un responsable. La dirección NAT no es un diseño.

Documente los dos campos por separado

Registre el par del túnel y el destino de la carga de trabajo como dos campos separados del runbook, cada uno con la ruta y la regla de cortafuegos que lo sostienen. Un túnel IPsec que se levanta solo le dice que las partes están de acuerdo; no dice nada sobre en qué dirección es accesible la carga de trabajo ni sobre si su ruta privada está completa.

Verifique con un cliente real al otro lado: resuelva el nombre, confirme que devuelve la dirección interna, conéctese y compruebe el tráfico de retorno. La documentación de direcciones IP de Compute Engine es la referencia para la distinción entre interno y externo usada arriba.