resolv.conf oanpasse reparearret DNS net nei it ferbrekken fan ’e VPN

Do ferbrekst de VPN, ping 1.1.1.1 antwurdet noch, en elke namosyk hinget foar’t de side einlings opjout. Dan lit cat /etc/resolv.conf in nammeserver sjen dy’t ea allinnich yn ’e tunnel bestien hat, meast bo-oan de list. It fuortheljen fan dy rigel liket it sa’n tsien minuten te reparearjen, oant in suspinsje, in Wi-Fi-roaming of in werstart him weromset. It bestân datsto bewurke hast is de ynstelling net; it is in werjefte fan linkstatus dy’t in oar komponint hat.

Wêrom’t ien ferâldere ynfier sekonden per opfrege kostet

De glibc-resolver rint de nammeserverlist yn folchoarder troch en wachtet in timeout ôf foar’t er de folgjende probearret, en resolv.conf(5) beheint dy list ta trije ynfieren. Set in resolver oan ’e tunnelkant lykas 10.8.0.1 bo-oan neidat de tunnel fuort is, en elke opfrege betellet de timeout foar’t er trochfalt nei in server dy’t antwurdet. Dêrom liket it symptoom in deade ferbining en net in DNS-flater: browsers blokkearje, rinne út ’e tiid en leverje soms in cachet adres dat letter ferâldere rekket.

Dat ferklearret ek wêrom’t de klacht as „it ynternet is stikken“ binnenkomt. In ping nei in IP-adres bewissiget dat de link goed is, wat de flater as dy fan ’e applikaasje lykje lit. De resolverlist is it earste ding om te lêzen en it lêste om te bewurkjen.

De myte: resolv.conf is in ynstellingsbestân

Freegje wat it paad eins is foar’tsto it feroarjest:

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

Op in systemd-resolved-host is it in symboalyske keppeling nei in stub-bestân dat nei 127.0.0.53 wiist, en de echte servers libje yn per-linkstatus dy’t resolvectl printsjet. Op in NetworkManager-host kin it in bestân wêze dat NetworkManager út ’e aktive ferbining skriuwt. By guon leveransierskliïnten is it in gewoan bestân dat by it ferbinen op it plak oerskreaun wurdt en, as do pech hast, by it ferbrekken nea weromset wurdt. Dat binne trije ferskate eigners, en de earste twa mei de hân bewurkje docht óf neat óf hâldt oant de folgjende netwurkevenemint.

resolvectl status is de werjefte dy’t de wierheid seit: DNS-servers per link, routingdomeinen, en oft de tunnellink noch bestiet. resolvectl query example.com giet fierder en lit sjen hokker ynterface antwurde. Brûk beide foar’tsto in bestân oanrekest, en hâld yn ’t sin dat in browser mei eigen feilige DNS dat allegear negearret.

Fyn de eigner foar’tsto wat bewurkest

Trije komponinten konkurrearje meastentiids om deselde ynstelling: systemd-resolved, NetworkManager en wat de VPN-kliïnt ek ynstallearre hat. Identifisearje earst de libbene:

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

As resolved aktyf is en de symboalyske keppeling nei syn stub wiist, is it globale bestân generearre útfier en is dyn bewurking kosmetysk. As NetworkManager de ferbining hat, hearre de servers by it ferbiningsprofyl, dus de repaasje is in nmcli-eigenskipswiziging en net in bestânbewurking. As der in leveransiersdaemon rint, oerlibbet allinnich syn eigen weromsetpaad de folgjende ferbining.

Skjinje de linkstatus op dy’t de kliïnt efterlitten hat

In deade kliïnt kin syn opromjehook net útfiere. SIGKILL kin hielendal net fongen wurde, wylst SIGINT en SIGTERM wol kinne, dus in tunnel dy’t „krekt stoppe“ nei in twongen dea lit faak sawol de ynterfaceregistraasje as de resolverynfier stean. Fyn de krekte PID en stjoer it sinjaal allinnich nei dy:

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

