FreeBind verzus After=: pripútanie systemd socketu k adrese VPN

Pri štarte môže socketová jednotka, ktorá pripútava pevnú adresu VPN, zlyhať skôr, než jej tunel adresu pridelí, a služba za ňou sa nikdy nespustí. Dva prepínače vyzerajú ako opravy a riešia rôzne polovice tohto problému. FreeBind umožňuje systemd vytvoriť poslucháča, kým adresa ešte chýba. After= iba zoraďuje úlohy, takže mení, kedy sa čo spúšťa, ale nedosiahne, aby adresa dorazila skôr.

Dva rôzne problémy, dva rôzne prepínače

Prvý problém je zlyhanie pripútania: jadro odmietne načúvať na adrese, ktorú hostiteľ nevlastní, takže socketová jednotka okamžite zlyhá a služba sa nikdy neaktivuje. Druhý problém je zlyhanie pripravenosti: adresa nakoniec existuje, ale niečo ju skúsi použiť skôr, než tunel prenáša prevádzku. FreeBind rieši prvý a pre druhý nerobí nič. Direktívy poradia neriešia priamo ani jeden, pretože len rozhodujú, čo sa v akom poradí spustí. Pomenovať zlyhanie, ktoré skutočne máte, je celé rozhodnutie.

Overte, ktoré z tých dvoch máte, v žurnáli, nie v popise služby. Zlyhanie pripútania pomenuje adresu a oznámi, že ju nemožno prideliť. Zlyhanie pripravenosti sa zvyčajne objaví neskôr, ako vypršanie časového limitu alebo odmietnuté spojenie videné z druhej strany, pričom v logu je úplne zdravá socketová jednotka.

FreeBind: poslucháč existuje pred adresou

FreeBind hovorí jadru, aby povolilo pripútanie k necudzej adrese, takže systemd môže pri štarte vytvoriť načúvajúci socket a odovzdať ho aplikácii, kedykoľvek sa aplikácia spustí. To je zmysel aktivácie socketom a dôvod, prečo socket môže prežiť službu za sebou.

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

Prázdne priradenie vymaže položky načúvania zdedené z jednotky dodávateľa skôr, než sa pridá nová, čo bráni zvyšnému wildcard poslucháčovi odpovedať na každom rozhraní. Nahraďte adresu a port svojimi a overte efektívnu jednotku, nie len súbor drop-in. Použite drop-in pod názvom jednotky namiesto úpravy súboru balíka na mieste, pretože nasledujúca aktualizácia balíka úpravu prepíše a nezanechá žiadnu stopu po zámere. Potom ho aplikujte postupom opätovného načítania a reštartu, ktorý socketová jednotka očakáva.

Referenčná príručka systemd socketov dokumentuje správanie IPv4 a IPv6 za touto voľbou a dôležitý detail je, že sa vzťahuje na pripútanie, nie na smerovanie. Nič v nej neprideľuje adresu ani nespúšťa VPN. FreeBind je oprávnenie dané poslucháčovi, nie náhrada rozhrania.

After= a Wants=: poradie nie je pripravenosť

Poradie a požiadavka sú oddelené osi a ich zámena vytvára jednotky, ktoré sa spustia v správnom poradí a napriek tomu zlyhajú. After=vpn-client.service znamená len, že ak sa spustia obe úlohy, táto čaká na spustenie druhej. Neťahá VPN a nečaká, kým VPN dokončí pripájanie.

Požiadavkové direktívy ako Wants= a Requires= sa starajú o aktiváciu a líšia sa v tom, čo sa stane, keď závislosť zlyhá: jedna pokračuje, druhá sa zastaví. Ani jedna nevie, čo znamená pripojený tunel. Proces VPN môže byť aktívny bez pridelenej adresy alebo s pridelenou adresou a bez trasy k partnerovi, a oba stavy závislosť spĺňajú. Ak aplikácia potrebuje, aby adresa existovala, modelujte tú podmienku výslovne, namiesto toho, aby ste štart procesu považovali za dôkaz pripravenosti.

Skontrolujte, čo jednotka skutočne deklaruje, pomocou systemctl cat a systemctl show -p After -p Wants -p Requires. Drop-in z troch rôznych adresárov môžu pridať direktívy, ktoré ste nikdy nenapísali, a systemd číta len efektívnu jednotku.

Čo network-online.target nerobí

Jednotka zoradená za network-online.target čaká, kým správca siete vyhlási sieť za použiteľnú, čo je synchronizačný bod pri štarte, nie trvalá podmienka. Nehovorí nič o tom, či je konkrétny tunel hore, a znovu sa nespustí, keď sa VPN popoludní znova pripojí. Považovať ho za monitor opätovného pripojenia je najčastejšie nesprávne čítanie tohto cieľa.

Projekt systemd tento rozdiel priamo dokumentuje a praktickým dôsledkom je, že všetko, čo potrebuje adresu tunela, musí závislosť vlastniť samo. Jednotka, ktorá čaká na network-online a potom pripúta adresu tunela, je správna len vtedy, keď sa tunel náhodou zdvihne prvý, a to je náhoda, nie návrh.

Otestujte životný cyklus, ktorý ste skutočne zvolili

Otestujte čistý štart, požiadavku po tom, čo sa adresa objaví, a správanie po tom, čo VPN padne a vráti sa. Tieto tri prípady oddeľujú funkčného poslucháča od funkčnej služby.

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

Prvý príkaz zachytí chyby v súbore jednotky pred reštartom, druhý ukáže zlúčenú jednotku a tretí dokáže, či poslucháč existuje a na akej adrese. Poslucháč na wildcard adrese tam, kde ste čakali adresu tunela, je presne ten zvyšok, ktorý mal prázdny ListenStream odstrániť. Po opätovnom pripojení VPN zopakujte tretí príkaz a zistite, či sa adresa posunula.

Zvoľte životný cyklus vedome: buď voľne pripútaný poslucháč, ktorý čaká na návrat stabilnej adresy, alebo služba, ktorá sa zastaví s tunelom a pri obnove znova naštartuje. To sú rôzne návrhy a zlyhávajú rôzne. Potom držte prístupovú politiku zviazanú so zdrojmi a cestami, ktoré ste zamýšľali, pretože pripútanie cieľovej adresy nevyžaduje, aby prijaté pakety dorazili cez dôveryhodné rozhranie.