OpenVPN DNS ostaje nakon SIGKILL: prvo provjerite vlasnika

DNS prestaje razrješavati nakon što se OpenVPN klijent ubije, a prvi je poriv prepisati /etc/resolv.conf. Ta promjena može pokvariti ispravan resolver dok stvarno zastarjelo stanje sjedi negdje drugdje. Pitanje koje treba prvo riješiti jest kome pripadaju DNS postavke koje je tunel instalirao i je li izlaz koji je preskočio čišćenje doista bio važan.

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

Odlučite kakav je izlaz nastupio

U Community izdanju OpenVPN, i SIGINT i SIGTERM zahtjevi su za uredan izlaz. SIGKILL se ne može uhvatiti: ne može se blokirati ni obraditi, pa nijedna rutina gašenja ne dobiva priliku pokrenuti se. 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 jamči da su kuke preskočene.

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

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

Odlučite kome pripada resolver

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

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

VPN kojim upravlja NetworkManager možda već posjeduje promjene resolvera. Dodavanje drugog pomoćnika povrh toga stvara dva vlasnika koji se natječu za istu vezu, a stanje gubitnika vraća se pri sljedećem ponovnom povezivanju. Ako je upravitelj zadužen, popravite postavku u upravitelju, a ne u skripti.

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

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

Nijedna direktiva ne čini da se kuka izvrši nakon SIGKILL. Privilegije se također 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 ažurirati resolver. OpenVPN referenca pokriva signale i životni ciklus povratnog poziva.

Provjerite vlastitu pogrešku kuke uz izlazni status procesa. Čišćenje koje nedostaje i čišćenje koje je propalo izgledaju isto u resolveru, a različito u zapisima.

Provjerite stanje koje doista ostaje

Na sustavu koji koristi systemd-resolved, resolvectl status pokazuje koja veza još nosi VPN DNS poslužitelje ili domene usmjeravanja. Ta veza može pripadati spoju kojeg više nema ili drugom tunelu koji je još podignut.

Sučelje koje nestane nosi sa sobom svoju konfiguraciju po vezi, pa preskočena kuka može postojati uz čist DNS. Ako je veza još registrirana i isključivo ju posjeduje zaustavljeni spoj, upravitelj koji ju posjeduje trebao bi je ukloniti. Ako je starija skripta prepisala globalnu datoteku resolvera, tražite umjesto toga dokumentirani korak vraćanja te skripte.

Oporavite se bez otimanja druge veze

Kada su postavke po vezi vaše za upravljanje, resolvectl revert uzima naziv veze i briše DNS konfiguraciju u vrijeme izvođenja za to sučelje. To je radnja u vrijeme izvođenja, a ne uređivanje profila, pa trajna konfiguracija spoja ostaje netaknuta. Imenujete li pogrešnu vezu, obrisat ćete DNS tunela koji radi, zato naziv dolazi iz izlaza statusa.

Potvrdite da je /etc/resolv.conf upravljana simbolička veza prije nego što ju uredite, zatim još jednom normalno zaustavite klijenta i ponovno pogledajte DNS. Ako drugo zaustavljanje očisti, raniji problem bio je prisilni izlaz, a ne konfiguracija.