Per què net.ipv4.conf.default.forwarding deixa tun0 tranquil

Heu definit net.ipv4.conf.default.forwarding=1, heu reiniciat la VPN i el túnel continua descartant paquets que la passarel·la hauria d'encaminar. El paràmetre sembla correcte al fitxer, i la interfície encara informa que el reenviament està desactivat. No s'ha trencat res: heu canviat el valor que hereten les interfícies futures, no el que fa servir el túnel viu.

Repasseu-ho a l'amfitrió que posseeix el túnel, al namespace de xarxa on el túnel existeix realment. Un contenidor o un namespace de xarxa pot tenir la interfície mentre l'amfitrió mostra xifres diferents.

Llegiu els tres valors junts

Comenceu comparant l'interruptor global de la passarel·la, la plantilla per a les interfícies noves i la interfície que us interessa. Substituïu tun0 per la interfície d'entrada real, i llegiu també la interfície de retorn, perquè el reenviament s'avalua al punt on arriba el paquet.

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

Un resultat habitual és ip_forward = 0, default.forwarding = 1 i tun0.forwarding = 0. Els dos primers no coincideixen sobre el paper de l'amfitrió, i el tercer mostra què fa realment la interfície. Aquesta combinació encaixa amb un amfitrió que mai no s'ha configurat com a encaminador, sinó que només ha rebut un valor de plantilla. Les tres xifres no es contradiuen; responen a tres preguntes diferents. Escriure el valor de la plantilla tampoc no decideix el paper de l'amfitrió.

Per què es mou el control global

net.ipv4.ip_forward és el control global de la passarel·la. Canviar-lo actualitza els paràmetres de reenviament per interfície com a part de la mateixa operació, i per això una sola escriptura pot fer que un túnel existent comenci a reenviar. default.forwarding només sembra les interfícies que s'inicialitzen després, de manera que un túnel que ja existia conserva el valor amb què va néixer.

La documentació del nucli marca ip_forward com a especial per una raó relacionada: canviar-lo reinicia un conjunt d'altres paràmetres IPv4 als valors per defecte d'amfitrió o d'encaminador. Això el converteix en una eina contundent. Definir-lo una vegada com a part de l'establiment del paper de passarel·la està bé; commutar-lo repetidament com a truc de depuració pot reescriure en silenci una configuració que us va costar encertar.

Els valors per interfície també existeixen per una raó. Una passarel·la gestionada deliberadament pot mantenir el reenviament desactivat en una interfície que no hauria d'encaminar mai, fins i tot mentre l'amfitrió reenvia en un altre lloc. Per això importa llegir la interfície viva i per això el valor global sol no és tota la resposta. Llegiu aquesta excepció com una decisió deliberada i anoteu per què aquella interfície és diferent. Si no, el proper enginyer la "repararà" molt amablement.

Feu el paràmetre permanent al lloc correcte

Un sysctl -w puntual que funcioni demostra que el nucli accepta el valor. No sobreviu a un reinici, ni sobreviu a un gestor de xarxa que torni a aplicar la seva pròpia idea de la configuració de la interfície en reconnectar. Poseu el paper de passarel·la al fitxer de configuració de sysctl o al gestor de xarxa que posseeix l'amfitrió, i després reinicieu el servei que l'aplica.

L'ordre importa amb els túnels. Si el gestor crea la interfície en arrencar i aplica el reenviament després, la interfície pot heretar el valor per defecte antic. Reiniciar un servei que recrea el túnel també és un esdeveniment de creació, i és fàcil de passar per alt quan la unitat sembla sana. Reviseu la seqüència, no només el contingut final del fitxer.

Torneu a llegir els mateixos tres valors després que la VPN es reconnecti i una altra vegada després d'un reinici. Un túnel acabat de crear és una interfície nova, i una interfície nova pren el valor per defecte vigent en el moment de la creació. Si les xifres canvien entre aquests esdeveniments, la configuració l'aplica alguna cosa que encara no heu identificat.

No ho repareu amb l'eina equivocada

Quan el reenviament semblava trencat, la temptació és buidar el tallafoc o afegir-hi emmascarament. Cap de les dues coses no adreça l'interruptor de reenviament. L'estat de reenviament, el permís per reenviar, una ruta per a la destinació i un camí de retorn són quatre requisits separats, i només el primer és el sysctl.

Proveu també amb el flux correcte. Una petició feta a la mateixa passarel·la no exercita gens el reenviament; és trànsit generat localment. La pregunta és si un paquet que arriba d'un client VPN o d'un amfitrió de la LAN s'accepta i s'encamina més enllà, així que la prova ha d'originar-se darrere de la passarel·la.

Mantingueu el cas IPv6 a part

Aquí tot és IPv4. El reenviament IPv6, els anuncis de router i el comportament d'accept_ra tenen els seus propis controls, i copiar un camí ipv4 en un paràmetre ipv6 produeix un fitxer que sembla plausible i no fa res d'útil. Una passarel·la de doble pila necessita tots dos conjunts configurats deliberadament.

Una última comprovació: després que els valors coincideixin, confirmeu que la ruta del túnel se selecciona per a la destinació i que el camí de resposta existeix. El reenviament activat en una interfície sense ruta continua sent un forat negre, i aquesta fallada es veu igual des del costat del client.