Feu que la regla ip sobrevisqui a una reconnexió amb systemd-networkd

Afegiu una regla de política amb ip rule i funciona fins que l'enllaç desapareix; en aquell moment simplement ja no hi és. Res no va fallar sorollosament: l'estat del nucli va canviar i cap propietari de configuració sabia que la regla havia d'existir. Aquesta és tota la diferència entre una regla que sobreviu i una que no. En un amfitrió amb systemd-networkd, la solució és donar un propietari a la regla en lloc de tornar a executar l'ordre després de cada reconnexió.

Una regla només existeix si algú la posseeix

La política d'encaminament del nucli és estat, no configuració. Viu al sistema en marxa, i qualsevol cosa que desmunti la interfície de la qual depèn se la pot endur. Una ordre de l'intèrpret canvia aquest estat i no deixa cap registre d'intenció.

Els gestors de xarxa treballen al revés: llegeixen la configuració, l'apliquen i la tornen a aplicar quan un esdeveniment d'enllaç invalida l'estat anterior. Una regla declarada a la seva configuració es torna a crear, mentre que una regla afegida al seu costat és un objecte estrany sense propietari.

Aquesta distinció té un nom a networkd, i val la pena llegir-lo abans d'habilitar res. Les regles estranyes s'eliminen per defecte a les versions recents, cosa que sorprèn qui esperava que les seves entrades manuals persistissin.

Llegiu la versió abans de confiar en un paràmetre

El comportament de propietat es controla amb un paràmetre de networkd.conf, i aquest paràmetre no existeix a les versions antigues de systemd. Comproveu la versió instal·lada abans de dissenyar-hi al voltant, perquè un amfitrió antic es comporta de manera diferent de la documentació que llegiu.

Dos valors importen. Un decideix si s'eliminen les regles no declarades a la configuració de networkd, i l'altre fa el mateix amb les rutes. Tots dos tracten de la propietat i no del contingut de la política, i tots dos per defecte adopten el comportament més estricte a les versions actuals. Desactivar-los globalment manté viva cada regla estranya, cosa que és una decisió molt més àmplia que declarar una política VPN volguda.

systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null

Aquest grep us diu què està definit localment i quin és el valor per defecte del proveïdor. L'absència també és informació, perquè significa que s'aplica el valor compilat. Anoteu el valor per defecte perquè la propera persona no l'hagi de retrobar.

Declareu la regla i la taula a què apunta

Una regla en un fitxer .network anomena una taula, i això és tot el que fa el nom. No crea les rutes dins d'aquella taula ni comprova que tinguin sentit. Declarar la regla sense les rutes produeix una política que fa coincidir el trànsit i després el descarta.

Declareu les rutes al mateix fitxer, amb salts següents abastables i la taula correcta. Manteniu la prioritat a la regla declarada perquè caigui on espereu dins la llista ordenada. Una regla que arriba a la taula equivocada abans del previst canvia més trànsit que el servei que volíeu arreglar. Llegiu el fragment de sota com una forma i no com un fitxer complet, perquè la propietat de la interfície i la resta de la connexió encara hi han de ser.

[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000

[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100

A continuació recarregueu i torneu a llegir l'estat del nucli, no el fitxer. Una configuració que s'ha analitzat net encara pot produir una regla que no volíeu, i les dues vistes només coincideixen quan la declaració era completa.

Trieu un sol propietari per a la interfície

Dos gestors en un túnel produeixen una baralla que sembla un error en tots dos. Importar una configuració wg-quick existent a networkd és una migració i no una addició, i executar tots dos deixa la interfície i les seves regles sota dos propietaris.

Feu la migració d'una passada: atureu la unitat antiga, desactiveu-la, declareu la interfície i les seves rutes a networkd i recarregueu. Comproveu que la unitat antiga no pugui tornar a l'arrencada. Una unitat romanent que es reactiva després d'un reinici sobreescriu l'estat que acabeu de declarar. Conserveu el fitxer de configuració antic fins que el nou hagi sobreviscut a una reconnexió, i llavors jubileu-lo.

La propietat de la marca mereix la mateixa cura: si una regla coincideix amb una marca del tallafoc, algú ha de posar aquella marca. Una regla que fa referència a una marca que ningú no posa és configuració morta que sembla deliberada.

Assageu els esdeveniments del cicle de vida

La configuració val tant com el seu comportament al llarg dels esdeveniments. Baixeu l'enllaç, pugeu-lo, reinicieu el servei i renoveu l'adreça. Després de cadascun, llegiu la llista de regles i el contingut de la taula.

sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd

El resultat volgut és la mateixa política amb propietari recreada i l'estat obsolet jubilat, cosa més duradora que tornar a afegir una regla d'intèrpret després de cada reconnexió. Manteniu una línia al registre de canvis que anomeni el fitxer propietari de la regla i la versió que la suporta. Llavors el proper enginyer pot trobar la política sense buscar en un historial d'intèrpret. Una regla que ningú no posseeix és una regla que es tornarà a perdre.