Por qué tu VM de GCP no puede responder al pool IPv6 de OpenVPN

Tu cliente VPN IPv6 llega a la carga de trabajo, la carga responde hacia el túnel y la respuesta nunca llega. El instinto es culpar al firewall o al túnel, y normalmente ninguno de los dos tiene la culpa. Una dirección que entrega OpenVPN es una red interna que solo existe dentro del túnel; Google Cloud no tiene ni idea de que fd42:90::/64 debería estar detrás de una VM concreta hasta que se lo digas.

Dos sistemas separados tienen que aprender ese hecho, y solo uno de ellos es OpenVPN. La VPC necesita una ruta antes de poder enviar nada de vuelta, y a la VM se le debe permitir reenviar lo que llega. Si fallas en cualquiera de las dos mitades, el síntoma parece idéntico.

El pool es una red interna, no una subred

OpenVPN puede entregar direcciones IPv6 de un rango que elijas, y ese rango es una ficción con la que coinciden los dos extremos del túnel. No es una subred de Google Cloud, no aparece en la lista de subredes de la VPC y la interfaz de red de la VM no adquiere esas direcciones. Por eso, una carga que responde a un cliente envía un paquete a una dirección que la red considera no enrutable.

Mantén el pool fuera de todos los rangos que la VPC ya use. Mantenlo también fuera de los rangos que hay detrás de tus otros túneles. El solapamiento convierte un fallo limpio de enrutamiento en uno intermitente que solo aparece bajo carga.

El direccionamiento local único como fd42:90::/64 es una opción razonable para esta red interna. El prefijo también recuerda que el diseño es privado por construcción. Nada de un pool ULA lo convierte en una fuente legítima en la internet pública.

Dale a la VPC un destino y un siguiente salto

La respuesta necesita una ruta de VPC cuyo destino sea el pool y cuyo siguiente salto sea la VM de VPN. La documentación actual de rutas estáticas cubre rangos de destino IPv6 e indica qué tipos de siguiente salto son elegibles, así que verifica la forma admitida para tu topología en lugar de copiar un ejemplo IPv4 antiguo.

Una dirección de siguiente salto tiene que ser una que esté asignada realmente a la interfaz cloud de la instancia. La dirección interna del túnel de la VM no es esa dirección. Usarla de todos modos produce una ruta que se instala limpiamente y nunca coincide con un paquete. Lee la lista de interfaces antes de escribir la ruta.

La precedencia de las rutas importa tanto como la entrada en sí. Las rutas de subred son más específicas que las rutas personalizadas que añades, así que un pool recortado de un rango de subred existente perderá contra la ruta de subred, sin importar cómo esté escrita la ruta personalizada. Elige un pool distinto y luego confirma que la ruta muestra la instancia como siguiente salto y el prefijo de destino correcto:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

El reenvío debe habilitarse dos veces

Una ruta entrega el paquete a la instancia. No hace que la instancia esté dispuesta a reenviar algo que no va dirigido a ella, y ese permiso existe en dos capas.

El lado del cloud necesita la capacidad de reenvío de la instancia habilitada, que es el ajuste que permite a una VM recibir tráfico para direcciones que no posee y pasarlo. El lado invitado necesita su propio reenvío IPv6, porque el kernel aplica una decisión aparte después de que llegue el paquete. Ambos deben estar activados antes de que una sola respuesta cruce el túnel.

sysctl -w net.ipv6.conf.all.forwarding=1

Después, las reglas de firewall tienen que admitir el rango de origen interno en ambas direcciones. Google Cloud evalúa el paquete desencapsulado, así que una regla que solo cubre la subred de la VPC descarta el tráfico del pool después de que el túnel ya ha tenido éxito. Añade el pool como rango de origen en la regla de entrada y comprueba que ninguna política de salida personalizada bloquee la respuesta. La regla de permiso implícita cubre el caso por defecto, una regla de salida escrita a mano no.

Dile a OpenVPN quién posee qué

OpenVPN reenvía a un cliente cuando sabe que ese cliente posee el destino. Las direcciones de cliente del pool las gestiona la directiva de servidor que define el pool, pero una subred detrás de un cliente es otra disposición y necesita una entrada de propiedad explícita para ese cliente.

Confundir ambas cosas produce un túnel en el que los pings al servidor funcionan y nada de lo que hay detrás. Decide qué caso estás construyendo y luego escribe la entrada correspondiente en lugar de añadir una segunda línea push y confiar en la suerte.

Mantén la salida a internet fuera de este diseño

El acceso privado y el acceso a internet son planes separados. Un pool ULA puede llegar a las cargas de trabajo de la VPC por el túnel una vez que el enrutamiento y el reenvío coinciden, y ese mismo pool no tiene camino hacia la internet pública a través de la VPC, porque la puerta de enlace del cloud no aceptará una fuente de túnel arbitraria como propia.

Si los clientes también necesitan salida a internet, planifica un diseño de direccionamiento y enrutamiento compatible para ello, mantenlo independiente del pool privado y prueba los dos caminos por separado. Un camino que funciona no dice nada sobre el otro, y un diseño que los confunde falla de una manera que parece un túnel roto.