OpenVPN-advarselen om flere --up-skript: bare én kjører

Advarselen om flere skript høres ut som en klage på planlegging, så den åpenbare løsningen er å omorganisere linjene til den forsvinner. Det er ikke en klage på planlegging. En senere --up-definisjon erstatter kommandoen som allerede er lagret for det trinnet, og parseren sier det, noe som betyr at av de to skriptene dine har nøyaktig ett noen gang kjørt. Det andre står ikke i kø bak det; det er borte.

Derfor fortjener advarselen oppmerksomhet selv om den ikke er fatal: det den forutsier, er en DNS-oppdatering eller en ruteendring som stille sluttet å skje.

Advarselen handler ikke om rekkefølge

OpenVPN lagrer én enkelt brukerskriptkommando for up-trinnet. Når parseren møter en annen definisjon, fra profilen, en inkludert fil eller kommandolinjen, erstatter den det den allerede hadde, og sender advarselen. Ingenting sammenkobles, ingenting kjører to ganger, og det finnes ikke noe rekkefølgespørsmål. Kommandoen som overlever, er den parseren så sist, og derfor kan en flyttet linje endre vinneren mens det andre skriptet forblir dødt.

Samme mønster gjelder for de andre skripttrinnene: én kommando hver. Hvis to stykker arbeid begge må skje, trenger de ett inngangspunkt, ikke to direktiver som ligner en liste.

Finn begge definisjonene i den virkelige oppstarten

Start med det daemonen faktisk mottok, ikke med profilen du redigerte. ps -ef og enhetens ExecStart viser kommandolinjen, som kan legge til --up fra et container-entrypoint eller en wrapper; en distribusjons init-fil kan gjøre det samme. systemctl cat openvpn-server@server avslører hva tjenesten selv bidrar med, og en rekursiv grep i konfigurasjonsmappen finner filnivådefinisjonene. Duplikater kommer ofte fra forskjellige lag, og det er nettopp derfor redigering av én fil ikke endrer noe.

Å kopiere et skript til en annen mappe eller gi det nytt navn fjerner heller ikke et direktiv. Parseren teller definisjoner, ikke filer.

La én hook eie arbeidet

Den varige løsningen er én dispatcher som kjører begge handlingene i en bevisst rekkefølge. Et kort shell-skript med set -eu som kaller den nødvendige integrasjonen og deretter den lokale handlingen og videresender "$@" slik at argumentgrensene overlever, holder atferden på ett sted som kan revideres. Å videresende argumenter bevarer dem bare; det beviser ikke at de to hjelperne forventer samme grensesnitt, så les hver enkelts kontrakt. Bestem hva en feil skal gjøre, og om delvise endringer må rulles tilbake.

Hvis oppstarteren tilbyr en støttet utvidelseshook, foretrekk den framfor håndlaget kjetting. Et container-image eller en leverandørpakke har ofte et dokumentert sted for ekstra arbeid, og å bruke det hindrer en oppgradering i å overskrive dispatcheren din.

Opprydding hører til det tilsvarende down-trinnet. En up-handling som skriver om DNS eller legger til ruter, trenger en dokumentert tilbakerulling, og en dispatcher som bare håndterer oppstart, er et halvt design.

Bekreft integrasjonen, ikke bare stillheten

Å fjerne duplikatadvarselen er den enkle delen; integrasjonen må fortsatt virke. Sjekk resolverens tilstand etter tilkobling med resolvectl status eller ved å lese /etc/resolv.conf, og bekreft rutene med ip route. Koble så fra og til igjen, fordi en raskt kjedet hook har en tendens til å etterlate noe fra forrige økt. journalctl -u openvpn-server@server -b viser om dispatcheren din kjørte, og hva den skrev ut.

Hold hookens rettigheter der de hører hjemme. Å heve script-security eller kjøre daemonen med flere rettigheter er ikke en løsning på en erstattet hook; det utvider hva hvert framtidig skript kan gjøre, inkludert et som en angriper får navngi.

Tegnet på at rettelsen er ekte, er ikke stillhet i loggen. Det er DNS-svaret, ruteoppføringen og oppryddingen som alle virker etter to gjenoppkoblinger.