resolv.conf rediģēšana neizlabo DNS pēc VPN atvienošanas

Jūs atvienojat VPN, ping 1.1.1.1 joprojām atbild, un katrs nosaukuma vaicājums karājas, līdz lapa beidzot padodas. Tad cat /etc/resolv.conf rāda nosaukumu serveri, kas jebkad ir pastāvējis tikai tuneļa iekšienē, parasti pirmais sarakstā. Šīs rindas dzēšana šķiet to salabo uz apmēram desmit minūtēm, līdz miegs, Wi-Fi klejošana vai restartēšana to atgriež. Fails, ko rediģējāt, nav iestatījums; tas ir saites stāvokļa attēlojums, kas pieder citai komponentei.

Kāpēc viens novecojis ieraksts izmaksā sekundes par katru vaicājumu

glibc atrisinātājs iet cauri nosaukumu serveru sarakstam secīgi un nogaida taimauta beigas, pirms mēģina nākamo, un resolv.conf(5) ierobežo šo sarakstu līdz trim ierakstiem. Ielieciet tuneļa puses atrisinātāju, piemēram, 10.8.0.1, saraksta augšgalā pēc tam, kad tunelis ir pazudis, un katrs vaicājums samaksā taimautu, pirms pāriet pie servera, kas atbild. Tāpēc simptoms izskatās kā miris savienojums, nevis DNS kļūda: pārlūki bloķē, iztecē laiks un dažkārt pasniedz kešatmiņā saglabātu adresi, kas vēlāk noveco.

Tas arī izskaidro, kāpēc sūdzība nāk kā „internets ir salūzis“. Ping uz IP adresi pierāda, ka saite ir kārtībā, kas liek kļūdai izskatīties kā lietotnes vaina. Atrisinātāju saraksts ir pirmā lieta, kas jālasa, un pēdējā, kas jārediģē.

Mīts: resolv.conf ir iestatījumu fails

Pirms to mainīt, pajautājiet, kas šis ceļš patiesībā ir:

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

systemd-resolved saimniekā tas ir simboliskā saite uz stub failu, kas norāda uz 127.0.0.53, un īstie serveri dzīvo stāvoklī pa saitēm, ko izdrukā resolvectl. NetworkManager saimniekā tas var būt fails, ko NetworkManager ieraksta no aktīvā savienojuma. Dažos ražotāju klientos tas ir vienkāršs fails, kas pievienošanās laikā tiek pārrakstīts uz vietas un, ja jums neveicas, atvienošanās laikā nekad netiek atjaunots. Tie ir trīs dažādi īpašnieki, un pirmo divu rediģēšana ar roku vai nu neko nedara, vai arī turas līdz nākamajam tīkla notikumam.

resolvectl status ir skats, kas saka patiesību: DNS serveri pa saitēm, maršrutēšanas domēni un vai tuneļa saite vēl pastāv. resolvectl query example.com iet tālāk un parāda, kura saskarne atbildēja. Izmantojiet abus pirms faila aiztikšanas, un atcerieties, ka pārlūks ar savu drošo DNS to visu ignorē.

Atrodiet īpašnieku, pirms kaut ko rediģējat

Parasti trīs komponentes sacenšas par vienu un to pašu iestatījumu: systemd-resolved, NetworkManager un tas, ko instalējis VPN klients. Vispirms nosakiet dzīvo:

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

Ja resolved ir aktīvs un simboliskā saite norāda uz tā stub, globālais fails ir ģenerēta izvade un jūsu rediģējums ir kosmētisks. Ja savienojumu pārvalda NetworkManager, serveri pieder savienojuma profilam, tāpēc labojums ir nmcli īpašības maiņa, nevis faila rediģēšana. Ja darbojas ražotāja dēmons, nākamo pievienošanos pārdzīvo tikai tā paša atjaunošanas ceļš.

Notīriet saites stāvokli, ko klients atstājis

Nogalināts klients nevar palaist savu tīrīšanas āķi. SIGKILL vispār nevar notvert, kamēr SIGINT un SIGTERM var, tāpēc tunelis, kas pēc piespiedu nogalināšanas „vienkārši apstājās“, bieži atstāj uz vietas gan saskarnes reģistrāciju, gan atrisinātāja ierakstu. Atrodiet konkrēto PID un sūtiet signālu tikai tam:

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

