OpenVPN’s waarschuwing over meerdere --up-scripts: slechts één draait

De waarschuwing over meerdere scripts klinkt als een klacht over planning, dus de voor de hand liggende oplossing is de regels herordenen tot hij verdwijnt. Het is geen klacht over planning. Een latere --up-definitie vervangt het commando dat al voor die fase is opgeslagen, en de parser zegt dat ook, wat betekent dat van uw twee scripts er ooit precies één is uitgevoerd. Het andere staat niet achteraan in de rij; het is weg.

Daarom verdient de waarschuwing aandacht, ook al is ze niet fataal: wat ze voorspelt, is een DNS-update of een routewijziging die stilletjes ophield te gebeuren.

De waarschuwing gaat niet over volgorde

OpenVPN bewaart één enkel gebruikersscriptcommando voor de up-fase. Wanneer de parser een andere definitie tegenkomt, uit het profiel, een inbegrepen bestand of de opdrachtregel, vervangt hij wat hij al had en geeft de waarschuwing. Niets wordt samengevoegd, niets draait twee keer, en er bestaat geen volgordevraag. Het commando dat overleeft, is het commando dat de parser het laatst zag, daarom kan een regel verplaatsen de winnaar veranderen terwijl het andere script dood blijft.

Hetzelfde patroon geldt voor de andere scriptfasen: één commando elk. Als twee stukken werk beide moeten gebeuren, hebben ze één ingangspunt nodig, niet twee richtlijnen die op een lijst lijken.

Vind beide definities in de echte start

Begin bij wat de daemon werkelijk ontving, niet bij het profiel dat u hebt bewerkt. ps -ef en de ExecStart van de unit tonen de opdrachtregel, waaraan --up kan worden toegevoegd vanuit een container-entrypoint of een wrapper; een init-bestand van een distributie kan hetzelfde doen. systemctl cat openvpn-server@server onthult wat de dienst zelf bijdraagt, en een recursieve grep over de configuratiemap vindt de definities op bestandsniveau. Duplicaten komen meestal uit verschillende lagen, en dat is precies waarom het bewerken van één bestand niets verandert.

Een script naar een andere map kopiëren of hernoemen verwijdert ook geen richtlijn. De parser telt definities, geen bestanden.

Laat één hook het werk bezitten

De duurzame oplossing is één dispatcher die beide acties in een weloverwogen volgorde uitvoert. Een kort shellscript met set -eu dat de vereiste integratie en daarna de lokale actie aanroept en "$@" doorgeeft zodat argumentgrenzen overleven, houdt het gedrag op één auditabele plek. Argumenten doorgeven bewaart ze alleen; het bewijst niet dat de twee helpers dezelfde interface verwachten, dus lees ieders contract. Beslis wat een fout moet doen en of gedeeltelijke wijzigingen moeten worden teruggedraaid.

Als de starter een ondersteunde uitbreidingshook biedt, geef die dan de voorkeur boven handmatige koppeling. Een containerimage of een leverancierspakket heeft vaak een gedocumenteerde plek voor extra werk, en het gebruik ervan voorkomt dat een upgrade uw dispatcher overschrijft.

Opruimen hoort bij de bijbehorende down-fase. Een up-actie die DNS herschrijft of routes toevoegt, heeft een gedocumenteerde terugdraaiing nodig, en een dispatcher die alleen de start afhandelt, is een half ontwerp.

Bevestig de integratie, niet alleen de stilte

De dubbele waarschuwing weghalen is het makkelijke deel; de integratie moet nog steeds werken. Controleer de resolverstatus na het verbinden met resolvectl status of door /etc/resolv.conf te lezen, en bevestig de routes met ip route. Verbreek daarna de verbinding en maak opnieuw verbinding, want een haastig gekoppelde hook laat vaak iets van de vorige sessie achter. journalctl -u openvpn-server@server -b laat zien of uw dispatcher liep en wat hij afdrukte.

Houd de rechten van de hook waar ze horen. script-security verhogen of de daemon met meer rechten laten draaien is geen oplossing voor een vervangen hook; het verruimt wat elk toekomstig script kan doen, ook een dat een aanvaller mag benoemen.

Het teken dat de oplossing echt is, is geen stilte in het log. Het zijn het DNS-antwoord, de routevermelding en het opruimen die allemaal werken na twee herverbindingen.