OpenVPN-DNS blir liggende etter SIGKILL: sjekk eieren først

DNS slutter å slå opp etter at en OpenVPN-klient er drept, og den første innskytelsen er å skrive om /etc/resolv.conf. Den endringen kan ødelegge en fungerende resolver mens den egentlige utdaterte tilstanden ligger et annet sted. Spørsmålet som må avklares først, er hvem som eier DNS-innstillingene tunnelen installerte, og om avslutningen som hoppet over oppryddingen faktisk betydde noe.

Tre forhold avgjør reparasjonen: signalet som avsluttet prosessen, resolverkomponenten som mottok innstillingene, og om tunnellenken fortsatt finnes. Svar på dem i den rekkefølgen, og rettelsen følger vanligvis uten å røre en global fil.

Avgjør hva slags avslutning som skjedde

I Community-utgaven av OpenVPN er både SIGINT og SIGTERM forespørsler om en ryddig avslutning. SIGKILL kan ikke fanges: det kan verken blokkeres eller håndteres, så ingen nedstengningsrutine får en sjanse til å kjøre. En vanlig Ctrl+C i en terminal i forgrunnen genererer SIGINT, mens en overvåker som gir opp å vente, vanligvis eskalerer til SIGKILL. Forskjellen betyr noe fordi bare det andre tilfellet garanterer at krokene ble hoppet over.

Det endrer ikke hvilket signal Ctrl+C sender, å kjøre inne i screen eller tmux. Sjekk hva prosessen faktisk mottok, ikke hva terminalen vanligvis gjør.

Når en tjeneste eller tilkoblingsbehandler kjører tunnelen, stopp den ene tilkoblingen gjennom eieren i stedet for å drepe pid-en. En behandler kan starte prosessen igjen og etterlate deg med en ny tunnel og en forvirrende resolvertilstand. En frittstående prosess trenger bare en vanlig avslutningsforespørsel for at oppryddingen skal kjøre.

Avgjør hvem som eier resolveren

systemd-resolved, et skript i resolvconf-stil og en enkel filskriving er tre forskjellige eiere. Den første holder innstillinger per lenke i minnet og slipper dem når grensesnittet forsvinner. Den andre holder poster som varer til noe fjerner dem. Den tredje skriver en fil og overlater gjenopprettingen til den som skrev den.

Identifiser eieren før du velger en reparasjonskommando. Det samme symptomet har tre forskjellige riktige svar avhengig av hvilken som er i bruk.

En VPN som styres av NetworkManager kan allerede eie resolverendringene. Legger du til en andre hjelper på toppen, får du to eiere som konkurrerer om samme lenke, og taperens tilstand dukker opp igjen ved neste gjenoppkobling. Hvis en behandler har ansvaret, rett innstillingen i behandleren i stedet for i et skript.

Hva down-kroken kan og ikke kan

Skriptet down kjøres én gang etter at TUN/TAP-enheten er lukket. Å legge til down-pre snur den rekkefølgen og kjører skriptet mens enheten fortsatt finnes, noe hjelpere som trenger den levende lenken krever.

Ingen av direktivene får en krok til å kjøre etter SIGKILL. Privilegier gjenopprettes heller ikke av down-pre: hvis daemonen går ned til en user eller group eller går inn i en chroot, kjører kroken med den tilgangen det etterlater. En kalt krok kan fortsatt mislykkes med å oppdatere resolveren. OpenVPN-referansen dekker signalene og livssyklusen til tilbakekallet.

Sjekk krokens egen feil ved siden av prosessens avslutningsstatus. Manglende opprydding og mislykket opprydding ser like ut i resolveren og forskjellige ut i loggene.

Sjekk tilstanden som faktisk er igjen

På et system som bruker systemd-resolved, viser resolvectl status hvilken lenke som fortsatt bærer VPN-ens DNS-servere eller rutingsdomener. Den lenken kan tilhøre en tilkobling som er borte, eller en annen tunnel som fortsatt er oppe.

Et grensesnitt som forsvinner tar med seg konfigurasjonen per lenke, så en hoppet-over krok kan sameksistere med ren DNS. Hvis lenken fortsatt er registrert og utelukkende eies av den stoppede tilkoblingen, bør behandleren som eier den fjerne den. Hvis et eldre skript skrev om en global resolverfil, se etter det skriptets dokumenterte gjenopprettingstrinn i stedet.

Gjenopprett uten å stjele en annen lenke

Når innstillinger per lenke er ditt ansvar å styre, resolvectl revert tar lenkenavnet og tømmer kjøretids-DNS-konfigurasjonen for grensesnittet. Det er en kjøretidshandling og ikke en profilendring, så den vedvarende tilkoblingskonfigurasjonen forblir urørt. Navngir du feil lenke, tømmer du DNS for en fungerende tunnel, og derfor kommer navnet fra statusutskriften.

Bekreft at /etc/resolv.conf er en administrert symbolsk lenke før du redigerer den, og stopp deretter klienten normalt én gang til og se på DNS igjen. Hvis den andre stoppen rydder opp, var det tidligere problemet den tvungne avslutningen og ikke konfigurasjonen.