Por qué net.ipv4.conf.default.forwarding deja tun0 en paz

Configuró net.ipv4.conf.default.forwarding=1, reinició la VPN y el túnel sigue descartando paquetes que la puerta de enlace debería enrutar. El ajuste parece correcto en el archivo, y la interfaz sigue informando que el reenvío está desactivado. Nada está roto: cambió el valor que heredan las interfaces futuras, no el que usa el túnel activo.

Repase esto en el host que posee el túnel, en el namespace de red donde el túnel existe realmente. Un contenedor o un namespace de red puede tener la interfaz mientras el host muestra cifras distintas.

Lea los tres valores juntos

Empiece comparando el interruptor de toda la puerta de enlace, la plantilla para las interfaces nuevas y la interfaz que le importa. Sustituya tun0 por la interfaz de entrada real, y lea también la interfaz de retorno, porque el reenvío se evalúa en el punto donde llega el paquete.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Un resultado habitual es ip_forward = 0, default.forwarding = 1 y tun0.forwarding = 0. Los dos primeros no coinciden sobre el papel del host, y el tercero muestra qué hace realmente la interfaz. Esa combinación encaja con un host que nunca se configuró como router, solo recibió un valor de plantilla. Las tres cifras no se contradicen; responden a tres preguntas distintas. Escribir el valor de la plantilla tampoco decide el papel del host.

Por qué se mueve el interruptor global

net.ipv4.ip_forward es el control de toda la puerta de enlace. Cambiarlo actualiza los ajustes de reenvío por interfaz como parte de la misma operación, por eso una sola escritura puede hacer que un túnel existente empiece a reenviar. default.forwarding solo siembra las interfaces que se inicializan después, así que un túnel que ya existía conserva el valor con el que nació.

La documentación del núcleo marca ip_forward como especial por una razón relacionada: cambiarlo reinicia un conjunto de otros parámetros IPv4 a los valores por defecto de host o router. Eso lo convierte en una herramienta contundente. Definirlo una vez como parte del establecimiento del papel de puerta de enlace está bien; conmutarlo repetidamente como truco de depuración puede reescribir en silencio una configuración que le costó acertar.

Los valores por interfaz también existen por una razón. Una puerta de enlace gestionada a propósito puede mantener el reenvío desactivado en una interfaz que nunca debería enrutar, incluso mientras el host reenvía en otro sitio. Por eso importa leer la interfaz activa y por eso el valor global por sí solo no es toda la respuesta. Lea esa excepción como una decisión deliberada y anote por qué esa interfaz es distinta. Si no, el siguiente ingeniero la "arreglará" muy amablemente.

Haga el ajuste permanente en el lugar correcto

Un sysctl -w puntual que funcione demuestra que el núcleo acepta el valor. No sobrevive a un reinicio, ni sobrevive a un gestor de red que vuelva a aplicar su propia idea de la configuración de la interfaz al reconectar. Ponga el papel de puerta de enlace en el archivo de configuración de sysctl o en el gestor de red que posee el host, y luego reinicie el servicio que lo aplica.

El orden importa con los túneles. Si el gestor crea la interfaz al arrancar y aplica el reenvío después, la interfaz puede heredar el valor por defecto antiguo. Reiniciar un servicio que recrea el túnel también es un evento de creación, y es fácil pasarlo por alto cuando la unidad parece sana. Revise la secuencia, no solo el contenido final del archivo.

Vuelva a leer los mismos tres valores después de que la VPN se reconecte y otra vez después de un reinicio. Un túnel recién creado es una interfaz nueva, y una interfaz nueva toma el valor por defecto vigente en el momento de la creación. Si las cifras cambian entre esos eventos, la configuración la está aplicando algo que aún no ha identificado.

No lo repare con la herramienta equivocada

Cuando el reenvío parecía roto, la tentación es vaciar el cortafuegos o añadir masquerading. Ninguna de las dos cosas atiende al interruptor de reenvío. El estado de reenvío, el permiso para reenviar, una ruta para el destino y un camino de retorno son cuatro requisitos separados, y solo el primero es el sysctl.

Pruebe también con el flujo correcto. Una petición hecha en la propia puerta de enlace no ejercita el reenvío en absoluto; es tráfico generado localmente. La pregunta es si un paquete que llega de un cliente VPN o de un host de la LAN se acepta y se enruta hacia delante, así que la prueba tiene que originarse detrás de la puerta de enlace.

Mantenga el caso IPv6 aparte

Aquí todo es IPv4. El reenvío IPv6, los anuncios de router y el comportamiento de accept_ra tienen sus propios controles, y copiar una ruta ipv4 en un ajuste ipv6 produce un archivo que parece plausible y no hace nada útil. Una puerta de enlace de doble pila necesita ambos conjuntos configurados a propósito.

Una última comprobación: después de que los valores coincidan, confirme que la ruta del túnel se selecciona para el destino y que el camino de respuesta existe. El reenvío activado en una interfaz sin ruta sigue siendo un agujero negro, y ese fallo se ve igual desde el lado del cliente.