Môže hákový skript OpenVPN použiť tunel, ktorý práve vytvoril?

Či sa hákový skript dostane na druhú stranu tunela, závisí od troch podmienok: ku ktorej udalosti je pripojený, či je OpenVPN pri behu skriptu stále vnútri svojej štartovacej sekvencie a či bola práca od tej sekvencie oddelená. Väčšina skriptov zlyháva na tretej. Pridanie čakania berie problém životného cyklu ako problém časovania a funguje práve tak často, aby zmiatlo.

Najprv určte udalosť, potom mechanizmus odloženia práce, potom miesto, kde odložená práca beží. Tieto tri rozhodnutia sú nezávislé a ich zámena je dôvod, prečo sa z dvojriadkového háku stane celé popoludnie.

Prečo hák čaká na tunel, ktorý čaká naňho

OpenVPN volá svoje háky synchrónne, vnútri toho istého procesu, ktorý prenáša pakety. up sa spustí, keď zariadenie tun alebo tap existuje, ale pred pridaním akejkoľvek trasy, a route-up po trasách; ani jeden z tých okamihov nesľubuje, že protistrana odpovie. Kým skript z ktoréhokoľvek háku ešte beží, démon nepreposiela, takže príkaz, ktorý očakáva, že prevádzka prejde tunelom, čaká na tunel, ktorý čaká na príkaz. Toto kruhové čakanie je dôvod, prečo ručné spustenie prejde a hák vyprší.

Zrejmá záplata, teda čakanie niekoľkých sekúnd, niekedy funguje preto, že vzdialený koniec nabudol sám, nie preto, že by čakanie niečo opravilo. Pomocník, ktorý zisťuje pripravenosť, je iná odpoveď: hák sa vráti, preposielanie začne a pomocník dostane, čo potrebuje, keď to skutočne existuje.

Vyberte hák podľa udalosti, nie podľa pohodlia

Pripojte up k práci, ktorá potrebuje len zariadenie, route-up k práci, ktorá potrebuje trasy, a client-connect a client-disconnect si nechajte na úlohy pre jednotlivých klientov na strane servera. Upratovanie pri odpojení musí zniesť dvojité spustenie, pretože opätovné pripojenia cez trvalé rozhranie nenasledujú rovnakú sekvenciu ako úplný reštart. Na serveri sa client-connect spustí, keď sa klient autentizuje, nie keď štartuje démon, čo stojí za overenie pred presunom logiky tam. Ak práca patrí k životnému cyklu služby a nie k jednému spojeniu, jednotka systemd je lepší domov ako akýkoľvek hák.

Príkazy háku spúšťa priamo démon, bez prostredného shellu, takže ifconfig_remote na riadku up dorazí ako doslovný text. Zabaľte príkaz do explicitného shellu alebo držte logiku v skripte, ktorý číta prostredie. ipchange je jedna direktíva, ktorá pridáva vlastné argumenty: odovzdáva príkazu adresu a port, takže skript napísaný pre žiadny vidí dva neočakávané.

Tri spôsoby, ako prácu oddeliť

Prvá možnosť je poslať pomocníka na pozadie zvnútra háku: spustite ho cez setsid alebo systemd-run --scope, zatvorte zdedené deskriptory a hneď skončite s nulou. Druhá je nechať hák zapísať malý súbor stavu a nechať na ňom konať časovač systemd alebo cestnú jednotku, čo drží hák triviálny a kladie politiku opakovania tam, kde sú logy. Tretia je hák úplne zahodiť a presunúť prácu do jednotky zoradenej za službou VPN, čo je správna odpoveď, keď práca vôbec nie je pre jednotlivé spojenia. Všetky tri zdieľajú jedno pravidlo: hák sa musí vrátiť, kým bude tunel potrebovať.

Čokoľvek vyberiete, urobte pomocníka idempotentným a pozorovateľným. Dve prekrývajúce sa volania nesmú vykonať tú istú nevratnú akciu dvakrát a pomocník, ktorý zlyhá, musí zanechať niečo, čo človek prečíta.

Oddeľte zlyhania sandboxu od zlyhaní životného cyklu

Keď skript beží z root promptu a ako služba zlyhá, príčinou je zvyčajne sandbox, nie sieť. Restriktívny ProtectHome, len na čítanie ProtectSystem alebo pracovný adresár, ktorý neexistuje môžu nechať skript alebo jeho dáta nedostupné a na hostiteľovi SELinux potrebuje súbor aj kontext, ktorý povoľuje spustenie. Prečítajte jednotku pomocou systemctl cat openvpn-server@server a journal pomocou journalctl -u openvpn-server@server -n 80, potom hľadajte chybu oprávnenia alebo kontextu, nie timeout spojenia. Vypnutie sandboxu má byť posledný krok, nie prvý.

Zlyhanie životného cyklu vyzerá inak: hák štartuje, pomocník beží a socket jednoducho ešte nie je. Zapíšte riadok s časovou pečiatkou zo samotného háku, odpojte a znova pripojte a čítajte udalosti v poradí. Keď pomocník tunel skutočne potrebuje, nech zisťuje pripravenosť, namiesto aby spal pevný čas.

Tri polia robia nasledujúcu správu užitočnou: ktorý hák bežal, ktorý účet použil a kde sa zastavil. Bez nich každé ďalšie vyšetrovanie začína odznova.