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

Odpojíte VPN, ping 1.1.1.1 stále odpovedá a každé hľadanie názvu visí, kým stránka nakoniec nevzdá. Potom cat /etc/resolv.conf ukáže názvový server, ktorý kedy existoval len vo vnútri tunela, zvyčajne prvý v zozname. Vymazanie toho riadku vyzerá, že to opraví na približne desať minút, kým ho spánok, roaming Wi-Fi alebo reštart nevráti späť. Súbor, ktorý ste upravili, nie je nastavenie; je to vykreslenie stavu spojenia, ktorý vlastní iná komponenta.

Prečo jeden zastaraný záznam stojí sekundy na každý dopyt

Resolver glibc prechádza zoznam názvových serverov v poradí a vyčká časový limit, kým skúsi ďalší, a resolv.conf(5) obmedzuje tento zoznam na tri záznamy. Dajte resolver na strane tunela, napríklad 10.8.0.1, na začiatok po tom, čo tunel zmizol, a každý dopyt zaplatí časový limit, kým prepadne na server, ktorý odpovedá. Preto symptóm vyzerá ako mŕtve pripojenie a nie ako chyba DNS: prehliadače blokujú, vyprší im čas a niekedy vrátia adresu z vyrovnávacej pamäte, ktorá neskôr zastará.

To tiež vysvetľuje, prečo sťažnosť prichádza ako „internet je pokazený“. Ping na IP adresu dokazuje, že spojenie je v poriadku, čo robí poruchu podobnou aplikácii. Zoznam resolverov je prvá vec, ktorú treba prečítať, a posledná, ktorú treba upraviť.

Mýtus: resolv.conf je konfiguračný súbor

Skôr než ho zmeníte, opýtajte sa, čo tá cesta vlastne je:

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

Na hostiteľovi so systemd-resolved je to symbolický odkaz na stub súbor ukazujúci na 127.0.0.53 a skutočné servery žijú v stave pre jednotlivé spojenia, ktorý vypisuje resolvectl. Na hostiteľovi s NetworkManagerom to môže byť súbor, ktorý NetworkManager zapisuje z aktívneho pripojenia. U niektorých klientských programov výrobcov je to obyčajný súbor prepisovaný na mieste pri pripojení a, ak nemáte šťastie, nikdy neobnovený pri odpojení. To sú traja rôzni vlastníci a ručná úprava prvých dvoch buď nič nerobí, alebo vydrží do ďalšej sieťovej udalosti.

resolvectl status je pohľad, ktorý hovorí pravdu: DNS servery pre jednotlivé spojenia, smerovacie domény a či spojenie tunela ešte existuje. resolvectl query example.com ide ďalej a ukazuje, ktoré rozhranie odpovedalo. Použite oboje, kým sa dotknete súboru, a majte na pamäti, že prehliadač s vlastným zabezpečeným DNS to všetko ignoruje.

Nájdite vlastníka, kým niečo upravíte

Zvyčajne súťažia tri komponenty o to isté nastavenie: systemd-resolved, NetworkManager a to, čo nainštaloval klient VPN. Najprv určite živú:

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

Ak je resolved aktívny a symbolický odkaz ukazuje na jeho stub, globálny súbor je generovaný výstup a vaša úprava je kozmetická. Ak spojenie vlastní NetworkManager, servery patria profilu pripojenia, takže oprava je zmena vlastnosti cez nmcli, nie úprava súboru. Ak beží démon výrobcu, len jeho vlastná cesta obnovy prežije ďalšie pripojenie.

Upratajte stav spojenia, ktorý klient zanechal

Zabitý klient nemôže spustiť svoj háčik na čistenie. SIGKILL sa nedá zachytiť vôbec, kým SIGINT a SIGTERM áno, takže tunel, ktorý po vynútenom zabití „len tak zastal“, často nechá na mieste registráciu rozhrania aj záznam resolvera. Nájdite konkrétny PID a pošlite signál len jemu:

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

Nesiahajte po pkill -f vpn ani killall vpn, kým si neprečítate celý zoznam zhôd. -f porovnáva celý príkazový riadok, takže môže ukončiť obalový skript, reláciu editora alebo nesúvisiaci proces, ktorého cesta obsahuje ten reťazec. Ukončenie nesprávneho procesu uprostred práce je spôsob, akým sa problém resolvera zmení na stratený súbor.

resolvectl revert resetuje runtime DNS konfiguráciu toho spojenia, čo je užšie než reštart resolvera a oveľa užšie než úprava globálneho súboru. Ak spojenie tunela úplne zmizlo, systemctl restart NetworkManager znovu zostaví stav pripojenia a to je krok, ku ktorému sa zdrojové vlákna stále vracajú. Dávajte pozor na správcu služieb s Restart=always, pretože môže zabitého klienta aj jeho DNS nastavenia vrátiť rovno späť.

Druhý smer: dotlačený DNS, ktorý nikdy nedorazil

Zrkadlovým obrazom zastaraného záznamu je tunel úplne bez použiteľného resolvera. Voľba DNS v profile je žiadosť; komponenta, ktorá spravuje pripojenie, ju musí odovzdať resolveru. Ak log ukazuje, že server bol prijatý, ale spojenie tunela nenesie žiadne DNS nastavenia, chýba integrácia, nie server.

Otestujte odovzdanie tým, že ho urobíte ručne, čo oddeľuje „server je nesprávny“ od „nikto ho nepoužil“:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Smerovacia doména, ktorá zachytáva všetko, posiela každý názov na to spojenie, čo je to, čo chce klient plného tunela a čo rozdelený DNS nesmie používať. Tieto nastavenia zmiznú pri ďalšom pripojení. Aby ste ich v NetworkManageri natrvalo nastavili, vypnite automatický DNS, nastavte server na pripojení a pridajte 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 "~."

Pre firemný tunel, ktorý má odpovedať len na interné názvy, vymenujte tie zóny s úvodnou vlnovkou namiesto zachytávania všetkého, aby verejné názvy ďalej používali lokálny resolver.

Obchádzky, ktoré sa stanú ďalšou haváriou

Kopírovanie resolv.conf pred pripojením a obnovenie po ňom je legitímny riadok v runbooku a je to obchádzka, nie oprava. Zlyhá presne vtedy, keď na tom záleží, pretože pád alebo vynútený reštart obnovenie preskočí. Zapíšte to ako obchádzku, aby na tom ďalší človek nestaval.

Vypnutie systemd-resolved a natvrdo zapísané verejné servery je druhý obľúbený ťah. Robí pripojenie a odpojenie predvídateľnými a odstraňuje DNS pre jednotlivé spojenia pre každú ďalšiu sieť, čo ničí rozdelený DNS pre interné názvy a marí účel tunela, ktorý má držať dopyty vnútri. Inštalácia resolvconf a pripnutie verejných serverov stojí to isté s vrstvou navyše. Berte ktorúkoľvek z nich ako diagnostiku: ak obnoví prehliadanie, dozvedeli ste sa, že vinná je integrácia resolvera, nie že verejné servery sú správne.

Trvalá oprava je jeden vlastník na vrstvu: rozhodnite, ktorá komponenta vlastní DNS spojenia tunela a ktorá globálne predvolené, zapíšte to a odstráňte ostatné z cesty. Potom po odpojení overte názvom, ktorý rozlišuje len VPN. Ak súkromný názov stále odpovedá, registrácia nebola odstránená; ak sa nič nerozlišuje, súbor ukazuje na server, ktorý už neexistuje. Oboje je vidieť v resolvectl, kým otvoríte prehliadač.