resolv.conf aldatzeak ez du DNS konpontzen VPN-a deskonektatu ondoren

VPN-a deskonektatzen duzu, ping 1.1.1.1 oraindik erantzuten du, eta izen-bilaketa bakoitza zintzilik geratzen da orria azkenean amore eman arte. Orduan cat /etc/resolv.conf-ek tunelaren barruan soilik inoiz existitu zen izen-zerbitzari bat erakusten du, normalean zerrendako lehena. Lerro hori ezabatzeak hamar minutu inguruz konpontzen duela dirudi, suspenditze batek, Wi-Fi roaming batek edo berrabiarazte batek berriro jartzen duen arte. Editatu duzun fitxategia ez da ezarpena; beste osagai baten jabetzako esteka-egoeraren irudikapen bat da.

Zergatik kostatzen duen sarrera zahar batek segundoak bilaketa bakoitzeko

glibc resoluztaileak izen-zerbitzarien zerrenda ordenan zeharkatzen du eta denbora-muga bat itxaroten du hurrengoa probatu aurretik, eta resolv.conf(5) zerrenda hori hiru sarrerara mugatzen du. Jarri tunel aldetikako resoluztail bat, hala nola 10.8.0.1, goian tunela desagertu ondoren, eta bilaketa bakoitzak denbora-muga ordaintzen du erantzuten duen zerbitzari batera erori aurretik. Horregatik sintomak konexio hil baten itxura du, eta ez DNS errore baten: nabigatzaileak blokeatu egiten dira, denboraz agortzen dira eta batzuetan geroago zaharkitu egiten den cachean gordetako helbidea ematen dute.

Honek ere azaltzen du zergatik iristen den kexa «interneta hondatuta dago» gisa. IP helbide batera ping egiteak esteka ondo dagoela frogatzen du, eta horrek akatsa aplikazioarena ematen du. Resoluztaileen zerrenda da irakurtzeko lehen gauza eta editatzeko azkena.

Mitoa: resolv.conf ezarpen-fitxategi bat da

Galdetu zein den bidea benetan aldatu aurretik:

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

systemd-resolved duen ostalari batean stub fitxategi baterako esteka sinbolikoa da, 127.0.0.53ra seinalatzen duena, eta benetako zerbitzariak resolvectlek inprimatzen duen esteka bakoitzeko egoeran bizi dira. NetworkManager duen ostalari batean NetworkManagerrek konexio aktibotik idazten duen fitxategia izan daiteke. Saltzaile batzuen bezeroetan konektatzean tokian bertan berridazten den fitxategi soila da eta, zortedun ez bazara, deskonektatzean inoiz berreskuratzen ez dena. Hiru jabe desberdin dira horiek, eta lehen biak eskuz editatzeak edo ezer ez du egiten edo hurrengo sare-gertaerara arte irauten du.

resolvectl status egia esaten duen ikuspegia da: esteka bakoitzeko DNS zerbitzariak, bideratze-domeinuak eta tunelaren esteka oraindik badagoen. resolvectl query example.com haratago doa eta zein interfazek erantzun duen erakusten du. Erabili biak fitxategi bat ukitu aurretik, eta gogoan izan bere DNS segurua duen nabigatzaile batek dena hori alde batera uzten duela.

Aurkitu jabea ezer editatu aurretik

Hiru osagai lehiatzen dira normalean ezarpen beragatik: systemd-resolved, NetworkManager eta VPN bezeroak instalatu duena. Identifikatu lehenik bizirik dagoena:

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

resolved aktibo badago eta esteka sinbolikoak bere stub-era seinalatzen badu, fitxategi globala sortutako irteera da eta zure edizioa kosmetikoa da. NetworkManager konexioaren jabe bada, zerbitzariak konexio-profilarenak dira, beraz konponketa nmcli propietate-aldaketa da, ez fitxategi-edizioa. Saltzailearen daemon bat martxan badago, bere berreskuratze-bideak bakarrik irauten du hurrengo konexiora arte.

Garbitu bezeroak utzitako esteka-egoera

Hildako bezero batek ezin du bere garbiketa-kakoa exekutatu. SIGKILL ezin da bat ere harrapatu, SIGINT eta SIGTERM bai ordea, beraz behartutako hilketa baten ondoren «besterik gabe gelditu zen» tunel batek sarritan interfazearen erregistroa eta resoluztailearen sarrera biak uzten ditu tokian. Aurkitu PID zehatza eta bidali seinalea hari bakarrik:

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

