OpenVPN DNS ostaje nakon SIGKILL: prvo provjerite vlasnika

DNS prestaje da se razrješava nakon što se OpenVPN klijent ubije, a prvi instinkt je prepisati /etc/resolv.conf. Ta izmjena može pokvariti ispravan resolver dok stvarno zastarjelo stanje sjedi negdje drugdje. Pitanje koje treba prvo riješiti jeste ko posjeduje DNS postavke koje je tunel instalirao i da li je izlaz koji je preskočio čišćenje zaista bio važan.

Tri uslova odlučuju popravku: signal koji je završio proces, komponenta resolvera koja je primila postavke i da li link tunela još postoji. Odgovorite na njih tim redom i popravka obično slijedi bez diranja globalne datoteke.

Odlučite kakav je izlaz nastupio

U Community OpenVPN, i SIGINT i SIGTERM su zahtjevi za uredan izlaz. SIGKILL se ne može uhvatiti: ne može se blokirati ni obraditi, pa nijedna rutina gašenja ne dobija priliku da se izvrši. Običan Ctrl+C u terminalu u prvom planu stvara SIGINT, dok supervizor koji odustane od čekanja obično eskalira na SIGKILL. Razlika je važna jer samo drugi slučaj garantuje da su kuke preskočene.

Rad unutar screen ili tmux ne mijenja koji signal šalje Ctrl+C. Provjerite šta je proces zaista primio, a ne šta terminal obično radi.

Kada tunel pokreće servis ili menadžer veza, zaustavite tu jednu vezu kroz njenog vlasnika umjesto da ubijete pid. Menadžer može ponovo podići proces, ostavljajući vam nov tunel i zbunjujuće stanje resolvera. Samostalnom procesu je potreban samo običan zahtjev za prekid da bi se čišćenje izvršilo.

Odlučite ko posjeduje resolver

systemd-resolved, skripta u stilu resolvconf i obično prepisivanje datoteke su tri različita vlasnika. Prvi drži postavke po linku u memoriji i odbacuje ih kada interfejs nestane. Drugi drži zapise koji ostaju dok ih nešto ne ukloni. Treći upisuje datoteku i prepušta vraćanje onome ko ju je upisao.

Identifikujte vlasnika prije nego što odaberete naredbu za popravku. Isti simptom ima tri različita tačna odgovora ovisno o tome koji je u upotrebi.

VPN kojim upravlja NetworkManager možda već posjeduje promjene resolvera. Dodavanje drugog pomoćnika preko toga stvara dva vlasnika koji se takmiče za isti link, a stanje gubitnika se vraća pri sljedećem ponovnom povezivanju. Ako je menadžer zadužen, popravite postavku u menadžeru, a ne u skripti.

Šta down kuka može i ne može

Skripta down se izvršava jednom nakon što se TUN/TAP uređaj zatvori. Dodavanje down-pre obrće taj redoslijed i izvršava skriptu dok uređaj još postoji, što zahtijevaju pomoćnici kojima treba živi link.

Nijedna direktiva ne čini da se kuka izvrši nakon SIGKILL. Privilegije se takođe ne vraćaju pomoću down-pre: ako se demon spusti na user ili group ili uđe u chroot, kuka radi s onim pristupom koji joj to ostavi. Pozvana kuka ipak može propustiti da ažurira resolver. OpenVPN referenca pokriva signale i životni ciklus povratnog poziva.

Provjerite vlastitu grešku kuke pored izlaznog statusa procesa. Čišćenje koje nedostaje i čišćenje koje je propalo izgledaju isto u resolveru, a različito u zapisima.

Provjerite stanje koje zaista ostaje

Na sistemu koji koristi systemd-resolved, resolvectl status pokazuje koji link još nosi VPN DNS servere ili domene rutiranja. Taj link može pripadati vezi koje više nema ili drugom tunelu koji je još podignut.

Interfejs koji nestane nosi sa sobom svoju konfiguraciju po linku, pa preskočena kuka može postojati uz čist DNS. Ako je link još registrovan i isključivo ga posjeduje zaustavljena veza, menadžer koji ga posjeduje treba da ga ukloni. Ako je starija skripta prepisala globalnu datoteku resolvera, tražite umjesto toga dokumentovani korak vraćanja te skripte.

Oporavite se bez otimanja drugog linka

Kada su postavke po linku vaše za upravljanje, resolvectl revert uzima ime linka i briše DNS konfiguraciju u vrijeme izvršavanja za taj interfejs. To je radnja u vrijeme izvršavanja, a ne izmjena profila, pa trajna konfiguracija veze ostaje netaknuta. Imenujte pogrešan link i obrisat ćete DNS za tunel koji radi, zato ime dolazi iz izlaza statusa.

Potvrdite da je /etc/resolv.conf upravljani simbolički link prije nego što ga uredite, zatim još jednom normalno zaustavite klijenta i ponovo pogledajte DNS. Ako drugo zaustavljanje očisti, raniji problem je bio prisilni izlaz, a ne konfiguracija.