Por que net.ipv4.conf.default.forwarding deixa tun0 tranquilo

Configurou net.ipv4.conf.default.forwarding=1, reiniciou a VPN e o túnel segue descartando paquetes que a pasarela debería encamiñar. O axuste parece correcto no ficheiro, e a interface segue informando de que o reenvío está desactivado. Nada está roto: cambiou o valor que herdan as interfaces futuras, non o que usa o túnel activo.

Repase isto no servidor que posúe o túnel, no namespace de rede onde o túnel existe realmente. Un contedor ou un namespace de rede pode ter a interface mentres o servidor mostra cifras distintas.

Lea os tres valores xuntos

Comece comparando o interruptor de toda a pasarela, o modelo para as interfaces novas e a interface que lle importa. Substitua tun0 pola interface de entrada real, e lea tamén a interface de retorno, porque o reenvío avalíase no punto onde chega o paquete.

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

Un resultado habitual é ip_forward = 0, default.forwarding = 1 e tun0.forwarding = 0. Os dous primeiros non coinciden sobre o papel do servidor, e o terceiro mostra que fai realmente a interface. Esa combinación encaixa cun servidor que nunca se configurou como router, só recibiu un valor de modelo. As tres cifras non se contradín; responden a tres preguntas distintas. Escribir o valor do modelo tampouco decide o papel do servidor.

Por que se move o interruptor global

net.ipv4.ip_forward é o control de toda a pasarela. Cambialo actualiza os axustes de reenvío por interface como parte da mesma operación, por iso unha soa escritura pode facer que un túnel existente comece a reenviar. default.forwarding só sementa as interfaces que se inicializan despois, así que un túnel que xa existía conserva o valor co que naceu.

A documentación do núcleo marca ip_forward como especial por unha razón relacionada: cambialo reinicia un conxunto doutros parámetros IPv4 aos valores por defecto de servidor ou router. Iso convérteo nunha ferramenta contundente. Defínilo unha vez como parte do establecemento do papel de pasarela está ben; conmutalo repetidamente como truco de depuración pode reescribir en silencio unha configuración que lle custou acertar.

Os valores por interface tamén existen por unha razón. Unha pasarela xestionada a propósito pode manter o reenvío desactivado nunha interface que nunca debería encamiñar, mesmo mentres o servidor reenvía noutro sitio. Por iso importa ler a interface activa e por iso o valor global por si só non é toda a resposta. Lea esa excepción como unha decisión deliberada e anote por que esa interface é distinta. Se non, o seguinte enxeñeiro "arranxaraa" moi amablemente.

Faga o axuste permanente no lugar correcto

Un sysctl -w puntual que funcione demostra que o núcleo acepta o valor. Non sobrevive a un reinicio, nin sobrevive a un xestor de rede que volva aplicar a súa propia idea da configuración da interface ao reconectar. Poña o papel de pasarela no ficheiro de configuración de sysctl ou no xestor de rede que posúe o servidor, e despois reinicie o servizo que o aplica.

A orde importa cos túneles. Se o xestor crea a interface ao arrincar e aplica o reenvío despois, a interface pode herdar o valor por defecto antigo. Reiniciar un servizo que recrea o túnel tamén é un evento de creación, e é fácil pasalo por alto cando a unidade parece sa. Revise a secuencia, non só o contido final do ficheiro.

Volve ler os mesmos tres valores despois de que a VPN se reconecte e outra vez despois dun reinicio. Un túnel acabado de crear é unha interface nova, e unha interface nova toma o valor por defecto vixente no momento da creación. Se as cifras cambian entre eses eventos, a configuración estáa aplicando algo que aínda non identificou.

Non o repare coa ferramenta equivocada

Cando o reenvío parecía roto, a tentación é baleirar a devasa ou engadir masquerading. Ningunha das dúas atende ao interruptor de reenvío. O estado de reenvío, o permiso para reenviar, unha ruta para o destino e un camiño de retorno son catro requisitos separados, e só o primeiro é o sysctl.

Probe tamén co fluxo correcto. Unha petición feita na propia pasarela non exercita o reenvío en absoluto; é tráfico xerado localmente. A pregunta é se un paquete que chega dun cliente VPN ou dun servidor da LAN se acepta e se encamiña cara adiante, así que a proba ten que orixinarse detrás da pasarela.

Manteña o caso IPv6 aparte

Aquí todo é IPv4. O reenvío IPv6, os anuncios de router e o comportamento de accept_ra teñen os seus propios controis, e copiar unha ruta ipv4 nun axuste ipv6 produce un ficheiro que parece plausible e non fai nada útil. Unha pasarela de dobre pila necesita ambos os dous conxuntos configurados a propósito.

Unha última comprobación: despois de que os valores coincidan, confirme que a ruta do túnel se selecciona para o destino e que o camiño de resposta existe. O reenvío activado nunha interface sen ruta segue sendo un burato negro, e ese fallo vese igual desde o lado do cliente.