Lad en ip-regel overleve en genopkobling med systemd-networkd
En ip-regel fra en shell forsvinder ved næste linkhændelse. Deklarér reglen, dens tabel og dens ruter i systemd-networkd, så politikken genskabes.
Tilføj en politikregel med ip rule, og den virker, indtil linket forsvinder; på det tidspunkt er den simpelthen væk. Intet fejlede højlydt: kernetilstanden ændrede sig, og ingen konfigurationsejer vidste, at reglen burde findes. Det er hele forskellen på en regel, der overlever, og en der ikke gør. På en vært med systemd-networkd er løsningen at give reglen en ejer i stedet for at køre kommandoen igen efter hver genopkobling.
En regel findes kun, hvis nogen ejer den
Kernens rutepolitik er tilstand, ikke konfiguration. Den lever i det kørende system, og alt, der river det interface ned, som den afhænger af, kan tage den med. En shellkommando ændrer den tilstand og efterlader ingen registrering af hensigten.
Netværksadministratorer arbejder den anden vej: de læser konfiguration, anvender den og anvender den igen, når en linkhændelse ugyldiggør den tidligere tilstand. En regel, der er deklareret i deres konfiguration, genskabes, mens en regel, der er tilføjet ved siden af, er et fremmed objekt uden ejer.
Den forskel har et navn i networkd, og den er værd at læse, før du aktiverer noget. Fremmede regler fjernes som standard i nyere versioner, hvilket overrasker dem, der forventede, at deres manuelle poster ville bestå.
Læs versionen, før du stoler på en indstilling
Ejeradfærden styres af en indstilling i networkd.conf, og den indstilling findes ikke i ældre systemd-udgivelser. Kontrollér den installerede version, før du designer ud fra den, fordi en ældre vært opfører sig anderledes end den dokumentation, du læser.
To værdier betyder noget. Den ene afgør, om regler, der ikke er deklareret i networkd-konfigurationen, fjernes, og den anden gør det samme for ruter. Begge handler om ejerskab og ikke om politikkens indhold, og begge vælger som standard den strengere adfærd i aktuelle udgivelser. Slår du dem fra globalt, holder du hver fremmed regel i live, hvilket er en langt bredere beslutning end at deklarere én ønsket VPN-politik.
systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null
Den grep fortæller dig, hvad der er sat lokalt, og hvad leverandørens standard er. Fravær er også information, fordi det betyder, at den kompilerede standard gælder. Skriv standarden i dine noter, så den næste person ikke skal genopdage den.
Deklarér reglen og den tabel, den peger på
En regel i en .network-fil navngiver en tabel, og det er alt, et navn gør. Den opretter ikke ruterne i den tabel og kontrollerer ikke, om de giver mening. Deklarerer du reglen uden ruterne, får du en politik, der matcher trafik og derefter dropper den.
Deklarér ruterne i samme fil, med nåbare næste hop og den rigtige tabel. Behold prioriteten i den deklarerede regel, så den lander, hvor du forventer, i den ordnede liste. En regel, der når den forkerte tabel tidligere end tilsigtet, ændrer mere trafik end den tjeneste, du ville rette. Læs fragmentet nedenfor som en form og ikke som en komplet fil, fordi interfaceejerskab og resten af forbindelsen stadig skal være til stede.
[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
Genindlæs derefter, og læs kernetilstanden i stedet for filen. En konfiguration, der blev parset rent, kan stadig give en regel, du ikke havde tænkt dig, og de to billeder stemmer kun overens, når deklarationen var komplet.
Vælg én ejer til interfacet
To administratorer på én tunnel giver en kamp, der ligner en fejl i begge. At importere et eksisterende wg-quick-opsætning i networkd er en migrering og ikke en tilføjelse, og kører begge, efterlades interfacet og dets regler under to ejere.
Lav migreringen i ét hug: stop den gamle unit, deaktiver den, deklarér interfacet og dets ruter i networkd, og genindlæs derefter. Kontrollér, at den gamle unit ikke kan komme tilbage ved opstart. En efterladt unit, der aktiveres igen efter en genstart, overskriver den tilstand, du netop har deklareret. Behold den gamle konfigurationsfil, indtil den nye har overlevet en genopkobling, og pensionér den så.
Ejerskab af mærket fortjener samme omhu: hvis en regel matcher et firewall-mærke, skal noget sætte det mærke. En regel, der henviser til et mærke, ingen sætter, er død konfiguration, der ser bevidst ud.
Prøv livscyklushændelserne igennem
Konfiguration er kun så god som sin adfærd gennem hændelser. Tag linket ned, op igen, genstart tjenesten, og forny adressen. Læs efter hver af dem regellisten og tabellens indhold.
sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd
Det tilsigtede resultat er den samme ejede politik genskabt og forældet tilstand pensioneret, hvilket er mere holdbart end at tilføje en shellregel igen efter hver genopkobling. Behold én linje i ændringsregistret, der navngiver filen, som ejer reglen, og den version, der understøtter den. Så kan den næste ingeniør finde politikken uden at søge i en shellhistorik. En regel, ingen ejer, er en regel, der går tabt igen.