DNS z OpenVPN zůstává po SIGKILL: nejprve zkontrolujte vlastníka

DNS přestane překládat poté, co je klient OpenVPN zabit, a prvním instinktem je přepsat /etc/resolv.conf. Tato úprava může rozbít funkční resolver, zatímco skutečný zastaralý stav leží jinde. Otázka, kterou je třeba vyřešit nejdřív, je, kdo vlastní nastavení DNS, které tunel nainstaloval, a zda na výstupu, který přeskočil úklid, skutečně záleželo.

Opravu rozhodují tři podmínky: signál, který proces ukončil, komponenta resolveru, která nastavení převzala, a zda odkaz tunelu stále existuje. Odpovězte na ně v tomto pořadí a oprava obvykle přijde bez zásahu do globálního souboru.

Určete, jaký druh ukončení nastal

V komunitní edici OpenVPN jsou SIGINT i SIGTERM žádostmi o čisté ukončení. SIGKILL nelze zachytit: nelze jej zablokovat ani obsloužit, takže žádná rutina vypnutí nedostane šanci se spustit. Běžné Ctrl+C v terminálu na popředí vygeneruje SIGINT, zatímco správce, který přestane čekat, obvykle eskaluje na SIGKILL. Rozdíl je důležitý, protože jen druhý případ zaručuje, že háčky byly přeskočeny.

Běh uvnitř screen nebo tmux nemění, který signál Ctrl+C posílá. Zkontrolujte, co proces skutečně dostal, ne co terminál obvykle dělá.

Když tunel spouští služba nebo správce připojení, zastavte toto jedno připojení přes jeho vlastníka, místo abyste zabíjeli pid. Správce může proces znovu zvednout a vy zůstanete s novým tunelem a zmateným stavem resolveru. Samostatný proces potřebuje k provedení úklidu jen běžný požadavek na ukončení.

Určete, kdo vlastní resolver

systemd-resolved, skript ve stylu resolvconf a prosté přepsání souboru jsou tři různí vlastníci. První drží nastavení pro odkaz v paměti a zahodí je, když rozhraní zmizí. Druhý drží záznamy, které přetrvají, dokud je něco neodstraní. Třetí zapíše soubor a obnovu ponechá tomu, kdo ho zapsal.

Než zvolíte opravný příkaz, určete vlastníka. Stejný symptom má tři různá správná řešení podle toho, který je použit.

VPN spravovaná přes NetworkManager může změny resolveru už vlastnit. Přidání druhého pomocníka navrch vytvoří dva vlastníky soupeřící o stejný odkaz a stav toho, kdo prohrál, se při dalším připojení objeví znovu. Pokud je ve vedení správce, opravte nastavení ve správci, ne ve skriptu.

Co háček down umí a co ne

Skript down se spustí jednou poté, co se zařízení TUN/TAP zavře. Přidání down-pre tento pořádek obrátí a spustí skript, dokud zařízení ještě existuje, což vyžadují pomocníci, kteří potřebují živý odkaz.

Ani jedna direktiva nezajistí, aby se háček spustil po SIGKILL. Oprávnění se také neobnovují pomocí down-pre: pokud démon klesne na user nebo group nebo vstoupí do chroot, háček běží s tím přístupem, který mu to ponechá. Vyvolaný háček přesto může selhat při aktualizaci resolveru. Referenční příručka OpenVPN pokrývá signály a životní cyklus zpětného volání.

Zkontrolujte vlastní chybu háčku vedle návratového stavu procesu. Chybějící úklid a neúspěšný úklid vypadají v resolveru stejně a v záznamech různě.

Zkontrolujte stav, který skutečně zůstává

V systému se systemd-resolved resolvectl status ukazuje, který odkaz stále nese DNS servery VPN nebo domény směrování. Tento odkaz může patřit připojení, které už neexistuje, nebo jinému tunelu, který je stále nahoře.

Rozhraní, které zmizí, si vezme svou konfiguraci pro odkaz s sebou, takže přeskočený háček může existovat vedle čistého DNS. Pokud je odkaz stále registrovaný a vlastní ho výhradně zastavené připojení, vlastnící správce by ho měl odstranit. Pokud starší skript přepsal globální soubor resolveru, hledejte místo toho dokumentovaný krok obnovy toho skriptu.

Obnovte se bez ukradení jiného odkazu

Když je nastavení pro odkaz vaše na starost, resolvectl revert vezme název odkazu a vymaže běžící DNS konfiguraci pro toto rozhraní. Jde o akci za běhu, ne o úpravu profilu, takže trvalá konfigurace připojení zůstane nedotčena. Pojmenujte špatný odkaz a vymažete DNS funkčnímu tunelu, proto název pochází z výstupu stavu.

Ověřte, že /etc/resolv.conf je spravovaný symbolický odkaz, než jej upravíte, poté ještě jednou normálně zastavte klienta a znovu se podívejte na DNS. Pokud druhé zastavení uklidí, dřívější problém byl nucený výstup, ne konfigurace.