DNS OpenVPN ostane po SIGKILL: najprej preverite lastnika

DNS preneha razreševati, potem ko je odjemalec OpenVPN ubit, in prvi vzgib je prepisati /etc/resolv.conf. Ta sprememba lahko pokvari delujoč resolver, medtem ko je pravo zastarelo stanje drugje. Najprej je treba razrešiti vprašanje, kdo ima nastavitve DNS, ki jih je namestil tunel, in ali je izhod, ki je preskočil čiščenje, res imel pomen.

Popravilo določajo trije pogoji: signal, ki je končal proces, komponenta resolverja, ki je prejela nastavitve, in ali povezava tunela še obstaja. Odgovorite v tem vrstnem redu in popravek običajno sledi brez poseganja v globalno datoteko.

Ugotovite, kakšna vrsta izhoda se je zgodila

V izdaji Community OpenVPN sta tako SIGINT kot SIGTERM zahtevi za urejen izhod. SIGKILL ni mogoče ujeti: ni ga mogoče blokirati ali obdelati, zato nobena rutina za zaustavitev ne dobi priložnosti za izvajanje. Običajen Ctrl+C v terminalskem oknu v ospredju ustvari SIGINT, medtem ko nadzornik, ki preneha čakati, običajno stopnjuje na SIGKILL. Razlika je pomembna, ker le drugi primer zagotavlja, da so bili kaveljčki preskočeni.

Izvajanje v screen ali tmux ne spremeni, kateri signal pošlje Ctrl+C. Preverite, kaj je proces dejansko prejel, ne kaj običajno počne terminal.

Ko tunel izvaja storitev ali upravitelj povezav, ustavite to eno povezavo prek njenega lastnika, namesto da ubijete pid. Upravitelj lahko proces znova dvigne in ostane vam nov tunel ter zmedeno stanje resolverja. Samostojen proces za izvedbo čiščenja potrebuje le običajno zahtevo za zaustavitev.

Ugotovite, kdo ima resolver

systemd-resolved, skripta v slogu resolvconf in preprosto prepisovanje datoteke so trije različni lastniki. Prvi hrani nastavitve za povezavo v pomnilniku in jih zavrže, ko vmesnik izgine. Drugi hrani zapise, ki ostanejo, dokler jih nekaj ne odstrani. Tretji zapiše datoteko in obnovitev prepusti tistemu, ki jo je zapisal.

Pred izbiro popravljalnega ukaza ugotovite lastnika. Isti simptom ima tri različne pravilne odgovore glede na to, kateri je v uporabi.

VPN, ki ga upravlja NetworkManager, lahko že ima spremembe resolverja. Dodajanje drugega pomočnika na vrh ustvari dva lastnika, ki tekmujeta za isto povezavo, in stanje poraženca se ob naslednjem ponovnem povezovanju spet pojavi. Če je odgovoren upravitelj, popravite nastavitev v upravitelju in ne v skripti.

Kaj kaveljček down zmore in česa ne

Skripta down se izvede enkrat po tem, ko se naprava TUN/TAP zapre. Dodajanje down-pre obrne ta vrstni red in izvede skripto, medtem ko naprava še obstaja, kar zahtevajo pomočniki, ki potrebujejo živo povezavo.

Nobena direktiva ne poskrbi, da bi se kaveljček izvedel po SIGKILL. Tudi privilegiji se ne obnovijo s down-pre: če se demon spusti na user ali group ali vstopi v chroot, kaveljček teče z dostopom, ki mu ga to pusti. Poklican kaveljček lahko vseeno ne uspe posodobiti resolverja. Referenca OpenVPN pokriva signale in življenjski cikel povratnega klica.

Preverite lastno napako kaveljčka ob izhodnem stanju procesa. Manjkajoče čiščenje in neuspešno čiščenje sta v resolverju videti enako, v dnevnikih pa različno.

Preverite stanje, ki v resnici ostane

V sistemu, ki uporablja systemd-resolved, resolvectl status pokaže, katera povezava še vedno nosi strežnike DNS za VPN ali domene usmerjanja. Ta povezava lahko pripada povezavi, ki je ni več, ali drugemu tunelu, ki je še dvignjen.

Vmesnik, ki izgine, s seboj odnese svojo konfiguracijo za povezavo, zato lahko preskočen kaveljček obstaja skupaj s čistim DNS. Če je povezava še vedno registrirana in jo ima izključno ustavljena povezava, naj jo upravitelj, ki jo ima, odstrani. Če je starejša skripta prepisala globalno datoteko resolverja, raje poiščite dokumentiran korak obnovitve te skripte.

Obnovite, ne da bi ukradli drugo povezavo

Ko so nastavitve za povezavo vaša odgovornost, resolvectl revert vzame ime povezave in počisti konfiguracijo DNS v času izvajanja za ta vmesnik. To je dejanje v času izvajanja in ne urejanje profila, zato trajna konfiguracija povezave ostane nedotaknjena. Če imenujete napačno povezavo, počistite DNS delujočega tunela, zato ime izhaja iz izhoda stanja.

Pred urejanjem potrdite, da je /etc/resolv.conf upravljana simbolična povezava, nato še enkrat običajno ustavite odjemalca in znova poglejte DNS. Če druga zaustavitev počisti, je bila prejšnja težava prisilni izhod in ne konfiguracija.