Om resolv.conf te wysig maak nie DNS reg ná die VPN ontkoppel nie

Jy ontkoppel die VPN, ping 1.1.1.1 antwoord steeds, en elke naamsoektog hang voordat die bladsy uiteindelik moed opgee. Dan wys cat /etc/resolv.conf ’n naambediener wat net ooit binne die tonnel bestaan het, gewoonlik eerste op die lys. Om daardie reël te verwyder lyk of dit die probleem vir sowat tien minute oplos, totdat ’n slaapstand, ’n Wi-Fi-swerm of ’n herbegin dit terugbring. Die lêer wat jy gewysig het, is nie die instelling nie; dit is ’n weergawe van skakeltoestand wat deur ’n ander komponent besit word.

Waarom een verouderde inskrywing sekondes per soektog kos

Die glibc-resolver loop die naambedienerlys in volgorde deur en wag ’n time-out uit voordat hy die volgende een probeer, en resolv.conf(5) beperk daardie lys tot drie inskrywings. Sit ’n resolver aan die tonnelkant soos 10.8.0.1 boaan nadat die tonnel weg is, en elke soektog betaal die time-out voordat dit deurval na ’n bediener wat antwoord. Dit is waarom die simptoom soos ’n dooie verbinding lyk eerder as ’n DNS-fout: blaaiers blokkeer, hou op wag, en lewer soms ’n gekaste adres wat later verouderd raak.

Dit verduidelik ook waarom die klagte as „die internet is stukkend” opduik. ’n Ping na ’n IP-adres bewys die skakel is reg, wat die fout soos die toepassing laat lyk. Die resolver-lys is die eerste ding om te lees en die laaste ding om te wysig.

Die mite: resolv.conf is ’n instellingslêer

Vra eers wat die pad werklik is voordat jy dit verander:

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

Op ’n systemd-resolved-gasheer is dit ’n simskakel na ’n stomp-lêer wat na 127.0.0.53 wys, en die werklike bedieners woon in per-skakel-toestand wat resolvectl druk. Op ’n NetworkManager-gasheer is dit dalk ’n lêer wat NetworkManager uit die aktiewe verbinding skryf. By sommige verskaffer-kliënte is dit ’n gewone lêer wat in plek herskryf word by verbinding en, as jy ongelukkig is, nooit herstel word by ontkoppeling nie. Dit is drie verskillende eienaars, en om die eerste twee met die hand te wysig doen óf niks óf hou tot die volgende netwerkgebeurtenis.

resolvectl status is die aansig wat die waarheid vertel: per-skakel DNS-bedieners, roeteringsdomeine, en of die tonnel-skakel nog bestaan. resolvectl query example.com gaan verder en wys watter koppelvlak geantwoord het. Gebruik albei voordat jy aan ’n lêer raak, en onthou dat ’n blaaier met sy eie veilige DNS dit alles ignoreer.

Vind die eienaar voordat jy enigiets wysig

Drie komponente ding gewoonlik om dieselfde instelling: systemd-resolved, NetworkManager en wat die VPN-kliënt ook al geïnstalleer het. Identifiseer eers die lewende een:

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

As resolved aktief is en die simskakel na sy stomp wys, is die globale lêer gegenereerde uitset en jou wysiging is kosmeties. As NetworkManager die verbinding besit, hoort die bedieners by die verbindingsprofiel, so die regstelling is ’n nmcli-eienskapverandering eerder as ’n lêerwysiging. As ’n verskaffer-daemon loop, is sy eie herstelpad die enigste een wat die volgende verbinding oorleef.

Vee die skakeltoestand uit wat die kliënt agtergelaat het

’n Gedode kliënt kan nie sy opruimingshaak uitvoer nie. SIGKILL kan glad nie gevang word nie, terwyl SIGINT en SIGTERM dit kan, so ’n tonnel wat ná ’n gedwonge dood „net gestop het”, laat dikwels beide die koppelvlak-registrasie en die resolver-inskrywing in plek. Vind die spesifieke PID en stuur die sein na daardie een:

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

