Kan ’n OpenVPN-haakskrip die tonnel gebruik wat hy pas gebou het?

Of ’n haakskrip die ander kant van die tonnel kan bereik, hang van drie voorwaardes af: aan watter gebeurtenis dit geheg is, of OpenVPN nog binne sy opstartreeks is wanneer die skrip loop, en of die werk van daardie reeks losgemaak is. Die meeste skripte faal op die derde. Om ’n slaap by te voeg, behandel ’n lewensiklusprobleem as ’n tydsprobleem, en dit werk net dikwels genoeg om te mislei.

Kies eers die gebeurtenis, dan die meganisme om werk uit te stel, dan die plek waar die uitgestelde werk loop. Dié drie besluite is onafhanklik, en om hulle te verwar is hoe ’n haak van twee reëls ’n middag word.

Waarom die haak wag op ’n tonnel wat op hom wag

OpenVPN roep sy hake sinchronies aan, binne dieselfde proses wat pakkette beweeg. up vuur wanneer die tun- of tap-toestel bestaan, maar voordat enige roete bygevoeg is, en route-up vuur ná roetes; nie een van dié oomblikke belowe dat ’n eweknie antwoord nie. Terwyl ’n skrip van enige haak nog loop, stuur die daemon nie aan nie, so ’n opdrag wat verwag dat verkeer deur die tonnel beweeg, wag op ’n tonnel wat op die opdrag wag. Dié kringloop is waarom ’n handmatige lopie slaag en die haak uittyd.

Die ooglopende pleister, ’n paar sekondes slaap, werk soms omdat die ander kant vanself opgekom het, nie omdat die slaap iets reggemaak het nie. ’n Helper wat vir gereedheid peil, is ’n ander antwoord: die haak keer terug, aanstuur begin, en die helper kry wat hy nodig het sodra dit werklik daar is.

Kies die haak volgens gebeurtenis, nie volgens gerief nie

Heg up aan werk wat net die toestel nodig het, route-up aan werk wat roetes nodig het, en hou client-connect en client-disconnect vir per-kliënt-take aan die bedienerkant. Opruiming by ontkoppeling moet dit verdra om twee keer te loop, want herverbindings oor ’n aanhoudende koppelvlak volg nie dieselfde reeks as ’n volle herbegin nie. Op die bediener vuur client-connect wanneer ’n kliënt verifieer, nie wanneer die daemon begin nie, wat die moeite werd is om te bevestig voordat logika daarheen geskuif word. As die werk aan die diens se lewensiklus behoort eerder as aan ’n enkele verbinding, is ’n systemd-eenheid ’n beter tuiste as enige haak.

Haakopdragte word direk deur die daemon uitgevoer, met geen skel daartussen nie, so ifconfig_remote in ’n up-lyn kom as letterlike teks aan. Wikkel die opdrag in ’n eksplisiete skel, of hou die logika in ’n skrip wat die omgewing lees. ipchange is een riglyn wat sy eie argumente byvoeg: dit gee die adres en poort aan die opdrag, so ’n skrip wat vir geen geskryf is, sien twee onverwagte een.

Drie maniere om die werk los te maak

Die eerste opsie is om die helper van binne die haak in die agtergrond te plaas: begin dit met setsid of systemd-run --scope, sluit die geërfde deskriptore, en verlaat dadelik met nul. Die tweede is om die haak ’n klein toestandsleer te laat skryf en ’n systemd-tydhouer of ’n pad-eenheid daarop te laat reageer, wat die haak eenvoudig hou en die herprobeerbeleid iewers plaas waar daar logs is. Die derde is om die haak heeltemal te laat vaar en die werk na ’n eenheid te skuif wat ná die VPN-diens georden is, wat die regte antwoord is wanneer die werk glad nie per-verbinding is nie. Al drie deel een reël: die haak moet terugkeer voordat dit die tonnel nodig het.

Watter een jy ook kies, maak die helper idempotent en waarneembaar. Twee oorvleuelende aanroepe moet nie dieselfde onomkeerbare aksie twee keer uitvoer nie, en ’n helper wat misluk, moet iets laat wat ’n mens kan lees.

Skei sandbox-foute van lewensiklusfoute

Wanneer ’n skrip van ’n root-prompt af loop en as diens misluk, is die oorsaak gewoonlik ’n sandbox eerder as die netwerk. ’n Beperkende ProtectHome, ’n lees-alleen ProtectSystem, of ’n werkmap wat nie bestaan nie kan die skrip of sy data onbereikbaar laat, en op ’n SELinux-gasheer het die lêer ook ’n konteks nodig wat uitvoering toelaat. Lees die eenheid met systemctl cat openvpn-server@server en die joernaal met journalctl -u openvpn-server@server -n 80, en soek dan na ’n toestemmings- of konteksfout eerder as ’n verbindingstydtans. Om die sandbox te deaktiveer, moet die laaste skuif wees, nie die eerste nie.

’n Lewensiklusfout lyk anders: die haak begin, die helper loop, en die sok is bloot nog nie daar nie. Skryf ’n tydstempel-lyn van die haak self, ontkoppel en herverbind, en lees die gebeurtenisse in volgorde. Wanneer die helper werklik die tonnel nodig het, laat dit vir gereedheid peil eerder as om vir ’n vaste tydperk te slaap.

Drie velde maak die volgende verslag nuttig: watter haak geloop het, watter rekening dit gebruik het, en waar dit gestop het. Sonder hulle begin elke latere ondersoek oor.