Redakti resolv.conf ne riparas DNS post malkonekto de la VPN

Vi malkonektas la VPN, ping 1.1.1.1 ankoraŭ respondas, kaj ĉiu nomserĉo pendas antaŭ ol la paĝo finfine rezignas. Poste cat /etc/resolv.conf montras nomservilon, kiu ekzistis nur ene de la tunelo, kutime unue en la listo. Forigi tiun linion ŝajne riparas ĝin por proksimume dek minutoj, ĝis paŭzo, Wi-Fi-migrado aŭ restarto metas ĝin reen. La dosiero, kiun vi redaktis, ne estas la agordo; ĝi estas bildigo de ligila stato, kiun posedas alia komponanto.

Kial unu kaduka enskribo kostas sekundojn por ĉiu serĉo

La glibc-solvilo trairas la nomservilan liston laŭ ordo kaj atendas tempolimon antaŭ ol provi la sekvan, kaj resolv.conf(5) limigas tiun liston al tri enskriboj. Metu solvilon ĉe la tunela flanko kiel 10.8.0.1 ĉe la supron post kiam la tunelo foriros, kaj ĉiu serĉo pagas la tempolimon antaŭ ol fali al servilo, kiu respondas. Tial la simptomo aspektas kiel mortinta konekto anstataŭ DNS-eraro: retumiloj blokiĝas, elĉerpiĝas la tempo, kaj foje liveras kaŝitan adreson, kiu poste kadukiĝas.

Ĝi ankaŭ klarigas, kial la plendo alvenas kiel „la interreto estas rompita“. Ping al IP-adreso pruvas, ke la ligilo estas en ordo, kio igas la difekton aspekti kiel tiu de la aplikaĵo. La solvila listo estas la unua afero por legi kaj la lasta por redakti.

La mito: resolv.conf estas agorda dosiero

Demandu, kio fakte estas la vojo, antaŭ ol ŝanĝi ĝin:

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

Sur gastiganto kun systemd-resolved ĝi estas simbola ligilo al stumpodosiero montranta al 127.0.0.53, kaj la veraj serviloj loĝas en la stato por ligilo, kiun resolvectl presas. Sur gastiganto kun NetworkManager ĝi povas esti dosiero, kiun NetworkManager skribas el la aktiva konekto. Ĉe iuj vendistaj klientoj ĝi estas simpla dosiero reskribata surloke ĉe konekto kaj, se vi malbonŝancas, neniam restarigata ĉe malkonekto. Tiuj estas tri malsamaj posedantoj, kaj mana redakto de la unuaj du aŭ faras nenion aŭ daŭras ĝis la sekva reta evento.

resolvectl status estas la vido, kiu diras la veron: DNS-serviloj por ligilo, enkursigaj domajnoj, kaj ĉu la tunela ligilo ankoraŭ ekzistas. resolvectl query example.com iras pli malproksimen kaj montras, kiu interfaco respondis. Uzu ambaŭ antaŭ ol tuŝi dosieron, kaj memoru, ke retumilo kun propra sekura DNS ignoras ĉion ĉi.

Trovu la posedanton antaŭ ol redakti ion ajn

Tri komponantoj kutime konkuras pri la sama agordo: systemd-resolved, NetworkManager, kaj kion ajn instalas la VPN-kliento. Identigu unue la vivan:

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

Se resolved estas aktiva kaj la simbola ligilo montras al ĝia stumpo, la tutmonda dosiero estas generita eligo kaj via redakto estas kosmetika. Se NetworkManager posedas la konekton, la serviloj apartenas al la konekta profilo, do la ripeto estas ŝanĝo de atributo per nmcli anstataŭ dosiera redakto. Se vendista demono funkcias, nur ĝia propra restariga vojo postvivas la sekvan konekton.

Purigu la ligilan staton, kiun la kliento lasis

Mortigita kliento ne povas ruli sian purigan hokon. SIGKILL tute ne kapteblas, dum SIGINT kaj SIGTERM kapteblas, do tunelo, kiu „simple haltis“ post deviga mortigo, ofte lasas kaj la interfacan registriĝon kaj la solvilan enskribon surloke. Trovu la konkretan PID kaj sendu la signalon nur al tiu:

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

