De warskôging fan OpenVPN oer meardere --up-skripts: mar ien draait

De warskôging oer meardere skripts klinkt as in klacht oer planning, dus de foar de hân lizzende oplossing is de rigels opnij oardern oant it ferdwynt. It is gjin klacht oer planning. In lettere --up-definysje ferfangt it kommando dat al foar dat stadium bewarre is, en de parser seit dat, wat betsjut dat fan jo twa skripts krekt ien ea draaid hat. It oare stiet net efter it yn ’e rige; it is fuort.

Dêrom fertsjinnet de warskôging oandacht, ek al is it net fataal: wat it foarseit is in DNS-bywurking of in rûteferoaring dy’t stil opholden is te barren.

De warskôging giet net oer oarder

OpenVPN bewarret ien kommando fan brûkersskript foar it stadium up. As de parser in oare definysje tsjinkomt, út it profyl, in ynfoege bestân of de kommandorigel, ferfangt er wat er al hie en jout de warskôging. Neat wurdt gearfoege, neat draait twa kear, en der bestiet gjin oardervraach. It kommando dat oerbliuwt is dat de parser it lêst seach, dêrom kin in rigel ferpleatsen de winner feroarje wylst it oare skript dea bliuwt.

Itselde patroan jildt foar de oare skriptstadia: ien kommando elk. As twa stikken wurk beide barre moatte, hawwe se ien yngongspunt nedich, net twa rjochtlinen dy’t op in list lykje.

Fyn beide definysjes yn ’e echte start

Begjin by wat de daemon eins krigen hat, net by it profyl dat jo bewurke hawwe. ps -ef en de ExecStart fan ’e unit litte de kommandorigel sjen, dy’t --up tafoegje kin út in kontener-yngongspunt of in wrapper; in init-bestân fan in distribúsje kin itselde dwaan. systemctl cat openvpn-server@server lit sjen wat de tsjinst sels bydraacht, en in rekursive grep oer de konfiguraasjemap fynt de definysjes op bestânsnivo. Dûbelingen komme meastentiids út ferskate lagen, en dêrom feroaret it bewurkjen fan ien bestân neat.

In skript nei in oare map kopiearje of it werneame ferwideret ek gjin rjochtline. De parser telt definysjes, gjin bestannen.

Lit ien hook it wurk hawwe

De duorjende oplossing is ien dispatcher dy’t beide aksjes yn in bewuste oarder útfiert. In koart shell-skript mei set -eu dat de fereaske yntegraasje en dêrnei de lokale aksje oanropt en "$@" trochjout sadat argumintgrinzen oerbliuwe, hâldt it gedrach op ien plak dat kontrolearre wurde kin. Arguminten trochjaan bewarret se allinnich; it bewiist net dat de twa helpers deselde ynterface ferwachtsje, dus lês it kontrakt fan elk. Beslis wat in flater dwaan moat en oft partiele feroarings weromdraaid wurde moatte.

As de starter in stipe útwreidingshook biedt, kies dy dan boppe hânmakke keatling. In kontenerbyld of in leveransierspakket hat faak in dokumintearre plak foar ekstra wurk, en it brûken dêrfan hâldt in upgrade tsjin it oerskriuwen fan jo dispatcher.

Opromjen heart by it oerienkommende down-stadium. In up-aksje dy’t DNS oerskriuwt of rûtes tafoeget, hat in dokumintearre weromdraaiing nedich, en in dispatcher dy’t allinnich de start behannelt is in heal ûntwerp.

Befêstigje de yntegraasje, net allinnich de stilte

De dûbele warskôging fuortsmite is it maklike part; de yntegraasje moat noch wurkje. Kontrolearje de resolverstatus nei it ferbinen mei resolvectl status of troch /etc/resolv.conf te lêzen, en befêstigje de rûtes mei ip route. Ferbyn dan en ferbyn opnij, want in hastich keatling fan in hook lit faak wat fan ’e foarige sesje efter. journalctl -u openvpn-server@server -b lit sjen oft jo dispatcher draaid hat en wat er printe.

Hâld de foarrjochten fan ’e hook dêr’t se hearre. script-security ferheegje of de daemon mei mear rjochten draaie litte is gjin oplossing foar in ferfongen hook; it ferbreedt wat elk takomstich skript dwaan kin, ynklusyf ien dy’t in oanfaller neame mei.

It teken dat de oplossing echt is, is net stilte yn it logboek. It is it DNS-antwurd, de rûte-ynskriuwing en it opromjen dy’t allegear wurkje nei twa werferbiningen.