FreeBind tsjin After=: in systemd-socket oan in VPN-adres bine

By it opstarten kin in socket-ienheid dy’t in fêst VPN-adres bynt, mislearje foardat de tunnel it tawiisd hat, en de tsjinst efter him start nea. Twa skakelaars lykje oplossings en lossen ferskillende helten fan dat probleem op. FreeBind lit systemd de listener oanmeitsje wylst it adres noch ûntbrekt. After= oardernet allinnich taken, dus it feroaret wannear’t dingen starte sûnder it adres earder komme te litten.

Twa ferskillende problemen, twa ferskillende skakelaars

It earste probleem is in biningsoflier: de kernel wegeret te lústerjen op in adres dat de host net besit, dus de socket-ienheid mislearret daliks en de tsjinst wurdt nea aktivearre. It twadde probleem is in reeheidsoflier: it adres bestiet úteinlik, mar eat besiket it te brûken foardat de tunnel ferkear draacht. FreeBind pakket it earste oan en docht neat foar it twadde. Oarderingsdirektiven pakke gjinien direkt oan, want se beskiede allinnich wat yn hokker folchoarder start. It oanjaan fan it oflier dat jo wier hawwe is de hiele beslissing.

Befêstigje hokker fan de twa jo hawwe út it loch, net út de tsjinstbeskriuwing. In biningsoflier neamt in adres en meldt dat it net tawiisd wurde kin. In reeheidsoflier ferskynt meastentiids letter, as in time-out of in wegere ferbining fan de oare kant sjoen, wylst der in folslein sûne socket-ienheid yn de logboeken stiet.

FreeBind: de listener bestiet foar it adres

FreeBind seit tsjin de kernel dat in bining oan in net-lokaal adres tastien is, sadat systemd de lústerjende socket by it opstarten oanmeitsje kin en dy oan de applikaasje jaan kin wannear’t de applikaasje ek start. Dat is it doel fan socket-aktivaasje, en de reden dat de socket de tsjinst efter him oerlibje kin.

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

De lege tawizing wisket de lúster-yngongen dy’t fan de leveransier-ienheid erfd binne foardat de nije tafoege wurdt, wat foarkomt dat in oerbleaune wildcard-listener op elk ynterface antwurdet. Ferfange it adres en de poarte troch jo eigen en kontrolearje de effektive ienheid, net allinnich it drop-in-bestân. Brûk in drop-in ûnder de namme fan de ienheid ynstee fan in pakketbestân op syn plak te bewurkjen, want de folgjende pakketfernijing skriuwt de bewurking oer en lit gjin spoar fan de bedoeling efter. Pas it dan ta fia de werladen- en werstartproseduere dy’t de socket-ienheid ferwachtet.

De systemd-socketreferinsje dokumintearret it IPv4- en IPv6-gedrach efter dizze opsje, en it wichtige detail is dat it op de bining giet en net op it rûten. Neat deryn jout in adres ta of start in VPN. FreeBind is in tastimming dy’t oan de listener jûn wurdt, gjin ferfanging fan it ynterface.

After= en Wants=: oardering is gjin reeheid

Oardering en eask binne aparte assen, en se trochinoar helje leveret ienheden op dy’t yn de goede folchoarder starte en dochs mislearje. After=vpn-client.service betsjut allinnich dat, as beide taken starte, dizze wachtet oant de oare start is. It lûkt it VPN net nei binnen en it wachtet net oant it VPN klear is mei ferbinen.

Easkdirektiven lykas Wants= en Requires= regelje aktivaasje en ferskille yn wat der bart as de ôfhinklikheid mislearret: de iene giet troch, de oare stoppet. Gjin fan beiden wit wat in ferbûne tunnel betsjut. In VPN-proses kin aktyf wêze sûnder tawiisd adres, of mei in tawiisd adres en gjin rûte nei de partner, en beide tastannen foldogge oan de ôfhinklikheid. As de applikaasje nedich hat dat it adres bestiet, modellearje dy betingst dan eksplisyt ynstee fan it starten fan it proses as bewiis fan reeheid te behanneljen.

Kontrolearje wat de ienheid wier ferklearret mei systemctl cat en systemctl show -p After -p Wants -p Requires. Drop-ins út trije ferskillende mappen kinne direktiven tafoegje dy’t jo nea skreaun hawwe, en systemd lêst allinnich de effektive ienheid.

Wat network-online.target net docht

In ienheid dy’t nei network-online.target oardene is, wachtet oant de netwurkbehearder it netwurk brûkber ferklearret, wat in syngronisaasjepunt by it opstarten is en gjin trochgeande betingst. It seit neat oer oft in beskaat tunnel omheech is, en it sil net wer ôfgean as in VPN midden op ’e middei wer ferbynt. It behannelje as in werferbiningsmonitor is de meast foarkommende ferkearde lêzing fan dat doel.

It systemd-projekt dokumintearret dat ferskil direkt, en it praktyske gefolch is dat alles wat in tunneladres nedich hat, de ôfhinklikheid sels besitte moat. In ienheid dy’t op network-online wachtet en dan in tunneladres bynt, is allinnich korrekt as de tunnel tafallich earst omheech komt, en dat is in tafal en gjin ûntwerp.

Test it libbenssyklus dat jo wier keazen hawwe

Test in skjinne opstart, in fersyk nei’t it adres ferskynt, en it gedrach nei’t it VPN delgiet en weromkomt. Dy trije gefallen skiede in wurkjende listener fan in wurkjende tsjinst.

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

It earste kommando fangt flaters yn it ienheidsbestân foar in werstart, it twadde toant de gearfoege ienheid, en it tredde bewiist oft de listener bestiet en op hokker adres. In listener op in wildcard-adres dêr’t jo in tunneladres ferwachten, is krekt it oerbliuwsel dat de lege ListenStream fuorthelje moast. Werhelje it tredde kommando nei in VPN-werferbining om te sjen oft it adres ferhuze is.

Kies it libbenssyklus bewust: of in frij bûne listener dy’t wachtet op de weromkomst fan in stabyl adres, of in tsjinst dy’t mei de tunnel stoppet en by werstel wer start. Dat binne ferskillende ûntwerpen en se mislearje op ferskillende manieren. Hâld dan it tagongsbelied bûn oan de boarnen en paden dy’t jo bedoelden, want it binen fan in bestimmingsadres easket net dat akseptearre pakketten fia in fertroud ynterface kamen.