DNS for OpenVPN ligger igjen etter SIGKILL: sjekk eierforholdet først

DNS slutter å løse navn etter at en OpenVPN-klient er drept, og det første en tenker på er å skrive om /etc/resolv.conf. En slik endring kan ødelegge en resolver som virker, mens den virkelige utdaterte tilstanden befinner seg et annet sted. Det første spørsmålet å avklare er hvem som eier DNS-oppsettet tunnelen la inn, og om avslutningen som hoppet over oppryddingen egentlig spilte noen rolle.

Tre forhold bestemmer reparasjonen: signalet som avsluttet prosessen, den resolverdelen som tok imot oppsettet, og om tunnellenken fremdeles eksisterer. Besvar dem i denne rekkefølgen, så følger rettelsen normalt uten å berøre en global fil.

Bestem hvilken type avslutning som fant sted

I Community-utgaven av OpenVPN er både SIGINT og SIGTERM anmodninger om en kontrollert avslutning. SIGKILL kan ikke fanges: det kan verken blokkeres eller håndteres, så ingen avslutningsrutine får mulighet til å kjøre. En vanlig Ctrl+C i en terminal i forgrunnen gir SIGINT, mens en vakt som slutter å vente, vanligvis trapper opp til SIGKILL. Forskjellen har betydning fordi bare det siste tilfellet garanterer at krokene ble hoppet over.

Å kjøre inne i screen eller tmux endrer ikke hvilket signal Ctrl+C sender. Kontroller hva prosessen faktisk mottok, ikke hva terminalen pleier å gjøre.

Når en tjeneste eller en tilkoblingsbehandler kjører tunnelen, bør du stoppe nettopp denne tilkoblingen gjennom eieren i stedet for å drepe pid-en. En behandler kan få prosessen opp igjen, og du sitter igjen med en ny tunnel og en forvirrende resolvertilstand. En frittstående prosess trenger bare en vanlig avslutningsanmodning for at oppryddingen skal kjøre.

Bestem hvem som eier resolveren

systemd-resolved, et skript i resolvconf-stil og en enkel filoverskriving er tre forskjellige eiere. Den første holder oppsettet per lenke i minnet og slipper det når grensesnittet forsvinner. Den andre holder oppføringer som består helt til noe fjerner dem. Den tredje skriver en fil og lar gjenopprettingen ligge hos den som skrev den.

Fastslå 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. Setter du inn en ekstra hjelper på toppen, oppstår to eiere som konkurrerer om samme lenke, og tilstanden til den som taper, dukker opp igjen ved neste gjenoppkobling. Er det en behandler som har ansvaret, retter du oppsettet der og ikke i et skript.

Hva down-kroken kan og ikke kan gjøre

Skriptet down kjøres én gang etter at TUN/TAP-enheten er lukket. Legger du til down-pre blir rekkefølgen snudd, og skriptet kjøres mens enheten ennå eksisterer, noe hjelpere som trenger den levende lenken forutsetter.

Ingen av de to direktivene får en krok til å kjøre etter SIGKILL. Rettigheter blir heller ikke gjenopprettet av down-pre: dersom daemonen faller ned til en user eller group eller går inn i en chroot, kjører kroken med den tilgangen det gir den. En krok som kalles opp, kan likevel mislykkes med å oppdatere resolveren. OpenVPN-referansen dekker signalene og livsløpet til tilbakekallet.

Se på feilen fra kroken selv ved siden av prosessens avslutningsstatus. Manglende opprydding og mislykket opprydding ser like ut i resolveren og forskjellige ut i loggen.

Kontroller tilstanden som faktisk blir igjen

På et system som bruker systemd-resolved, viser resolvectl status hvilken lenke som fremdeles bærer DNS-serverne eller rutingsdomenene til VPN-en. Den lenken kan høre til en tilkobling som er borte, eller til en annen tunnel som fremdeles er oppe.

Et grensesnitt som forsvinner, tar med seg oppsettet per lenke, så en hoppet-over krok kan eksistere sammen med ren DNS. Er lenken fremdeles registrert og utelukkende eid av den stoppede tilkoblingen, bør behandleren som eier den, fjerne den. Har et eldre skript skrevet om en global resolverfil, bør du i stedet lete etter det dokumenterte gjenopprettingstrinnet til det skriptet.

Gjenopprett uten å stjele en annen lenke

Når oppsettet per lenke er ditt ansvar, resolvectl revert tar lenkenavnet og tømmer kjøretids-DNS-oppsettet for grensesnittet. Dette er en kjøretidshandling og ikke en profilendring, så det varige tilkoblingsoppsettet forblir urørt. Oppgir du feil lenke, tømmer du DNS for en tunnel som virker, og derfor hentes navnet fra statusutskriften.

Kontroller at /etc/resolv.conf er en administrert symbolsk lenke før du redigerer den, og stopp deretter klienten på vanlig måte én gang til og se på DNS igjen. Rydder den andre stoppet opp, var det tidligere problemet den tvungne avslutningen og ikke oppsettet.