Feu que el reenviament IPv4 es mantingui després de reiniciar una passarel·la VPN

Fer ping a la passarel·la funciona i arribar a qualsevol cosa del darrere no, i aquesta és la forma d’un problema de reenviament, no d’un problema de túnel. El lliurament local a la passarel·la demostra que el túnel s’ha aixecat i que l’assignació d’adreces ha funcionat; no diu res sobre si el nucli farà passar un paquet d’una interfície a una altra. Abans de tocar cap sysctl, confirmeu que la màquina ha d’encaminar aquest trànsit i localitzeu el context de xarxa que conté la interfície orientada als clients. Després llegiu el valor allà, no on la darrera guia que vau llegir va mirar per casualitat.

Arribar a la passarel·la no és el mateix que reenviar

Dins del nucli es prenen dues decisions separades. El lliurament a una adreça local acaba el viatge del paquet; el reenviament el torna a enviar per una altra interfície, i aquesta segona decisió es governa per espai de noms de xarxa. Una passarel·la pot ser perfectament accessible amb el reenviament desactivat, i des d’una ordre ping les dues falles semblen idèntiques.

Anoteu per quina interfície arriba el paquet del client i per quina surt el camí següent. Totes dues pertanyen a un sol espai de noms, i aquest espai de noms té el paràmetre que importa.

Llegiu el valor on els paquets són realment

En una passarel·la que encamina a l’espai de noms de l’amfitrió, una sola ordre respon la pregunta: sysctl net.ipv4.ip_forward. Quan el camí d’entrada i el següent viuen en un espai de noms amb nom, pregunteu a aquest espai de noms: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. El valor de l’amfitrió no substitueix el valor de l’espai de noms, i un u a l’amfitrió no és prova de res.

No tots els contextos d’encaminament tenen una etiqueta que pugueu passar a ip netns. Els entorns d’execució de contenidors i els serveis creen espais de noms que mai no es registren amb un nom amigable, i per a aquests feu servir les eines d’inspecció de l’entorn. Substituïu vpn-gw pel nom real, o pel mecanisme de l’entorn que arriba al mateix context, i deixeu de conjecturar a nivell d’amfitrió.

Doneu al paràmetre un sol propietari

En una passarel·la amfitriona convencional amb systemd, la forma duradora és un fitxer drop-in amb un nom triat per l’administrador, com /etc/sysctl.d/60-vpn-forwarding.conf, que contingui net.ipv4.ip_forward = 1. Escriviu el fitxer i després carregueu aquest fitxer concret perquè l’estat viu també canviï: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, seguit d’una lectura de retorn. El nom del fitxer és un exemple i no un camí VPN reservat, i el número inicial importa perquè els fitxers ordenats més tard guanyen.

La precedència és on la persistència es trenca en silenci. Reviseu tant el carregador de la distribució com el vostre drop-in, perquè procps sysctl --system també llegeix /etc/sysctl.conf al final, mentre que l’ordre sysctl.d de systemd és una seqüència completament diferent. Una assignació posterior pot tornar a posar la mateixa clau, deixant el vostre fitxer correcte i el valor efectiu incorrecte. No sobreescriviu un fitxer d’administrador existent per guanyar aquesta discussió; trobeu el propietari i canvieu-lo allà.

Un espai de noms creat després de l’arrencada no el governa cap drop-in de l’amfitrió. El seu paràmetre pertany a allò que el crea, sigui l’entorn d’execució de contenidors o la unitat de proveïment de l’espai de noms. Concedir a un contenidor amplis privilegis d’amfitrió per esquivar la pregunta és un mal negoci comparat amb dedicar deu minuts a identificar el propietari correcte.

Saber què costa l’interruptor abans de canviar-lo

ip_forward no és un booleà inofensiu. La documentació del nucli assenyala que canviar-lo reinicia diversos altres paràmetres IPv4 als seus valors per defecte d’amfitrió o d’encaminador, de manera que un canvi de diagnòstic pot descartar ajustos fets en un altre lloc i no esmentar-ho mai. Tracteu-lo com un canvi de configuració amb efectes secundaris i no com una prova que es pugui executar sense miraments.

Això també descarta activar-lo i desactivar-lo cada cop que un client no pot arribar a un amfitrió. Si el valor ja és u, la falla és en un altre punt del camí, i reescriure la mateixa clau per tercera vegada no el mourà.

Demostreu la persistència i després proveu la resta del camí

Llegiu el valor de retorn en quatre moments: just després del canvi, després que aparegui la interfície VPN, després d’una reconnexió i després d’un reinici planificat. Un valor que reverteix en qualsevol d’aquests punts té un segon propietari, i una altra escriptura puntual només ho amaga fins al proper reinici.

El reenviament activat encara deixa tres coses per verificar. El client necessita una ruta fins a la destinació, la passarel·la necessita una ruta següent més permís per fer-la servir, i la destinació necessita un camí de retorn cap a l’adreça del túnel del client. Una LAN privada encaminada no necessita NAT automàticament, així que no afegiu masquerading abans de saber quina de les tres coses falta, i proveu-ho des del client previst i no des de la mateixa passarel·la, perquè una petició originada a la passarel·la no toca mai el camí de reenviament que acabeu d’activar. IPv6 té la seva pròpia política de reenviament i encaminament, així que una prova IPv4 que funcioni no en diu res.

Manteniu el camí del drop-in, el propietari de l’espai de noms i l’ordre de lectura de retorn junts al runbook. Qui ho agafi després ha de poder llegir el valor, veure qui en és propietari i decidir en un minut si el problema és la persistència o la resta del camí.