Nesniedzieties pēc pkill -f vpn vai killall vpn, pirms neesat izlasījis pilnu atbilstību sarakstu. -f atbilst visai komandrindai, tāpēc tas var izbeigt ietvara skriptu, redaktora sesiju vai nesaistītu procesu, kura ceļā ir šī virkne. Nepareiza procesa izbeigšana darba vidū ir veids, kā atrisinātāja problēma kļūst par pazaudētu failu.

resolvectl revert atiestata šīs saites izpildlaika DNS konfigurāciju, kas ir šaurāk nekā atrisinātāja restartēšana un daudz šaurāk nekā globālā faila rediģēšana. Ja tuneļa saite ir pilnībā pazudusi, systemctl restart NetworkManager atjauno savienojuma stāvokli, un tas ir solis, pie kura avota pavedieni nemitīgi atgriežas. Uzmanieties no pakalpojumu pārvaldnieka ar Restart=always, jo tas var nogalinātu klientu un tā DNS iestatījumus vienkārši atgriezt atpakaļ.

Otrs virziens: iespiests DNS, kas tā arī nenonāca

Novecojušā ieraksta spoguļattēls ir tunelis bez jebkāda izmantojama atrisinātāja. DNS opcija profilā ir pieprasījums; komponentei, kas pārvalda savienojumu, tas jānodod atrisinātājam. Ja žurnāls rāda, ka serveris saņemts, bet tuneļa saite nenes nekādus DNS iestatījumus, trūkst integrācijas, nevis servera.

Pārbaudiet nodošanu, veicot to ar roku, kas atdala „serveris ir nepareizs“ no „neviens to nepiemēroja“:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Visu pārtverošais maršrutēšanas domēns sūta katru nosaukumu uz šo saiti, ko vēlas pilna tuneļa klients un ko nedrīkst izmantot sadalītais DNS. Šie iestatījumi pazūd nākamajā pievienošanās reizē. Lai padarītu tos pastāvīgus NetworkManager, izslēdziet automātisko DNS, iestatiet serveri savienojumā un pievienojiet domēnu:

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

Uzņēmuma tunelim, kam jāatbild tikai uz iekšējiem nosaukumiem, uzskaitiet šīs zonas ar sākuma tildi visu pārtverošā vietā, lai publiskie nosaukumi turpinātu izmantot vietējo atrisinātāju.

Apieti, kas kļūst par nākamo avāriju

resolv.conf kopēšana pirms pievienošanās un atjaunošana pēc tam ir likumīga runbook rinda, un tas ir apiešanas ceļš, nevis remonts. Tas neizdodas tieši tad, kad tas ir svarīgi, jo avārija vai piespiedu restartēšana izlaiž atjaunošanu. Pierakstiet to kā apiešanas ceļu, lai nākamais cilvēks uz tā nebalstītos.

systemd-resolved izslēgšana un publisku serveru cietā kodēšana ir otrs populārais gājiens. Tas padara pievienošanos un atvienošanos paredzamu un noņem DNS pa saitēm visiem citiem tīkliem, kas salauž sadalīto DNS iekšējiem nosaukumiem un iznīcina tuneļa, kas paredzēts vaicājumu noturēšanai iekšienē, mērķi. resolvconf instalēšana un publisku serveru piespraušana izmaksā to pašu ar papildu slāni. Uztveriet jebkuru no tiem kā diagnostiku: ja tas atjauno pārlūkošanu, jūs uzzinājāt, ka vainīga ir atrisinātāja integrācija, nevis tas, ka publiskie serveri ir pareizi.

Ilgtspējīgais labojums ir viens īpašnieks katram slānim: izlemiet, kura komponente pārvalda tuneļa saites DNS un kura globālo noklusējumu, pierakstiet to un noņemiet pārējos no ceļa. Pēc tam pēc atvienošanās pārbaudiet ar nosaukumu, ko atrisina tikai VPN. Ja privāts nosaukums joprojām atbild, reģistrācija netika noņemta; ja nekas netiek atrisināts, fails norāda uz serveri, kas vairs neeksistē. Abi ir redzami resolvectl pirms pārlūka atvēršanas.