FreeBind teenoor After=: ’n systemd-socket aan ’n VPN-adres bind

By die opstart kan ’n socket-eenheid wat aan ’n vaste VPN-adres bind, misluk voordat die tonnel dit toegeken het, en die diens agter hom begin nooit nie. Twee skakelaars lyk soos oplossings en los verskillende helftes van daardie probleem op. FreeBind laat systemd die luisteraar skep terwyl die adres nog afwesig is. After= orden net take, so dit verander wanneer dinge begin sonder om die adres enige vinniger te laat kom.

Twee verskillende probleme, twee verskillende skakelaars

Die eerste probleem is ’n bindingsfout: die kernel weier ’n luister op ’n adres wat die gasheer nie besit nie, so die socket-eenheid misluk dadelik en die diens word nooit geaktiveer nie. Die tweede probleem is ’n gereedheidsfout: die adres bestaan uiteindelik, maar iets probeer dit gebruik voordat die tonnel verkeer dra. FreeBind spreek die eerste aan en doen niks vir die tweede nie. Ordeningsopdragte spreek nie een van die twee direk aan nie, want hulle besluit net wat in watter volgorde begin. Om die fout te benoem wat jy werklik het, is die hele besluit.

Bevestig watter een jy het uit die joernaal eerder as uit die diensbeskrywing. ’n Bindingsfout noem ’n adres en rapporteer dat dit nie toegeken kan word nie. ’n Gereedheidsfout verskyn gewoonlik later, as ’n tydverstreke of ’n geweierde verbinding gesien van die oorkant, met ’n heeltemal gesonde socket-eenheid in die logboeke.

FreeBind: die luisteraar bestaan voor die adres

FreeBind sê vir die kernel om ’n binding aan ’n nie-plaaslike adres toe te laat, sodat systemd die luisterende socket by die opstart kan skep en dit aan die toepassing kan gee wanneer die toepassing ook al begin. Dit is die punt van socket-aktivering, en die rede waarom die socket die diens agter hom kan oorleef.

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

Die leë toewysing skrap die luisterinskrywings wat van die verskaffereenheid geërf is voordat die nuwe een bygevoeg word, wat verhoed dat ’n oorblywende wildcard-luisteraar op elke koppelvlak antwoord. Vervang die adres en poort met jou eie, en verifieer die effektiewe eenheid eerder as net die drop-in-lêer. Gebruik ’n drop-in onder die eenheid se naam eerder as om ’n pakketlêer in plek te wysig, want die volgende pakketopdatering sal die wysiging oorskryf en geen spoor van die bedoeling laat nie. Pas dit dan toe deur die herlaai- en herbeginprosedure wat die socket-eenheid verwag.

Die systemd-socket-verwysing dokumenteer die IPv4- en IPv6-gedrag agter die opsie, en die belangrike detail is dat dit op die binding van toepassing is eerder as op roetering. Niks daarin ken ’n adres toe of begin ’n VPN nie. FreeBind is ’n toestemming wat aan die luisteraar gegee word, nie ’n vervanging vir die koppelvlak nie.

After= en Wants=: ordening is nie gereedheid nie

Ordening en vereiste is aparte asse, en om hulle te verwar lewer eenhede wat in die regte volgorde begin en steeds misluk. After=vpn-client.service beteken net dat as beide take begin word, hierdie een wag dat die ander begin word. Dit trek nie die VPN in nie, en dit wag nie dat die VPN klaar verbind nie.

Vereiste-opdragte soos Wants= en Requires= hanteer aktivering, en hulle verskil in wat gebeur wanneer die afhanklikheid misluk: een gaan voort, die ander stop. Nie een van hulle weet wat ’n verbonde tonnel beteken nie. ’n VPN-proses kan aktief wees sonder dat ’n adres toegeken is, of met ’n adres toegeken en geen roete na die eweknie nie, en beide toestande bevredig die afhanklikheid. As die toepassing nodig het dat die adres bestaan, modelleer daardie voorwaarde uitdruklik in plaas daarvan om die begin van die proses as bewys van gereedheid te beskou.

Kontroleer wat die eenheid werklik verklaar met systemctl cat en systemctl show -p After -p Wants -p Requires. Drop-ins uit drie verskillende gidse kan opdragte byvoeg wat jy nooit geskryf het nie, en die effektiewe eenheid is die enigste ding wat systemd lees.

Wat network-online.target nie doen nie

’n Eenheid wat na network-online.target georden is, wag dat die netwerkbestuurder die netwerk bruikbaar verklaar, wat ’n opstartsinchronisasiepunt is eerder as ’n deurlopende toestand. Dit sê niks oor of ’n spesifieke tonnel op is nie, en dit sal nie weer vuur wanneer ’n VPN in die middel van die middag weer verbind nie. Om dit as ’n herverbindingsmonitor te behandel, is die mees algemene verkeerde lesing van daardie teiken.

Die systemd-projek dokumenteer daardie onderskeid direk, en die praktiese gevolg is dat enigiets wat ’n tonneladres nodig het, die afhanklikheid self moet besit. ’n Eenheid wat vir network-online wag en dan ’n tonneladres bind, is net korrek wanneer die tonnel toevallig eerste opkom, wat ’n toeval is eerder as ’n ontwerp.

Toets die lewensiklus wat jy werklik gekies het

Toets ’n skoon opstart, ’n versoek nadat die adres verskyn, en die gedrag nadat die VPN val en terugkeer. Daardie drie gevalle skei ’n werkende luisteraar van ’n werkende diens.

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

Die eerste opdrag vang eenheidlêerfoute voor ’n herbegin, die tweede wys die saamgevoegde eenheid, en die derde bewys of die luisteraar bestaan en op watter adres. ’n Luisteraar op ’n wildcard-adres waar jy ’n tonneladres verwag het, is presies die oorblyfsel wat die leë ListenStream moes verwyder. Herhaal die derde opdrag ná ’n VPN-herverbinding om te sien of die adres geskuif het.

Kies die lewensiklus doelbewus: óf ’n vrygebinde luisteraar wat wag dat ’n stabiele adres terugkeer, óf ’n diens wat saam met die tonnel stop en by herstel weer begin. Dit is verskillende ontwerpe en hulle misluk op verskillende maniere. Hou dan toegangsbeleid gekoppel aan die bronne en paaie wat jy bedoel het, want om ’n bestemmingsadres te bind vereis nie dat aanvaarde pakkette deur ’n vertroude koppelvlak gekom het nie.