FreeBind versus After=: připoutání systemd socketu k adrese VPN

Při startu může socketová jednotka, která připoutává pevnou adresu VPN, selhat dřív, než jí tunel adresu přidělí, a služba za ní se nikdy nespustí. Dva přepínače vypadají jako řešení a řeší různé poloviny tohoto problému. FreeBind umožňuje systemd vytvořit posluchač, dokud adresa ještě chybí. After= jen řadí úlohy, takže mění, kdy se co spouští, ale nedosáhne toho, aby adresa dorazila dřív.

Dva různé problémy, dva různé přepínače

První problém je selhání připoutání: jádro odmítne naslouchat na adrese, kterou hostitel nevlastní, takže socketová jednotka okamžitě selže a služba se nikdy neaktivuje. Druhý problém je selhání připravenosti: adresa nakonec existuje, ale něco se ji pokusí použít dřív, než tunel přenáší provoz. FreeBind řeší první a pro druhý nedělá nic. Direktivy pořadí neřeší přímo ani jeden, protože jen rozhodují, co se v jakém pořadí spustí. Pojmenovat selhání, které skutečně máte, je celé rozhodnutí.

Ověřte, které z těch dvou máte, v žurnálu, ne v popisu služby. Selhání připoutání pojmenuje adresu a oznámí, že ji nelze přidělit. Selhání připravenosti se obvykle objeví později, jako vypršení časového limitu nebo odmítnuté spojení viděné z druhé strany, zatímco v logu je naprosto zdravá socketová jednotka.

FreeBind: posluchač existuje dřív než adresa

FreeBind říká jádru, aby povolilo připoutání k necizí adrese, takže systemd může při startu vytvořit naslouchající socket a předat ho aplikaci, kdykoli se aplikace spustí. To je smysl aktivace socketem a důvod, proč socket může přežít službu za sebou.

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

Prázdné přiřazení vymaže položky naslouchání zděděné z jednotky dodavatele dřív, než se přidá nová, což brání zbytkovému wildcard posluchači odpovídat na každém rozhraní. Nahraďte adresu a port svými a ověřte efektivní jednotku, ne jen soubor drop-in. Použijte drop-in pod názvem jednotky místo úpravy souboru balíčku na místě, protože příští aktualizace balíčku úpravu přepíše a nezanechá žádnou stopu po záměru. Pak ho aplikujte postupem znovunačtení a restartu, který socketová jednotka očekává.

Referenční příručka systemd socketů dokumentuje chování IPv4 a IPv6 za touto volbou a důležitý detail je, že se vztahuje k připoutání, ne ke směrování. Nic v ní nepřiděluje adresu ani nespouští VPN. FreeBind je oprávnění dané posluchači, ne náhrada rozhraní.

After= a Wants=: pořadí není připravenost

Pořadí a požadavek jsou oddělené osy a jejich záměna vytváří jednotky, které se spustí ve správném pořadí a přesto selžou. After=vpn-client.service znamená jen, že pokud se spustí obě úlohy, tato čeká na spuštění druhé. Netáhne VPN a nečeká, až VPN dokončí připojování.

Požadavkové direktivy jako Wants= a Requires= se starají o aktivaci a liší se v tom, co se stane, když závislost selže: jedna pokračuje, druhá se zastaví. Ani jedna neví, co znamená připojený tunel. Proces VPN může být aktivní bez přidělené adresy nebo s přidělenou adresou a bez trasy k protějšku a oba stavy závislost splňují. Pokud aplikace potřebuje, aby adresa existovala, modelujte tuto podmínku výslovně, místo abyste start procesu považovali za důkaz připravenosti.

Zkontrolujte, co jednotka skutečně deklaruje, pomocí systemctl cat a systemctl show -p After -p Wants -p Requires. Drop-in ze tří různých adresářů mohou přidat direktivy, které jste nikdy nenapsali, a systemd čte jen efektivní jednotku.

Co network-online.target nedělá

Jednotka seřazená za network-online.target čeká, až správce sítě prohlásí síť za použitelnou, což je synchronizační bod při startu, ne trvalá podmínka. Neříká nic o tom, zda je konkrétní tunel nahoře, a znovu se nespustí, když se VPN odpoledne znovu připojí. Považovat ho za monitor opětovného připojení je nejčastější chybné čtení tohoto cíle.

Projekt systemd tento rozdíl přímo dokumentuje a praktickým důsledkem je, že vše, co potřebuje adresu tunelu, musí závislost vlastnit samo. Jednotka, která čeká na network-online a pak připoutá adresu tunelu, je správná jen tehdy, když se tunel náhodou zvedne první, což je shoda okolností, ne návrh.

Otestujte životní cyklus, který jste skutečně zvolili

Otestujte čistý start, požadavek poté, co se adresa objeví, a chování poté, co VPN spadne a vrátí se. Tyto tři případy oddělují funkční posluchač od funkční služby.

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

První příkaz zachytí chyby v souboru jednotky před restartem, druhý ukáže sloučenou jednotku a třetí dokáže, zda posluchač existuje a na jaké adrese. Posluchač na wildcard adrese tam, kde jste čekali adresu tunelu, je přesně ten zbytek, který měl prázdný ListenStream odstranit. Po opětovném připojení VPN zopakujte třetí příkaz a zjistěte, zda se adresa přesunula.

Zvolte životní cyklus vědomě: buď volně připoutaný posluchač, který čeká na návrat stabilní adresy, nebo služba, která se zastaví s tunelem a při obnovení znovu nastartuje. To jsou různé návrhy a selhávají různě. Pak držte přístupovou politiku svázanou se zdroji a cestami, které jste zamýšleli, protože připoutání cílové adresy nevyžaduje, aby přijaté pakety dorazily přes důvěryhodné rozhraní.