OpenVPN-advarslen om flere --up-scripts: kun ét kører

Advarslen om flere scripts lyder som en klage over planlægning, så det oplagte fix er at omarrangere linjerne, indtil den forsvinder. Det er ikke en klage over planlægning. En senere --up-definition erstatter den kommando, der allerede er gemt for det trin, og parseren siger det, hvilket betyder, at præcis ét af dine to scripts nogensinde er kørt. Det andet står ikke i kø bag det; det er væk.

Derfor fortjener advarslen opmærksomhed, selvom den ikke er fatal: det, den forudsiger, er en DNS-opdatering eller en ruteændring, som stille holdt op med at ske.

Advarslen handler ikke om rækkefølge

OpenVPN gemmer én enkelt bruger-scriptkommando til up-trinnet. Når parseren møder en anden definition, fra profilen, en inkluderet fil eller kommandolinjen, erstatter den det, den allerede havde, og udsender advarslen. Intet sammenkædes, intet kører to gange, og der findes intet rækkefølgespørgsmål. Den kommando, der overlever, er den, parseren så sidst, og derfor kan en flyttet linje skifte vinderen, mens det andet script forbliver dødt.

Samme mønster gælder for de øvrige scripttrin: én kommando hver. Hvis to stykker arbejde begge skal ske, har de brug for ét indgangspunkt, ikke to direktiver, der ligner en liste.

Find begge definitioner i den rigtige start

Start med det, daemonen faktisk modtog, ikke med den profil, du redigerede. ps -ef og enhedens ExecStart viser kommandolinjen, som kan tilføje --up fra et container-entrypoint eller en wrapper; en distributions init-fil kan gøre det samme. systemctl cat openvpn-server@server afslører, hvad tjenesten selv bidrager med, og en rekursiv grep over konfigurationsmappen finder filniveau-definitionerne. Dubletter kommer ofte fra forskellige lag, og det er netop derfor, at redigering af én fil ikke ændrer noget.

At kopiere et script til en anden mappe eller omdøbe det fjerner heller ikke et direktiv. Parseren tæller definitioner, ikke filer.

Lad én hook eje arbejdet

Den holdbare løsning er én dispatcher, der kører begge handlinger i en bevidst rækkefølge. Et kort shell-script med set -eu, der kalder den krævede integration og derefter den lokale handling og videresender "$@", så argumentgrænserne overlever, holder adfærden ét sted, der kan revideres. Videresendelse af argumenter bevarer dem kun; det beviser ikke, at de to hjælpere forventer samme interface, så læs hvers kontrakt. Beslut, hvad en fejl skal gøre, og om delvise ændringer skal rulles tilbage.

Hvis launcheren tilbyder en understøttet udvidelseshook, så foretræk den frem for håndlavet kædning. Et container-image eller en leverandørpakke har ofte et dokumenteret sted til ekstra arbejde, og brug af det forhindrer, at en opgradering overskriver din dispatcher.

Oprydning hører til det matchende down-trin. En up-handling, der omskriver DNS eller tilføjer ruter, kræver en dokumenteret tilbagerulning, og en dispatcher, der kun håndterer opstart, er et halvt design.

Bekræft integrationen, ikke bare stilheden

At fjerne dubletadvarslen er den nemme del; integrationen skal stadig virke. Kontroller resolver-tilstanden efter forbindelsen med resolvectl status eller ved at læse /etc/resolv.conf, og bekræft ruterne med ip route. Afbryd og genopret derefter forbindelsen, fordi en hurtigt kædet hook har tendens til at efterlade noget fra den forrige session. journalctl -u openvpn-server@server -b viser, om din dispatcher kørte, og hvad den udskrev.

Hold hookens rettigheder, hvor de hører til. At hæve script-security eller køre daemonen med flere rettigheder er ikke en løsning på en erstattet hook; det udvider, hvad hvert fremtidigt script kan gøre, inklusive et, som en angriber får lov at navngive.

Tegnet på, at rettelsen er reel, er ikke tavshed i loggen. Det er DNS-svaret, ruteindgangen og oprydningen, der alle fungerer efter to genopkoblinger.