resolv.conf muutmine ei paranda DNS-i pärast VPN-i katkestamist

Katkestad VPN-i, ping 1.1.1.1 vastab endiselt ja iga nimepäring jääb rippuma, kuni leht lõpuks alla annab. Siis näitab cat /etc/resolv.conf nimeserverit, mis on kunagi eksisteerinud ainult tunneli sees, tavaliselt nimekirjas esimesena. Selle rea kustutamine näib parandavat asja umbes kümneks minutiks, kuni peatamine, Wi-Fi-rändlus või taaskäivitus selle tagasi paneb. Fail, mida muutsid, ei ole seade; see on lingi oleku kuvand, mis kuulub teisele komponendile.

Miks üks aegunud kirje maksab iga päringu eest sekundeid

glibc resolver käib nimeserverite nimekirja järjekorras läbi ja ootab ajalõpu lõpuni, enne kui proovib järgmist, ja resolv.conf(5) piirab seda nimekirja kolme kirjega. Pane tunnelipoolne resolver nagu 10.8.0.1 nimekirja algusesse pärast seda, kui tunnel on kadunud, ja iga päring maksab ajalõpu, enne kui langeb serverile, mis vastab. Sellepärast näeb sümptom välja nagu surnud ühendus, mitte nagu DNS-i viga: brauserid blokeeruvad, jooksevad ajast välja ja mõnikord serveerivad vahemällu salvestatud aadressi, mis hiljem aegub.

See selgitab ka, miks kaebus tuleb kujul „internet on katki“. Ping IP-aadressile tõestab, et link on korras, mis paneb vea rakenduse süüks. Resolverite nimekiri on esimene asi, mida lugeda, ja viimane, mida muuta.

Müüt: resolv.conf on seadete fail

Küsi, mis tee tegelikult on, enne kui seda muudad:

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

systemd-resolvediga hostis on see sümboolne link stub-failile, mis osutab 127.0.0.53-le, ja päris serverid elavad lingipõhises olekus, mille resolvectl välja trükib. NetworkManageriga hostis võib see olla fail, mille NetworkManager kirjutab aktiivsest ühendusest. Mõne tootja kliendis on see lihtfail, mis kirjutatakse ühendamisel kohapeal üle ja mida õnnetu juhul katkestamisel kunagi ei taastata. Need on kolm erinevat omanikku ja kahe esimese käsitsi muutmine kas ei tee midagi või kestab järgmise võrgusündmuseni.

resolvectl status on vaade, mis räägib tõtt: lingipõhised DNS-serverid, marsruutimisdomeenid ja kas tunnelilink on veel olemas. resolvectl query example.com läheb kaugemale ja näitab, milline liides vastas. Kasuta mõlemat enne faili puudutamist ja pea meeles, et oma turvalise DNS-iga brauser eirab seda kõike.

Leia omanik enne, kui midagi muudad

Tavaliselt võistlevad sama seade pärast kolm komponenti: systemd-resolved, NetworkManager ja see, mille VPN-klient paigaldas. Tuvasta kõigepealt elus olev:

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

Kui resolved on aktiivne ja sümboolne link osutab selle stubile, on globaalne fail genereeritud väljund ja sinu muudatus on kosmeetiline. Kui ühendus kuulub NetworkManagerile, kuuluvad serverid ühendusprofiilile, seega on parandus nmcli atribuudi muutmine, mitte faili muutmine. Kui tootja deemon töötab, elab järgmise ühenduse üle ainult selle enda taastamistee.

Puhasta lingi olek, mille klient maha jättis

Tapetud klient ei saa oma puhastuskonksu käivitada. SIGKILL-i ei saa üldse tabada, SIGINT-i ja SIGTERM-i saab, seega pärast sunnitud tapmist „lihtsalt seiskunud“ tunnel jätab sageli paigale nii liidese registreeringu kui ka resolveri kirje. Leia konkreetne PID ja saada signaal ainult sellele:

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

Ära haaraku pkill -f vpn ega killall vpn järele enne, kui oled lugenud tervet vastete nimekirja. -f sobitab tervet käsurida, seega võib see lõpetada ümbris-skripti, redaktori sessiooni või mitteseotud protsessi, mille teekond sisaldab seda stringi. Vale protsessi lõpetamine töö keskel on viis, kuidas resolveri probleemist saab kadunud fail.

resolvectl revert lähtestab selle lingi käitusaegse DNS-konfiguratsiooni, mis on kitsam kui resolveri taaskäivitamine ja palju kitsam kui globaalse faili muutmine. Kui tunnelilink on täielikult kadunud, taastab systemctl restart NetworkManager ühenduse oleku ja see on samm, mille juurde allikate lõimed pidevalt tagasi tulevad. Jälgi teenusehaldurit, millel on Restart=always, sest see võib tapetud kliendi ja selle DNS-seaded otse tagasi panna.

Teine suund: lükatud DNS, mis ei jõudnud kunagi kohale

Aegunud kirje peegelpilt on tunnel, millel pole üldse kasutatavat resolverit. DNS-valik profiilis on palve; ühendust haldav komponent peab selle resolverile üle andma. Kui logi näitab, et server võeti vastu, aga tunnelilink ei kanna ühtegi DNS-seadet, siis on puudu integratsioon, mitte server.

Testi üleandmist seda käsitsi tehes, mis eristab „server on vale“ ja „keegi ei rakendanud seda“:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Kõike püüdev marsruutimisdomeen saadab iga nime sellele lingile, mida täistunneliklient tahab ja mida jagatud DNS ei tohi kasutada. Need seaded kaovad järgmisel ühendamisel. Et teha need NetworkManageris püsivaks, lülita automaatne DNS välja, sea server ühendusele ja lisa domeen:

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 "~."

Ettevõtte tunnelile, mis peaks vastama ainult sisemistele nimedele, loetle need tsoonid algava tildemärgiga, mitte kõike püüdva domeeniga, et avalikud nimed kasutaksid edasi kohalikku resolverit.

Ajutised lahendused, millest saab järgmine katkestus

resolv.confi kopeerimine enne ühendamist ja selle taastamine pärast on runbookis seaduslik rida ja see on ajutine lahendus, mitte parandus. See ebaõnnestub täpselt siis, kui sellest sõltub, sest krahh või sunnitud taaskäivitus jätab taastamise vahele. Kirjuta see ajutise lahendusena üles, et järgmine inimene sellele ei ehitaks.

systemd-resolvedi väljalülitamine ja avalike serverite kõvakodeerimine on teine populaarne käik. See teeb ühendamise ja katkestamise etteaimatavaks ning eemaldab lingipõhise DNS-i kõigi teiste võrkude jaoks, mis rikub sisemiste nimede jagatud DNS-i ja nullib tunneli eesmärgi hoida päringud selle sees. resolvconfi paigaldamine ja avalike serverite kinnitamine maksab sama lisakihiga. Käsitle mõlemat diagnoosina: kui see taastab sirvimise, oled õppinud, et süüdi on resolveri integratsioon, mitte et avalikud serverid on õiged.

Püsiv parandus on üks omanik kihi kohta: otsusta, milline komponent omab tunnelilingi DNS-i ja milline globaalset vaikeväärtust, kirjuta see üles ja eemalda teised teelt. Seejärel kontrolli pärast katkestamist nimega, mida ainult VPN lahendab. Kui privaatne nimi vastab endiselt, ei eemaldatud registreeringut; kui midagi ei lahendata, osutab fail serverile, mida enam ei ole. Mõlemad on näha resolvectlis enne, kui brauseri avad.