FreeBind kontra After=: at binde en systemd-socket til en VPN-adresse

Ved opstart kan en socket-unit, der binder en fast VPN-adresse, fejle, før tunnelen har tildelt den, og tjenesten bag den starter aldrig. To kontakter ligner løsninger og løser hver sin halvdel af problemet. FreeBind lader systemd oprette lytteren, mens adressen stadig mangler. After= ordner kun job, så det ændrer, hvornår ting starter, uden at adressen kommer tidligere.

To forskellige problemer, to forskellige kontakter

Det første problem er en bindingsfejl: kernen afviser at lytte på en adresse, som værten ikke ejer, så socket-unitten fejler straks, og tjenesten aktiveres aldrig. Det andet problem er en parathedsfejl: adressen findes til sidst, men noget forsøger at bruge den, før tunnelen bærer trafik. FreeBind løser det første og gør intet ved det andet. Ordensdirektiver løser ikke noget af det direkte, fordi de kun afgør, hvad der starter i hvilken rækkefølge. At navngive den fejl, du faktisk har, er hele beslutningen.

Bekræft, hvilken af de to du har, ud fra journalen og ikke ud fra tjenestebeskrivelsen. En bindingsfejl nævner en adresse og rapporterer, at den ikke kan tildeles. En parathedsfejl viser sig som regel senere, som en timeout eller en afvist forbindelse set fra den anden side, med en helt sund socket-unit i loggen.

FreeBind: lytteren findes før adressen

FreeBind fortæller kernen, at den må tillade en binding til en ikke-lokal adresse, så systemd kan oprette den lyttende socket ved opstart og give den til applikationen, når applikationen starter. Det er meningen med socket-aktivering og grunden til, at socketen kan overleve tjenesten bag den.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

Den tomme tildeling rydder de lytteposter, der er arvet fra leverandørens unit, før den nye tilføjes, hvilket forhindrer en resterende wildcard-lytter i at svare på alle interfaces. Erstat adressen og porten med dine egne, og verificér den effektive unit og ikke kun drop-in-filen. Brug en drop-in under unitens navn i stedet for at redigere en pakkefil på stedet, fordi den næste pakkeopdatering overskriver ændringen og ikke efterlader noget spor af hensigten. Anvend den derefter gennem den genindlæsnings- og genstartsprocedure, som socket-unitten forventer.

systemd-socket-reference dokumenterer IPv4- og IPv6-adfærden bag valgmuligheden, og den vigtige detalje er, at den gælder bindingen og ikke routing. Intet i den tildeler en adresse eller starter en VPN. FreeBind er en tilladelse givet til lytteren, ikke en erstatning for interfacet.

After= og Wants=: rækkefølge er ikke parathed

Rækkefølge og krav er separate akser, og at forveksle dem giver units, der starter i den rigtige rækkefølge og alligevel fejler. After=vpn-client.service betyder kun, at hvis begge job startes, venter dette på, at det andet startes. Det trækker ikke VPN ind, og det venter ikke på, at VPN bliver færdig med at forbinde.

Kravdirektiver som Wants= og Requires= håndterer aktivering og adskiller sig i, hvad der sker, når afhængigheden fejler: den ene fortsætter, den anden stopper. Ingen af dem ved, hvad en forbundet tunnel betyder. En VPN-proces kan være aktiv uden tildelt adresse eller med tildelt adresse og uden rute til modparten, og begge tilstande opfylder afhængigheden. Hvis applikationen har brug for, at adressen findes, skal du modellere den betingelse eksplicit i stedet for at behandle processtart som bevis på parathed.

Kontrollér, hvad unitten faktisk erklærer, med systemctl cat og systemctl show -p After -p Wants -p Requires. Drop-ins fra tre forskellige mapper kan tilføje direktiver, du aldrig har skrevet, og den effektive unit er det eneste, systemd læser.

Hvad network-online.target ikke gør

En unit, der er ordnet efter network-online.target, venter på, at netværksadministratoren erklærer netværket brugbart, hvilket er et synkroniseringspunkt ved opstart og ikke en vedvarende betingelse. Den siger intet om, hvorvidt en bestemt tunnel er oppe, og den udløses ikke igen, når en VPN genopretter forbindelsen midt på eftermiddagen. At behandle den som en genopkoblingsmonitor er den mest almindelige fejllæsning af det mål.

systemd-projektet dokumenterer den forskel direkte, og den praktiske konsekvens er, at alt, der har brug for en tunneladresse, selv må eje afhængigheden. En unit, der venter på network-online og derefter binder en tunneladresse, er kun korrekt, når tunnelen tilfældigvis kommer op først, og det er et tilfælde og ikke et design.

Test den livscyklus, du faktisk valgte

Test en ren opstart, en anmodning efter adressen vises, og adfærden efter VPN falder og vender tilbage. De tre tilfælde adskiller en fungerende lytter fra en fungerende tjeneste.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

Den første kommando fanger fejl i unit-filen før en genstart, den anden viser den sammenlagte unit, og den tredje beviser, om lytteren findes, og på hvilken adresse. En lytter på en wildcard-adresse, hvor du forventede en tunneladresse, er præcis den rest, som den tomme ListenStream skulle fjerne. Gentag den tredje kommando efter en VPN-genopkobling for at se, om adressen flyttede sig.

Vælg livscyklussen bevidst: enten en frit bundet lytter, der venter på, at en stabil adresse vender tilbage, eller en tjeneste, der stopper med tunnelen og starter igen ved genopretning. Det er forskellige designs, og de fejler på forskellige måder. Hold derefter adgangspolitikken bundet til de kilder og stier, du havde tænkt dig, fordi binding af en destinationsadresse ikke kræver, at accepterede pakker ankom gennem et betroet interface.