Far sopravvivere la regola ip a una riconnessione con systemd-networkd

Aggiungi una regola di politica con ip rule e funziona finché il link non sparisce; a quel punto semplicemente non c'è più. Nulla è fallito rumorosamente: lo stato del kernel è cambiato e nessun proprietario della configurazione sapeva che la regola dovesse esistere. È tutta qui la differenza tra una regola che sopravvive e una che non lo fa. Su un host con systemd-networkd la soluzione è dare alla regola un proprietario invece di rieseguire il comando dopo ogni riconnessione.

Una regola esiste solo se qualcuno la possiede

La politica di routing del kernel è stato, non configurazione. Vive nel sistema in esecuzione, e qualunque cosa demolisca l'interfaccia da cui dipende può portarla via con sé. Un comando della shell cambia quello stato e non lascia alcun registro dell'intenzione.

I gestori di rete lavorano al contrario: leggono la configurazione, la applicano e la riapplicano quando un evento del link invalida lo stato precedente. Una regola dichiarata nella loro configurazione viene ricreata, mentre una regola aggiunta accanto a loro è un oggetto estraneo senza proprietario.

Questa distinzione ha un nome in networkd, e vale la pena leggerlo prima di abilitare qualsiasi cosa. Le regole estranee vengono rimosse per impostazione predefinita nelle versioni recenti, il che sorprende chi si aspettava che le proprie voci manuali persistessero.

Leggi la versione prima di fidarti di un'impostazione

Il comportamento di proprietà è controllato da un'impostazione in networkd.conf, e quell'impostazione non esiste nelle versioni precedenti di systemd. Controlla la versione installata prima di progettare intorno a essa, perché un host più vecchio si comporta diversamente dalla documentazione che stai leggendo.

Due valori contano. Uno decide se vengono rimosse le regole non dichiarate nella configurazione di networkd, e l'altro fa lo stesso per le rotte. Entrambi riguardano la proprietà e non il contenuto della politica, ed entrambi scelgono per impostazione predefinita il comportamento più severo nelle versioni attuali. Disattivarli globalmente mantiene viva ogni regola estranea, il che è una decisione molto più ampia che dichiarare una politica VPN voluta.

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

Quel grep ti dice cosa è impostato localmente e qual è il valore predefinito del fornitore. Anche l'assenza è informazione, perché significa che vale il valore compilato. Annota il valore predefinito così la persona successiva non deve riscoprirlo.

Dichiara la regola e la tabella a cui punta

Una regola in un file .network nomina una tabella, e questo è tutto ciò che fa un nome. Non crea le rotte dentro quella tabella e non verifica che abbiano senso. Dichiarare la regola senza le rotte produce una politica che abbina il traffico e poi lo scarta.

Dichiara le rotte nello stesso file, con salti successivi raggiungibili e la tabella giusta. Mantieni la priorità nella regola dichiarata perché finisca dove ti aspetti nell'elenco ordinato. Una regola che raggiunge la tabella sbagliata prima del previsto cambia più traffico del servizio che volevi riparare. Leggi il frammento qui sotto come una forma e non come un file completo, perché la proprietà dell'interfaccia e il resto della connessione devono ancora essere presenti.

[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

Poi ricarica e rileggi lo stato del kernel invece del file. Una configurazione analizzata in modo pulito può comunque produrre una regola che non volevi, e le due viste concordano solo quando la dichiarazione era completa.

Scegli un solo proprietario per l'interfaccia

Due gestori su un tunnel producono una lite che sembra un difetto in entrambi. Importare una configurazione wg-quick esistente in networkd è una migrazione e non un'aggiunta, e farli girare entrambi lascia l'interfaccia e le sue regole sotto due proprietari.

Fai la migrazione in un solo passaggio: ferma la vecchia unità, disattivala, dichiara l'interfaccia e le sue rotte in networkd, poi ricarica. Verifica che la vecchia unità non possa tornare all'avvio. Un'unità rimasta che si riattiva dopo un riavvio sovrascrive lo stato che hai appena dichiarato. Conserva il vecchio file di configurazione finché il nuovo non ha superato una riconnessione, poi ritiralo.

La proprietà del marchio merita la stessa cura: se una regola corrisponde a un marchio del firewall, qualcosa deve impostare quel marchio. Una regola che fa riferimento a un marchio che nessuno imposta è configurazione morta che sembra deliberata.

Esercita gli eventi del ciclo di vita

La configurazione vale quanto il suo comportamento nel corso degli eventi. Metti giù il link, rialzalo, riavvia il servizio e rinnova l'indirizzo. Dopo ciascuno, leggi l'elenco delle regole e il contenuto della tabella.

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

Il risultato voluto è la stessa politica con proprietario ricreata e lo stato obsoleto ritirato, cosa più duratura che riaggiungere una regola della shell dopo ogni riconnessione. Mantieni una riga nel registro delle modifiche che nomini il file proprietario della regola e la versione che la supporta. Così l'ingegnere successivo può trovare la politica senza frugare in una cronologia della shell. Una regola che nessuno possiede è una regola che andrà persa di nuovo.