Ez hartu pkill -f vpn edo killall vpn irakurri aurretik bat-etortze zerrenda osoa. -f komando-lerro osoarekin bat dator, beraz bilgarri-script bat, editore-saio bat edo string hori bere bidean duen prozesu erlazionatu gabe bat amaitu dezake. Prozesu okerra lanean ari dela amaitzea da resoluztailearen arazoa galdutako fitxategi bihurtzeko modua.

resolvectl revert-ek esteka horren exekuzio-denborako DNS konfigurazioa berrezartzen du, resoluztailea berrabiaraztea baino estuagoa eta fitxategi globala editatzea baino askoz estuagoa. Tunelaren esteka erabat desagertu bada, systemctl restart NetworkManager-ek konexioaren egoera berreraikitzen du eta iturburu-hariak etengabe itzultzen diren urratsa da. Kontuz Restart=always duen zerbitzu-kudeatzaile batekin, hildako bezero bat eta bere DNS ezarpenak zuzenean itzul baititzake.

Beste norabidea: inoiz iritsi ez zen DNS bultzatua

Sarrera zaharraren ispilu-irudia resolver erabilgarririk ez duen tunel bat da. Profileko DNS aukera eskaera bat da; konexioa kudeatzen duen osagaiak resoluztaileari eman behar dio. Erregistroak zerbitzaria jaso zela erakusten badu baina tunelaren estekak ez badu DNS ezarpenik eramaten, integrazioa falta da, ez zerbitzaria.

Probatu eskualdaketa eskuz eginez, honek «zerbitzaria gaizki dago» eta «inork ez zuen aplikatu» bereizten ditu:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Dena harrapatzen duen bideratze-domeinuak izen bakoitza esteka horretara bidaltzen du, tunel osoaren bezero batek nahi duena eta DNS zatituak erabili behar ez duena. Ezarpen hauek hurrengo konexioan desagertzen dira. NetworkManagerren iraunkorrak egiteko, desgaitu DNS automatikoa, ezarri zerbitzaria konexioan eta gehitu domeinua:

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

Barne-izenak soilik erantzun behar dituen enpresako tunel baterako, zerrendatu gune horiek hasierako tilde batekin dena harrapatuaren ordez, izen publikoek resoluztail lokalak erabiltzen jarrai dezan.

Hurrengo etenaldia bihurtzen diren konponbide behin-behinekoak

Konektatu aurretik resolv.conf kopiatzea eta gero berreskuratzea runbook bateko lerro zilegia da, eta konponbide behin-behinekoa da, ez konponketa. Berak axola duenean huts egiten du, krash batek edo behartutako berrabiarazte batek berreskuratzea saltatzen baitu. Idatzi konponbide behin-behineko gisa, hurrengo pertsonak horren gainean eraiki ez dezan.

systemd-resolved desgaitzea eta zerbitzari publikoak gogor kodetzea da beste mugimendu ezaguna. Konektatzea eta deskonektatzea aurreikusteko modukoak egiten ditu eta beste sare guztietarako esteka bakoitzeko DNS kentzen du, eta horrek barne-izenen DNS zatitua hausten du eta galderak bere barruan edukitzeko pentsatutako tunel baten helburua zapuzten du. resolvconf instalatzeak eta zerbitzari publikoak finkatzeak gauza bera kostatzen du geruza gehigarri batekin. Hartu bietako edozein diagnostiko gisa: nabigazioa berreskuratzen badu, resoluztailearen integrazioa dela erruduna ikasi duzu, ez zerbitzari publikoak zuzenak direnik.

Konponketa iraunkorra geruza bakoitzeko jabe bat da: erabaki zein osagai den tunelaren estekaren DNS-aren jabe eta zein balio global lehenetsiarena, idatzi hori eta kendu besteak bidetik. Gero egiaztatu deskonektatu ondoren VPNak soilik ebazten duen izen batekin. Izen pribatu batek oraindik erantzuten badu, erregistroa ez zen kendu; ezer ez bada ebazten, fitxategiak jada existitzen ez den zerbitzari bat seinalatzen du. Biak resolvectlen ikusten dira nabigatzaile bat ireki aurretik.