Úprava resolv.conf neopraví DNS po odpojení VPN

Odpojíte VPN, ping 1.1.1.1 stále odpovídá a každé hledání jména visí, než to stránka nakonec vzdá. Pak cat /etc/resolv.conf ukáže jmenný server, který kdy existoval jen uvnitř tunelu, obvykle první v seznamu. Smazání toho řádku vypadá, že to spraví na zhruba deset minut, dokud ho spánek, roaming Wi-Fi nebo restart nevrátí zpět. Soubor, který jste upravili, není nastavení; je to vykreslení stavu spoje, který vlastní jiná komponenta.

Proč jeden zastaralý záznam stojí sekundy na každý dotaz

Resolver glibc prochází seznam jmenných serverů popořadě a vyčká timeout, než zkusí další, a resolv.conf(5) omezuje tento seznam na tři záznamy. Dejte resolver na straně tunelu, například 10.8.0.1, na začátek poté, co tunel zmizel, a každý dotaz zaplatí timeout, než propadne na server, který odpovídá. Proto symptom vypadá jako mrtvé připojení, a ne jako chyba DNS: prohlížeče blokují, vyprší jim čas a někdy vrátí uloženou adresu, která později zastará.

Vysvětluje to také, proč stížnost přichází jako „internet je rozbitý“. Ping na IP adresu dokazuje, že spoj je v pořádku, což dělá závadu podobnou aplikaci. Seznam resolverů je první věc, kterou je třeba přečíst, a poslední, kterou je třeba upravovat.

Mýtus: resolv.conf je konfigurační soubor

Než ho změníte, zeptejte se, co ta cesta vlastně je:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

Na hostiteli se systemd-resolved je to symbolický odkaz na stub soubor ukazující na 127.0.0.53 a skutečné servery žijí ve stavu pro jednotlivá spojení, který vypisuje resolvectl. Na hostiteli s NetworkManagerem to může být soubor, který NetworkManager zapisuje z aktivního připojení. U některých klientských programů výrobců je to obyčejný soubor přepisovaný na místě při připojení a, pokud nemáte štěstí, nikdy neobnovený při odpojení. To jsou tři různí vlastníci a ruční úprava prvních dvou buď nic nedělá, nebo vydrží do další síťové události.

resolvectl status je pohled, který říká pravdu: DNS servery pro jednotlivá spojení, směrovací domény a zda spoj tunelu ještě existuje. resolvectl query example.com jde dál a ukazuje, které rozhraní odpovědělo. Použijte obojí, než se dotknete souboru, a mějte na paměti, že prohlížeč s vlastním zabezpečeným DNS to vše ignoruje.

Najděte vlastníka, než něco upravíte

Obvykle spolu soutěží tři komponenty o stejné nastavení: systemd-resolved, NetworkManager a to, co nainstaloval klient VPN. Nejprve určete živou:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Pokud je resolved aktivní a symbolický odkaz míří na jeho stub, globální soubor je generovaný výstup a vaše úprava je kosmetická. Pokud spojení vlastní NetworkManager, servery patří profilu připojení, takže oprava je změna vlastnosti přes nmcli, ne úprava souboru. Pokud běží démon výrobce, jen jeho vlastní cesta obnovy přežije další připojení.

Ukliďte stav spoje, který klient zanechal

Zabitý klient nemůže spustit svůj úklidový hák. SIGKILL nelze zachytit vůbec, zatímco SIGINT a SIGTERM ano, takže tunel, který po vynuceném zabití „prostě přestal“, často nechá na místě registraci rozhraní i záznam resolveru. Najděte konkrétní PID a pošlete signál jen jemu:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Nesedejte po pkill -f vpn ani killall vpn, dokud si nepřečtete celý seznam shod. -f porovnává celý příkazový řádek, takže může ukončit obalový skript, relaci editoru nebo nesouvisející proces, jehož cesta ten řetězec obsahuje. Ukončení špatného procesu uprostřed práce je způsob, jak se problém resolveru změní ve ztracený soubor.

resolvectl revert resetuje běhovou DNS konfiguraci toho spoje, což je užší než restart resolveru a mnohem užší než úprava globálního souboru. Pokud spoj tunelu úplně zmizel, systemctl restart NetworkManager znovu sestaví stav připojení a to je krok, ke kterému se zdrojová vlákna stále vracejí. Dávejte pozor na správce služeb s Restart=always, protože může zabitého klienta i jeho DNS nastavení vrátit rovnou zpět.

Druhý směr: dotlačený DNS, který nikdy nedorazil

Zrcadlový obraz zastaralého záznamu je tunel úplně bez použitelného resolveru. Volba DNS v profilu je žádost; komponenta, která spojení spravuje, ji musí předat resolveru. Pokud log ukazuje, že server byl přijat, ale spoj tunelu nenese žádná DNS nastavení, chybí integrace, ne server.

Otestujte předání tím, že ho uděláte ručně, což oddělí „server je špatný“ od „nikdo ho nepoužil“:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Směrovací doména pro vše posílá každé jméno na ten spoj, což je to, co klient plného tunelu chce a co rozdělený DNS nesmí používat. Tato nastavení zmizí při dalším připojení. Chcete-li je v NetworkManageru trvale, vypněte automatický DNS, nastavte server na připojení a přidejte doménu:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Pro firemní tunel, který má odpovídat jen na interní jména, vypište ty zóny s úvodní vlnovkou místo „vše“, aby veřejná jména dál používala místní resolver.

Obchvaty, které se stanou další havárií

Kopírování resolv.conf před připojením a obnovení po něm je legitimní řádek v runbooku a je to obchvat, ne oprava. Selže přesně tehdy, když na tom záleží, protože pád nebo vynucený restart obnovení přeskočí. Zapište to jako obchvat, aby na něm další člověk nestavěl.

Vypnutí systemd-resolved a natvrdo zapsané veřejné servery je druhý oblíbený tah. Dělá připojení a odpojení předvídatelnými a odstraňuje DNS pro jednotlivá spojení pro každou další síť, což rozbíjí rozdělený DNS pro interní jména a maří účel tunelu, který má držet dotazy uvnitř. Instalace resolvconf a připíchnutí veřejných serverů stojí totéž s vrstvou navíc. Berte kterékoli z nich jako diagnostiku: pokud obnoví prohlížení, zjistili jste, že vinna je integrace resolveru, ne že veřejné servery jsou správné.

Trvalá oprava je jeden vlastník na vrstvu: rozhodněte, která komponenta vlastní DNS spoje tunelu a která globální výchozí, zapište to a odstraňte ostatní z cesty. Pak po odpojení ověřte jménem, které rozlišuje jen VPN. Pokud soukromé jméno stále odpovídá, registrace nebyla odstraněna; pokud se nerozlišuje nic, soubor ukazuje na server, který už neexistuje. Obojí je vidět v resolvectl, než otevřete prohlížeč.