FreeBind mot After=: å binda ein systemd-socket til ei VPN-adresse

Ved oppstart kan ein socket-eining som bind ei fast VPN-adresse, feile før tunnelen har tildelt ho, og tenesta bak startar aldri. To brytarar ser ut som rettingar og løyser kvar sin halvdel av problemet. FreeBind lèt systemd opprette lyttaren medan adressa framleis manglar. After= ordnar berre jobbar, så det endrar når ting startar utan å få adressa til å kome tidlegare.

To ulike problem, to ulike brytarar

Det første problemet er ein bindingsfeil: kjernen nektar å lytte på ei adresse verten ikkje eig, så socket-eininga feilar med ein gong og tenesta blir aldri aktivert. Det andre problemet er ein beredskapsfeil: adressa finst til slutt, men noko prøver å bruke ho før tunnelen ber trafikk. FreeBind løyser det første og gjer ingenting for det andre. Ordensdirektiv løyser ingen av dei direkte, fordi dei berre avgjer kva som startar i kva rekkjefølgje. Å namngje feilen du faktisk har, er heile avgjerda.

Stadfest kva av dei to du har, frå journalen og ikkje frå tenesteskildringa. Ein bindingsfeil nemner ei adresse og rapporterer at ho ikkje kan tildelast. Ein beredskapsfeil dukkar vanlegvis opp seinare, som tidsavbrot eller ei avvist tilkopling sett frå den andre sida, med ei heilt sunn socket-eining i loggen.

FreeBind: lyttaren finst før adressa

FreeBind ber kjernen tillate ei binding til ei ikkje-lokal adresse, slik at systemd kan opprette den lyttande socketen ved oppstart og gje han til applikasjonen kvar gong applikasjonen startar. Det er poenget med socket-aktivering, og grunnen til at socketen kan overleve tenesta bak seg.

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

Den tome tildelinga fjernar lytteoppføringane som er arva frå leverandøren si eining, før den nye blir lagd til, og hindrar ein attverande wildcard-lyttar i å svare på alle grensesnitt. Byt ut adressa og porten med dine eigne, og verifiser den effektive eininga og ikkje berre drop-in-fila. Bruk ein drop-in under namnet på eininga i staden for å redigere ei pakkefil på staden, fordi neste pakkeoppdatering skriv over endringa og ikkje lèt noko spor av hensikta att. Bruk han deretter gjennom innlastings- og omstartprosedyren som socket-eininga ventar.

systemd-socket-referansen dokumenterer IPv4- og IPv6-åtferda bak valet, og den viktige detaljen er at han gjeld bindinga og ikkje rutinga. Ingenting i han tildeler ei adresse eller startar ein VPN. FreeBind er ei løyve gitt til lyttaren, ikkje ei erstatning for grensesnittet.

After= og Wants=: rekkjefølgje er ikkje beredskap

Rekkjefølgje og krav er separate aksar, og å blande dei gir einingar som startar i rett rekkjefølgje og likevel feilar. After=vpn-client.service tyder berre at viss begge jobbane blir starta, ventar denne på at den andre blir starta. Han dreg ikkje inn VPN, og han ventar ikkje på at VPN blir ferdig med å kople til.

Kravdirektiv som Wants= og Requires= handterer aktivering, og dei skil seg i kva som skjer når avhengnaden feilar: den eine held fram, den andre stoppar. Ingen av dei veit kva ein tilkopla tunnel tyder. Ein VPN-prosess kan vere aktiv utan tildelt adresse, eller med tildelt adresse og utan rute til motparten, og begge tilstandane oppfyller avhengnaden. Viss applikasjonen treng at adressa finst, må du modellere den føresetnaden eksplisitt i staden for å handsame prosessoppstart som prov på beredskap.

Kontroller kva eininga faktisk erklærer med systemctl cat og systemctl show -p After -p Wants -p Requires. Drop-ins frå tre ulike katalogar kan leggje til direktiv du aldri har skrive, og den effektive eininga er det einaste systemd les.

Kva network-online.target ikkje gjer

Ei eining som er ordna etter network-online.target, ventar på at nettverkshandsamaren erklærer nettverket brukbart, noko som er eit synkroniseringspunkt ved oppstart og ikkje ein vedvarande føresetnad. Ho seier ingenting om ein bestemt tunnel er oppe, og ho blir ikkje utløyst på nytt når ein VPN koplar til igjen midt på ettermiddagen. Å handsame ho som ein gjenoppkoplingsovervakar er den vanlegaste feillesinga av det målet.

systemd-prosjektet dokumenterer den skilnaden direkte, og den praktiske konsekvensen er at alt som treng ei tunneladresse, sjølv må eige avhengnaden. Ei eining som ventar på network-online og deretter bind ei tunneladresse, er berre rett når tunnelen tilfeldigvis kjem opp først, og det er eit tilfelle og ikkje eit design.

Test livssyklusen du faktisk valde

Test ein rein oppstart, ein førespurnad etter at adressa viser seg, og åtferda etter at VPN fell og kjem tilbake. Dei tre tilfella skil ein fungerande lyttar frå ei fungerande teneste.

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

Den første kommandoen fangar feil i einingfila før ein omstart, den andre viser den samanslegne eininga, og den tredje provar om lyttaren finst og på kva adresse. Ein lyttar på ei wildcard-adresse der du venta ei tunneladresse, er nøyaktig resten som den tome ListenStream skulle fjerne. Gjenta den tredje kommandoen etter ei VPN-gjenoppkopling for å sjå om adressa flytta seg.

Vel livssyklusen med vilje: anten ein fritt bunden lyttar som ventar på at ei stabil adresse kjem tilbake, eller ei teneste som stoppar med tunnelen og startar igjen ved gjenoppretting. Dette er ulike design, og dei feilar på ulike måtar. Hald deretter tilgangspolicyen bunden til kjeldene og banane du meinte, fordi binding av ei måladdresse krev ikkje at aksepterte pakkar kom gjennom eit klarert grensesnitt.