Moenie na pkill -f vpn of killall vpn gryp voordat jy die volle paslys gelees het nie. -f pas die hele opdraglyn, so dit kan ’n omhulsel-skrip, ’n redigeerder-sessie of ’n onverwante proses beëindig wie se pad die string bevat. Om die verkeerde proses midde-in ’n lopie te beëindig, is hoe ’n resolver-probleem ’n verlore lêer word.

resolvectl revert stel die looptyd-DNS-konfigurasie van daardie skakel terug, wat smaller is as om die resolver te herbegin en baie smaller as om die globale lêer te wysig. As die tonnel-skakel heeltemal weg is, herbou systemctl restart NetworkManager die verbindingstoestand en is dit die stap waarna die bron-drade aanhou terugkeer. Let op ’n diensbestuurder met Restart=always, want dit kan ’n gedode kliënt, en sy DNS-instellings, direk terugplaas.

Die ander rigting: DNS wat gestoot is maar nooit aangekom het nie

Die spieëlbeeld van die verouderde inskrywing is ’n tonnel met glad geen bruikbare resolver nie. ’n DNS-opsie in die profiel is ’n versoek; die komponent wat die verbinding bestuur, moet dit aan die resolver oorhandig. As die log wys die bediener is ontvang maar die tonnel-skakel dra geen DNS-instellings nie, dan ontbreek die integrasie, nie die bediener nie.

Toets die oorhandiging deur dit met die hand te doen, wat „die bediener is verkeerd” van „niemand het dit toegepas” skei:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Die vang-alles-roeteringsdomein stuur elke naam na daardie skakel, wat is wat ’n vol-tonnel-kliënt wil hê en wat split-DNS nie moet gebruik nie. Hierdie instellings verdwyn by die volgende verbinding. Om hulle in NetworkManager blywend te maak, deaktiveer outomatiese DNS, stel die bediener op die verbinding en voeg die domein by:

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

Vir ’n maatskappy-tonnel wat net interne name moet beantwoord, lys daardie sones met ’n voorste tilde in plaas van die vang-alles, sodat publieke name die plaaslike resolver bly gebruik.

Noodoplossings wat die volgende onderbreking word

Om resolv.conf voor verbinding te kopieer en dit daarna te herstel is ’n wettige reël in ’n runbook, en dit is ’n noodoplossing eerder as ’n herstelling. Dit faal presies wanneer dit saak maak, want ’n ineenstorting of ’n gedwonge herbegin slaan die herstel oor. Skryf dit as ’n noodoplossing neer sodat die volgende persoon nie daarop bou nie.

Om systemd-resolved te deaktiveer en publieke bedieners hard te kodeer is die ander gewilde skuif. Dit maak verbinding en ontkoppeling voorspelbaar en verwyder per-skakel-DNS vir elke ander netwerk, wat split-DNS vir interne name breek en die doel verydel van ’n tonnel wat bedoel is om navrae binne hom te hou. Om resolvconf te installeer en publieke bedieners vas te pen kos dieselfde met ’n ekstra laag. Behandel enigeen as ’n diagnostikum: as dit blaai herstel, het jy geleer dat die resolver-integrasie foutief is, nie dat die publieke bedieners korrek is nie.

Die blywende regstelling is een eienaar per laag: besluit watter komponent die tonnel-skakel se DNS besit en watter die globale verstek besit, skryf dit neer, en verwyder die ander uit die pad. Verifieer dan ná ’n ontkoppeling met ’n naam wat net die VPN oplos. As ’n private naam steeds antwoord, is die registrasie nie verwyder nie; as niks hoegenaamd oplos nie, wys die lêer na ’n bediener wat nie meer bestaan nie. Beide is sigbaar in resolvectl voordat jy ’n blaaier oopmaak.