Ne ekkaptu pkill -f vpn aŭ killall vpn antaŭ ol legi la plenan kongruan liston. -f kongruas kun la tuta komandlinio, do ĝi povas fini involvan skripton, redaktan seancon aŭ nerilatan procezon, kies vojo enhavas la ĉenon. Fini la malĝustan procezon meze de la laboro estas kiel solvila problemo fariĝas perdita dosiero.

resolvectl revert restarigas la rultempan DNS-agordon de tiu ligilo, kio estas pli mallarĝa ol restartigi la solvilon kaj multe pli mallarĝa ol redakti la tutmondan dosieron. Se la tunela ligilo tute foriris, systemctl restart NetworkManager rekonstruas la konektan staton kaj tio estas la paŝo, al kiu la fontaj fadenoj konstante revenas. Atentu servadministrilon kun Restart=always, ĉar ĝi povas meti mortigitan klienton, kaj ĝiajn DNS-agordojn, rekte reen.

La alia direkto: puŝita DNS, kiu neniam alvenis

La spegula bildo de la kaduka enskribo estas tunelo tute sen uzebla solvilo. DNS-opcio en la profilo estas peto; la komponanto, kiu administras la konekton, devas transdoni ĝin al la solvilo. Se la protokolo montras, ke la servilo estis ricevita sed la tunela ligilo portas neniujn DNS-agordojn, mankas la integriĝo, ne la servilo.

Testu la transdonon farante ĝin mane, kio apartigas „la servilo estas malĝusta“ de „neniu aplikis ĝin“:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

La enkursiga domajno, kiu kaptas ĉion, sendas ĉiun nomon al tiu ligilo, kion volas plentunela kliento kaj kion disigita DNS ne rajtas uzi. Tiuj agordoj malaperas ĉe la sekva konekto. Por igi ilin daŭraj en NetworkManager, malŝaltu aŭtomatan DNS, agordu la servilon sur la konekto kaj aldonu la domajnon:

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

Por firmaa tunelo, kiu respondu nur al internaj nomoj, listigu tiujn zonojn kun komenca tildo anstataŭ la kaptilo-ĉion, por ke publikaj nomoj daŭre uzu la lokan solvilon.

Provizoraj solvoj, kiuj fariĝas la sekva paneo

Kopii resolv.conf antaŭ konekto kaj restarigi ĝin poste estas legitima linio en runbook, kaj ĝi estas provizora solvo, ne riparo. Ĝi malsukcesas ĝuste kiam ĝi gravas, ĉar paneo aŭ deviga restarto preterlasas la restarigon. Skribu ĝin kiel provizoran solvon, por ke la sekva persono ne konstruu sur ĝi.

Malŝalti systemd-resolved kaj malmoligi publikajn servilojn estas la alia populara movo. Ĝi igas konekton kaj malkonekton antaŭvideblaj kaj forigas DNS-on por ligilo por ĉiu alia reto, kio rompas disigitan DNS-on por internaj nomoj kaj neniigas la celon de tunelo destinita teni demandojn interne. Instali resolvconf kaj fiksi publikajn servilojn kostas same kun plia tavolo. Traktu iun ajn el ili kiel diagnozon: se ĝi restarigas retumadon, vi lernis, ke la solvila integriĝo kulpas, ne ke la publikaj serviloj estas ĝustaj.

La daŭra ripeto estas unu posedanto por tavolo: decidu, kiu komponanto posedas la DNS-on de la tunela ligilo kaj kiu la tutmondan defaŭlton, skribu tion, kaj forigu la aliajn el la vojo. Poste kontrolu post malkonekto per nomo, kiun nur la VPN solvas. Se privata nomo ankoraŭ respondas, la registriĝo ne estis forigita; se nenio solviĝas, la dosiero montras al servilo, kiu ne plu ekzistas. Ambaŭ videblas en resolvectl antaŭ ol vi malfermas retumilon.