Gryp net nei pkill -f vpn of killall vpn foar’tsto de folsleine oerienkomstlist lêzen hast. -f oerienkomt mei de hiele opdrachtline, dus it kin in wiksel-skript, in bewurker-sesje of in net besibbe proses einigje wêrfan it paad de string befettet. It ferkearde proses midden yn it wurk einigje is de manier wêrop in resolverprobleem in ferlern bestân wurdt.

resolvectl revert set de runtimer-DNS-konfiguraasje fan dy link werom, wat smeller is as de resolver werstarte en folle smeller as it globale bestân bewurkje. As de tunnellink hielendal fuort is, bout systemctl restart NetworkManager de ferbiningstatus wer op en dat is de stap dêr’t de boarnethreads hieltyd wer nei weromkomme. Pas op in tsjinstbehearder mei Restart=always, want dy kin in deade kliïnt en syn DNS-ynstellings fuort daliks weromsette.

De oare rjochting: trochstutsen DNS dy’t nea oankaam

It spegelbyld fan ’e ferâldere ynfier is in tunnel sûnder hokker brûkbere resolver dan ek. In DNS-opsje yn it profyl is in fersyk; it komponint dat de ferbining beheart moat it oan de resolver oerjaan. As it logbook sjen lit dat de server ûntfongen is mar de tunnellink gjin DNS-ynstellings draacht, dan ûntbrekt de yntegraasje, net de server.

Test de oerdracht troch it mei de hân te dwaan, wat „de server is ferkeard“ fan „nimmen hat it tapast“ skiedt:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

It routingdomein dat alles fangt stjoert elke namme nei dy link, wat in folsleine-tunnelkliïnt hawwe wol en wat split-DNS net brûke moat. Dizze ynstellings ferdwine by de folgjende ferbining. Om se yn NetworkManager bliuwend te meitsjen, skeakelje automatyske DNS út, set de server op ’e ferbining en foegje it domein ta:

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

Foar in bedriuwstunnel dy’t allinnich antwurdzje moat op ynterne nammen, listje dy sônes mei in liedende tilde ynstee fan it fangen fan alles, sadat iepenbiere nammen de lokale resolver bliuwe brûken.

Wurkbeliedingen dy’t de folgjende ûnderbrekking wurde

resolv.conf kopiearje foar it ferbinen en it dêrnei weromsette is in legitime rigel yn in runbook, en it is in wurkbelieding en net in reparaasje. It mislearret krekt as it derop oankomt, omdat in crash of in twongen werstart it weromsetten oerslacht. Skriuw it as wurkbelieding op sadat de folgjende persoan der net op bout.

systemd-resolved útskeakelje en iepenbiere servers hurd kodearje is de oare populêre set. It makket ferbinen en ferbrekken foarsisber en hellet DNS per link fuort foar elk oar netwurk, wat split-DNS foar ynterne nammen brekt en it doel fan in tunnel tsjinwurket dy’t bedoeld is om opfreges binnen te hâlden. It ynstallearjen fan resolvconf en it fêstsetten fan iepenbiere servers kostet itselde mei in ekstra laach. Behannelje ien fan beide as diagnoaze: as it browsen werombringt, hast leard dat de resolveryntegraasje skuldich is, net dat de iepenbiere servers korrekt binne.

De duorsume reparaasje is ien eigner per laach: beslút hokker komponint de DNS fan ’e tunnellink hat en hokker de globale standert, skriuw dat op en helje de oaren fan it paad. Ferifiearje dan nei in ferbrekken mei in namme dy’t allinnich de VPN oplost. As in priveenamme noch antwurdet, is de registraasje net fuortsmiten; as neat oplost, wiist it bestân nei in server dy’t net mear bestiet. Beide binne sichtber yn resolvectl foar’tsto in browser iepenest.