FreeBind mot After=: å binde en systemd-socket til en VPN-adresse

Ved oppstart kan en socket-enhet som binder en fast VPN-adresse, feile før tunnelen har tildelt den, og tjenesten bak starter aldri. To brytere ser ut som rettelser og løser hver sin halvdel av problemet. FreeBind lar systemd opprette lytteren mens adressen fortsatt mangler. After= ordner bare jobber, så det endrer når ting starter uten å få adressen til å komme tidligere.

To forskjellige problemer, to forskjellige brytere

Det første problemet er en bindingsfeil: kjernen avviser å lytte på en adresse verten ikke eier, så socket-enheten feiler med en gang og tjenesten blir aldri aktivert. Det andre problemet er en beredskapsfeil: adressen finnes til slutt, men noe prøver å bruke den før tunnelen bærer trafikk. FreeBind løser det første og gjør ingenting for det andre. Ordensdirektiver løser ingen av dem direkte, fordi de bare avgjør hva som starter i hvilken rekkefølge. Å navngi feilen du faktisk har, er hele beslutningen.

Bekreft hvilken av de to du har, fra journalen og ikke fra tjenestebeskrivelsen. En bindingsfeil nevner en adresse og rapporterer at den ikke kan tildeles. En beredskapsfeil dukker vanligvis opp senere, som tidsavbrudd eller en avvist tilkobling sett fra den andre siden, med en helt sunn socket-enhet i loggen.

FreeBind: lytteren finnes før adressen

FreeBind ber kjernen tillate en binding til en ikke-lokal adresse, slik at systemd kan opprette den lyttende socketen ved oppstart og gi den til applikasjonen hver gang applikasjonen starter. Det er poenget med socket-aktivering, og grunnen til at socketen kan overleve tjenesten bak seg.

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

Den tomme tildelingen fjerner lytteoppføringene som er arvet fra leverandørens enhet, før den nye legges til, og hindrer en gjenværende wildcard-lytter i å svare på alle grensesnitt. Erstatt adressen og porten med dine egne, og verifiser den effektive enheten og ikke bare drop-in-filen. Bruk en drop-in under enhetens navn i stedet for å redigere en pakkefil på stedet, fordi neste pakkeoppdatering overskriver endringen og ikke etterlater noe spor av hensikten. Bruk den deretter gjennom innlastings- og omstartprosedyren som socket-enheten forventer.

systemd-socket-referansen dokumenterer IPv4- og IPv6-atferden bak valget, og den viktige detaljen er at den gjelder bindingen og ikke rutingen. Ingenting i den tildeler en adresse eller starter en VPN. FreeBind er en tillatelse gitt til lytteren, ikke en erstatning for grensesnittet.

After= og Wants=: rekkefølge er ikke beredskap

Rekkefølge og krav er separate akser, og å blande dem gir enheter som starter i riktig rekkefølge og likevel feiler. After=vpn-client.service betyr bare at hvis begge jobbene startes, venter denne på at den andre startes. Den trekker ikke inn VPN, og den venter ikke på at VPN blir ferdig med å koble til.

Kravdirektiver som Wants= og Requires= håndterer aktivering, og de skiller seg i hva som skjer når avhengigheten feiler: den ene fortsetter, den andre stopper. Ingen av dem vet hva en tilkoblet tunnel betyr. En VPN-prosess kan være aktiv uten tildelt adresse, eller med tildelt adresse og uten rute til motparten, og begge tilstandene oppfyller avhengigheten. Hvis applikasjonen trenger at adressen finnes, må du modellere den betingelsen eksplisitt i stedet for å behandle prosessoppstart som bevis på beredskap.

Kontroller hva enheten faktisk erklærer med systemctl cat og systemctl show -p After -p Wants -p Requires. Drop-ins fra tre forskjellige kataloger kan legge til direktiver du aldri har skrevet, og den effektive enheten er det eneste systemd leser.

Hva network-online.target ikke gjør

En enhet som er ordnet etter network-online.target, venter på at nettverksbehandleren erklærer nettverket brukbart, noe som er et synkroniseringspunkt ved oppstart og ikke en vedvarende betingelse. Den sier ingenting om hvorvidt en bestemt tunnel er oppe, og den utløses ikke på nytt når en VPN kobler til igjen midt på ettermiddagen. Å behandle den som en gjenoppkoblingsmonitor er den vanligste feillesningen av det målet.

systemd-prosjektet dokumenterer den forskjellen direkte, og den praktiske konsekvensen er at alt som trenger en tunneladresse, selv må eie avhengigheten. En enhet som venter på network-online og deretter binder en tunneladresse, er bare riktig når tunnelen tilfeldigvis kommer opp først, og det er en tilfeldighet og ikke et design.

Test livssyklusen du faktisk valgte

Test en ren oppstart, en forespørsel etter at adressen vises, og atferden etter at VPN faller og kommer tilbake. De tre tilfellene skiller en fungerende lytter fra en fungerende tjeneste.

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

Den første kommandoen fanger feil i enhetsfilen før en omstart, den andre viser den sammenslåtte enheten, og den tredje beviser om lytteren finnes og på hvilken adresse. En lytter på en wildcard-adresse der du forventet en tunneladresse, er nøyaktig resten som den tomme ListenStream skulle fjerne. Gjenta den tredje kommandoen etter en VPN-gjenoppkobling for å se om adressen flyttet seg.

Velg livssyklusen bevisst: enten en fritt bundet lytter som venter på at en stabil adresse kommer tilbake, eller en tjeneste som stopper med tunnelen og starter igjen ved gjenoppretting. Dette er forskjellige design, og de feiler på forskjellige måter. Hold deretter tilgangspolicyen bundet til kildene og banene du mente, fordi binding av en måladdresse ikke krever at aksepterte pakker kom gjennom et klarert grensesnitt.