Haga que el reenvío IPv4 persista tras reiniciar una puerta de enlace VPN

Hacer ping a la puerta de enlace funciona y llegar a cualquier cosa detrás de ella no, y esa es la forma de un problema de reenvío y no de un problema de túnel. La entrega local a la puerta de enlace demuestra que el túnel se levantó y que la asignación de direcciones funcionó; no dice nada sobre si el núcleo dejará pasar un paquete de una interfaz a otra. Antes de tocar cualquier sysctl, confirme que la máquina debe enrutar este tráfico y localice el contexto de red que contiene la interfaz orientada al cliente. Después lea el valor allí, no donde casualmente miró la última guía que leyó.

Llegar a la puerta de enlace no es lo mismo que reenviar

Dentro del núcleo ocurren dos decisiones separadas. La entrega a una dirección local termina el viaje del paquete; el reenvío lo vuelve a enviar por otra interfaz, y esa segunda decisión se gobierna por espacio de nombres de red. Una puerta de enlace puede ser perfectamente accesible mientras el reenvío está desactivado, y desde un indicador de ping los dos fallos parecen idénticos.

Anote por qué interfaz llega el paquete del cliente y por qué interfaz sale el camino siguiente. Ambas pertenecen a un solo espacio de nombres, y ese espacio de nombres contiene el ajuste que importa.

Lea el valor donde los paquetes están realmente

En una puerta de enlace que enruta en el espacio de nombres del host, un solo comando responde la pregunta: sysctl net.ipv4.ip_forward. Cuando el camino de entrada y el siguiente viven en un espacio de nombres con nombre, pregúntele a ese espacio de nombres: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. El valor del host no sustituye al valor del espacio de nombres, y un uno en el host no es prueba de nada.

No todos los contextos de enrutamiento tienen una etiqueta que pueda pasar a ip netns. Los entornos de ejecución de contenedores y los servicios crean espacios de nombres que nunca se registran con un nombre amigable, y para esos use las herramientas de inspección del entorno. Sustituya vpn-gw por el nombre real, o por el mecanismo del entorno que alcanza el mismo contexto, y deje de adivinar en el nivel del host.

Dé al ajuste un solo propietario

En una puerta de enlace anfitriona convencional con systemd, la forma duradera es un archivo drop-in con un nombre elegido por el administrador, como /etc/sysctl.d/60-vpn-forwarding.conf, que contenga net.ipv4.ip_forward = 1. Escriba el archivo y luego cargue ese archivo concreto para que el estado vivo también cambie: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, seguido de una lectura de retorno. El nombre del archivo es un ejemplo y no una ruta VPN reservada, y el número inicial importa porque los archivos ordenados más tarde ganan.

La precedencia es donde la persistencia se rompe en silencio. Revise tanto el cargador de la distribución como su propio drop-in, porque procps sysctl --system también lee /etc/sysctl.conf al final, mientras que el orden sysctl.d de systemd es una secuencia completamente distinta. Una asignación posterior puede devolver la misma clave de inmediato, dejando su archivo correcto y el valor efectivo incorrecto. No sobrescriba un archivo de administrador existente para ganar esa discusión; encuentre al propietario y cámbielo allí.

Un espacio de nombres creado después del arranque no se rige en absoluto por un drop-in del host. Su ajuste pertenece a lo que lo crea, ya sea el entorno de ejecución de contenedores o la unidad de aprovisionamiento del espacio de nombres. Conceder a un contenedor amplios privilegios de host para eludir la pregunta es un mal negocio comparado con dedicar diez minutos a identificar al propietario correcto.

Sepa cuánto cuesta el interruptor antes de accionarlo

ip_forward no es un booleano inofensivo. La documentación del núcleo señala que cambiarlo restablece varios otros parámetros IPv4 a sus valores predeterminados de host o de enrutador, así que un cambio de diagnóstico puede descartar ajustes hechos en otro lugar y no mencionarlo nunca. Trátelo como un cambio de configuración con efectos secundarios y no como una sonda que se pueda ejecutar sin cuidado.

Eso también descarta activarlo y desactivarlo cada vez que un cliente no puede llegar a un host. Si el valor ya es uno, la falla está en otro punto del camino, y reescribir la misma clave por tercera vez no lo moverá.

Demuestre la persistencia y luego pruebe el resto del camino

Lea el valor de vuelta en cuatro momentos: justo después del cambio, después de que aparezca la interfaz VPN, después de una reconexión y después de un reinicio planificado. Un valor que revierte en cualquiera de esos puntos tiene un segundo propietario, y otra escritura puntual solo lo oculta hasta el próximo reinicio.

El reenvío activado todavía deja tres cosas por verificar. El cliente necesita una ruta hasta el destino, la puerta de enlace necesita una ruta siguiente más permiso para usarla, y el destino necesita un camino de retorno hacia la dirección del túnel del cliente. Una LAN privada enrutada no necesita NAT automáticamente, así que no añada masquerading antes de saber cuál de las tres falta, y pruebe desde el cliente previsto y no desde la propia puerta de enlace, porque una petición originada en la puerta de enlace nunca toca el camino de reenvío que acaba de activar. IPv6 tiene su propia política de reenvío y enrutamiento, así que una prueba IPv4 que funcione no dice nada sobre ella.

Mantenga juntos en el runbook la ruta del drop-in, el propietario del espacio de nombres y el comando de lectura de retorno. Quien lo retome después debería poder leer el valor, ver quién lo posee y decidir en un minuto si el problema es la persistencia o el resto del camino.