DNS OpenVPN zostáva po SIGKILL: najprv skontrolujte vlastníka

DNS prestane prekladať po tom, ako je klient OpenVPN zabitý, a prvým inštinktom je prepísať /etc/resolv.conf. Táto úprava môže pokaziť funkčný resolver, kým skutočný zastaraný stav leží inde. Otázka, ktorú treba vyriešiť najprv, je, kto vlastní nastavenia DNS, ktoré tunel nainštaloval, a či na výstupe, ktorý preskočil čistenie, skutočne záležalo.

Opravu rozhodujú tri podmienky: signál, ktorý proces ukončil, komponent resolvera, ktorý nastavenia prevzal, a či spojenie tunela stále existuje. Odpovedzte v tomto poradí a oprava zvyčajne príde bez zásahu do globálneho súboru.

Určite, aký druh ukončenia nastal

V komunitnom vydaní OpenVPN sú SIGINT aj SIGTERM žiadosťami o čisté ukončenie. SIGKILL nemožno zachytiť: nemožno ho zablokovať ani obslúžiť, takže žiadna rutina vypnutia nedostane šancu spustiť sa. Bežné Ctrl+C v termináli v popredí vygeneruje SIGINT, zatiaľ čo správca, ktorý prestane čakať, zvyčajne eskaluje na SIGKILL. Rozdiel je dôležitý, pretože iba druhý prípad zaručuje, že háky boli preskočené.

Beh vnútri screen alebo tmux nemení, ktorý signál Ctrl+C posiela. Skontrolujte, čo proces skutočne dostal, nie čo terminál zvyčajne robí.

Keď tunel spúšťa služba alebo správca pripojení, zastavte toto jedno pripojenie cez jeho vlastníka, namiesto zabíjania pid. Správca môže proces znova zdvihnúť a vy zostanete s novým tunelom a zmäteným stavom resolvera. Samostatný proces potrebuje na spustenie čistenia iba bežnú žiadosť o ukončenie.

Určite, kto vlastní resolver

systemd-resolved, skript v štýle resolvconf a prosté prepísanie súboru sú traja rôzni vlastníci. Prvý drží nastavenia pre spojenie v pamäti a zahodí ich, keď rozhranie zmizne. Druhý drží záznamy, ktoré pretrvajú, kým ich niečo neodstráni. Tretí zapíše súbor a obnovu ponechá tomu, kto ho zapísal.

Pred výberom opravného príkazu určite vlastníka. Ten istý príznak má tri rôzne správne riešenia podľa toho, ktorý sa používa.

VPN spravovaná cez NetworkManager môže už vlastniť zmeny resolvera. Pridanie druhého pomocníka navrch vytvorí dvoch vlastníkov súperiacich o to isté spojenie a stav toho, kto prehral, sa pri ďalšom pripojení objaví znova. Ak je zodpovedný správca, opravte nastavenie v správcovi, nie v skripte.

Čo hák down dokáže a čo nie

Skript down sa spustí raz po zatvorení zariadenia TUN/TAP. Pridanie down-pre obráti toto poradie a spustí skript, kým zariadenie ešte existuje, čo vyžadujú pomocníci, ktorí potrebujú živé spojenie.

Ani jedna direktíva nezaistí, aby sa hák spustil po SIGKILL. Oprávnenia sa tiež neobnovujú pomocou down-pre: ak démon klesne na user alebo group alebo vstúpi do chroot, hák beží s tým prístupom, ktorý mu to ponechá. Vyvolaný hák však môže zlyhať pri aktualizácii resolvera. Referenčná príručka OpenVPN pokrýva signály a životný cyklus spätného volania.

Skontrolujte vlastnú chybu háku vedľa návratového stavu procesu. Chýbajúce čistenie a neúspešné čistenie vyzerajú v resolveri rovnako a v záznamoch inak.

Skontrolujte stav, ktorý skutočne zostáva

V systéme so systemd-resolved resolvectl status ukazuje, ktoré spojenie ešte nesie DNS servery VPN alebo domény smerovania. Toto spojenie môže patriť pripojeniu, ktoré už neexistuje, alebo inému tunelu, ktorý je stále hore.

Rozhranie, ktoré zmizne, si vezme svoju konfiguráciu pre spojenie so sebou, takže preskočený hák môže existovať vedľa čistého DNS. Ak je spojenie stále registrované a vlastní ho výhradne zastavené pripojenie, vlastniaci správca by ho mal odstrániť. Ak starší skript prepísal globálny súbor resolvera, hľadajte namiesto toho dokumentovaný krok obnovy toho skriptu.

Obnovte bez ukradnutia iného spojenia

Keď je nastavenie pre spojenie vašou zodpovednosťou, resolvectl revert vezme názov spojenia a vymaže runtime DNS konfiguráciu pre toto rozhranie. Je to akcia za behu, nie úprava profilu, takže trvalá konfigurácia pripojenia zostane nedotknutá. Pomenujte nesprávne spojenie a vymažete DNS funkčného tunela, preto názov pochádza z výstupu stavu.

Overte, že /etc/resolv.conf je spravovaný symbolický odkaz, skôr než ho upravíte, potom ešte raz normálne zastavte klienta a znova sa pozrite na DNS. Ak druhé zastavenie vyčistí, skorší problém bol nútený výstup, nie konfigurácia.