Habilitar el reenvío de IP en una puerta de enlace GCE VPN existente

La VM se creó sin reenvío de IP, ya ejecuta el software VPN y el instinto es reconstruirla desde la plantilla con el flag activado. Esa reconstrucción es innecesaria. Compute Engine expone canIpForward como una propiedad actualizable, y la ruta de actualización documentada la aplica con un refresh en lugar de un reinicio. Lo que el flag controla en realidad es estrecho: sin él, la plataforma descarta los paquetes que llegan a la instancia pero no están dirigidos a la dirección propia de la instancia. Una puerta de enlace que reenvía el tráfico de otras máquinas hace exactamente eso, así que el flag tiene que estar activado. Todo lo demás es configuración del huésped y encaminamiento, que el flag no toca.

Qué permite el flag y qué no

Con el reenvío desactivado, la plataforma trata la instancia como un extremo. Los paquetes cuyo destino es la dirección propia de la instancia se entregan; los paquetes que la instancia debe reenviar en nombre de otro, no.

Con el reenvío activado, la instancia puede actuar como siguiente salto de una ruta VPC, que es el papel que necesita un dispositivo VPN. El flag no dice nada sobre firewalls, encaminamiento del huésped, configuración del túnel ni rutas de retorno, y un valor true en una puerta de enlace rota sigue siendo una puerta de enlace rota.

Leer la propiedad actual

Inspecciona la configuración antes de cambiar nada, con un describe de solo lectura contra la instancia, el proyecto y la zona previstos:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Un valor false solo importa si esta VM debe ser un siguiente salto. Si lo es, el resto del camino todavía hay que comprobarlo por separado, porque la propiedad es una línea en una cadena más larga.

Actualizar la instancia existente

El procedimiento de actualización de propiedades de instancia de Google exporta el recurso actual, modifica la propiedad y envía el resultado. Ese es un flujo de trabajo distinto del flag --can-ip-forward del momento de creación, y es el que funciona en una VM en marcha.

Exporta primero la definición a un archivo local y conserva una copia sin cambios para comparar:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

En ese archivo exportado, establece la propiedad y no cambies nada más:

canIpForward: true

Conserva todo el recurso, incluida su huella. Sustituir el archivo por un documento YAML de una línea, o agrupar ediciones no relacionadas de tipo de máquina, disco o interfaz en el mismo envío, es como un cambio de propiedad se convierte en una caída.

Pide al mecanismo de actualización que valide el archivo e informe qué requeriría, antes de que se permita cualquier cambio efectivo:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Esa ejecución de validación no habilita el reenvío. Lee la respuesta en busca de propiedades no válidas y de la acción que dice que hace falta. Para este cambio aislado, la acción documentada es REFRESH. Si el resultado pide un reinicio, el archivo contiene más que la propiedad que querías cambiar, así que inspecciónalo en lugar de conceder el reinicio.

Aplica el archivo revisado con el límite de refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Comprueba que la operación se completó y ejecuta de nuevo el comando describe. Si la huella ya no coincide, alguien más cambió la instancia mientras editabas, así que exporta una copia nueva y revisa el cambio otra vez en lugar de forzar tu archivo obsoleto.

El huésped todavía tiene que encaminar el paquete

El permiso en la nube no convierte el dispositivo en un router. Confirma que una ruta VPC selecciona esta VM como siguiente salto para el prefijo de destino, y que el huésped encamina entre el túnel y la interfaz correcta con su propia política de reenvío activada.

La política del firewall tiene que permitir el flujo interno además del receptor externo. Abrir solo el puerto VPN describe el transporte cifrado y no dice nada sobre el intercambio de la aplicación dentro de él.

Por último, el destino necesita una ruta de retorno hacia el grupo de clientes, o el diseño tiene que traducir las fuentes a propósito. Si el destino ve tráfico traducido, comprueba la fuente traducida; si el diseño conserva el grupo, comprueba ese grupo en la ruta de retorno y en las reglas de acceso. Añadir NAT antes de decidir qué diseño quieres oculta una ruta que falta y cambia la política que ve el destino.

En una puerta de enlace Linux, el reenvío del núcleo forma parte de la configuración del huésped. Un dispositivo pfSense tiene su propio equivalente, y copiar en él un comando sysctl de Linux no es el paso correspondiente.

Verificar desde el cliente que necesita acceso

Prueba desde un cliente VPN hacia un servicio de destino, no desde la propia puerta de enlace. Una conexión iniciada en la puerta de enlace usa una fuente distinta y nunca ejercita las reglas de reenvío que acabas de habilitar.

Registra la propiedad en lo que gestione el dispositivo. Una VM corregida a mano funciona hasta que su siguiente sustitución reintroduce en silencio la configuración original, y ese fallo parecerá una regresión del software VPN.

Orden de trabajo: lee la propiedad, exporta y edita una línea, valida con NO_EFFECT, aplica con REFRESH, confirma que el huésped reenvía y luego prueba desde un cliente.