Lat ein ip-regel overleve ei ny tilkoping med systemd-networkd

Legg til ein policyregel med ip rule, og han verkar til lenkja forsvinn; på det tidspunktet er han rett og slett borte. Ingenting feila med lyd: kjernetilstanden endra seg, og ingen konfigurasjonseigar visste at regelen skulle finnast. Det er heile skilnaden mellom ein regel som overlever og ein som ikkje gjer det. På ein vert med systemd-networkd er løysinga å gi regelen ein eigar i staden for å køyre kommandoen på nytt etter kvar ny tilkopling.

Ein regel finst berre dersom nokon eig han

Rutingpolicyen til kjernen er tilstand, ikkje konfigurasjon. Han lever i det køyrande systemet, og alt som riv ned grensesnittet han er avhengig av, kan ta han med seg. Ein skalkommando endrar den tilstanden og lèt ikkje etter seg noko registrering av intensjonen.

Nettverkshandsamarar arbeider motsett: dei les konfigurasjon, brukar han og brukar han på nytt når ei lenkjehending gjer den førre tilstanden ugyldig. Ein regel som er deklarert i konfigurasjonen deira, blir oppretta på nytt, medan ein regel som er lagd til ved sida av, er eit framand objekt utan eigar.

Den skilnaden har eit namn i networkd, og han er verd å lese før du aktiverer noko. Framande reglar blir fjerna som standard i nyare versjonar, noko som overraskar dei som venta at dei manuelle oppføringane skulle bli verande.

Les versjonen før du stolar på ei innstilling

Eigaråtferda blir styrt av ei innstilling i networkd.conf, og den innstillinga finst ikkje i eldre systemd-utgåver. Sjekk den installerte versjonen før du designar rundt han, fordi ein eldre vert oppfører seg annleis enn dokumentasjonen du les.

To verdiar tel. Den eine avgjer om reglar som ikkje er deklarerte i networkd-konfigurasjonen blir fjerna, og den andre gjer det same for ruter. Begge handlar om eigarskap og ikkje om innhaldet i policyen, og begge vel som standard den strengare åtferda i gjeldande utgåver. Slår du dei av globalt, held du kvar framand regel i live, noko som er eit langt vidare vedtak enn å deklarere éin ønskt VPN-policy.

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

Den grep-en fortel deg kva som er sett lokalt og kva leverandøren sin standard er. Fråvær er også informasjon, fordi det betyr at den kompilerte standarden gjeld. Skriv standarden i notata dine, så den neste personen ikkje må oppdage han på nytt.

Deklarer regelen og tabellen han peikar på

Ein regel i ei .network-fil namngir ein tabell, og det er alt eit namn gjer. Han opprettar ikkje rutene i den tabellen og sjekkar ikkje om dei gir meining. Deklarerer du regelen utan rutene, får du ein policy som matchar trafikk og deretter slepp han.

Deklarer rutene i same fil, med nåbare neste hopp og rett tabell. Hald prioriteten i den deklarerte regelen, slik at han landar der du ventar i den ordna lista. Ein regel som når feil tabell tidlegare enn tiltenkt, endrar meir trafikk enn tenesta du ville reparere. Les fragmentet nedanfor som ei form og ikkje som ei fullstendig fil, fordi grensesnitteigarskap og resten av sambandet framleis må vere til stades.

[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

Last deretter inn på nytt og les kjernetilstanden i staden for fila. Ein konfigurasjon som vart parsa reint, kan likevel gi ein regel du ikkje hadde tenkt deg, og dei to visingane stemmer berre når deklarasjonen var komplett.

Vel éin eigar for grensesnittet

To handsamarar på éin tunnel gir ein kamp som ser ut som ein feil i begge. Å importere eit eksisterande wg-quick-oppsett i networkd er ein migrasjon og ikkje eit tillegg, og køyrer begge, blir grensesnittet og reglane liggjande under to eigarar.

Gjer migrasjonen i eitt slag: stopp den gamle eininga, deaktiver henne, deklarer grensesnittet og rutene i networkd, og last deretter inn på nytt. Kontroller at den gamle eininga ikkje kan kome tilbake ved oppstart. Ei attverande eining som blir aktivert på nytt etter omstart, overstyrer tilstanden du nettopp deklarerte. Hald den gamle konfigurasjonsfila til den nye har overlevd ei ny tilkopling, og pensjoner henne deretter.

Eigarskap av merket fortener same omsut: dersom ein regel matchar eit brannmurmerke, må noko setje det merket. Ein regel som viser til eit merke ingen set, er daud konfigurasjon som ser medviten ut.

Øv på livssyklushendingane

Konfigurasjon er berre så god som åtferda gjennom hendingar. Ta lenkja ned, opp att, start tenesta på nytt og forny adressa. Etter kvar av dei, les regellista og innhaldet i tabellen.

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

Det tiltenkte resultatet er den same eigde policyen oppretta på nytt og utdatert tilstand pensjonert, noko som er meir haldbart enn å leggje til ein skalregel på nytt etter kvar ny tilkopling. Hald éi linje i endringsloggen som namngir fila som eig regelen og versjonen som støttar han. Då kan den neste ingeniøren finne policyen utan å leite i ein skalhistorikk. Ein regel ingen eig, er ein regel som går tapt igjen.