Праўка resolv.conf не выпраўляе DNS пасля адключэння VPN

Вы адключаеце VPN, ping 1.1.1.1 усё яшчэ адказвае, а кожны запыт імені вісіць, пакуль старонка нарэшце не здаецца. Тады cat /etc/resolv.conf паказвае сервер імён, які існаваў толькі ўнутры тунэля, звычайна першым у спісе. Выдаленне гэтага радка выглядае як выпраўленне прыкладна на дзесяць хвілін, пакуль сон, роўмінг Wi-Fi або перазапуск не верне яго на месца. Файл, які вы правілі, не з'яўляецца наладай; гэта адлюстраванне стану злучэння, якім валодае іншы кампанент.

Чаму адзін састарэлы запіс каштуе секунд на кожны запыт

Рэзалвер glibc праходзіць спіс сервераў імён па парадку і чакае заканчэння тайм-аўту, перш чым паспрабаваць наступны, а resolv.conf(5) абмяжоўвае гэты спіс трыма запісамі. Пастаўце рэзалвер з боку тунэля, напрыклад 10.8.0.1, у пачатак пасля знікнення тунэля — і кожны запыт будзе плаціць тайм-аўтам, перш чым перайсці да сервера, які адказвае. Менавіта таму сімптом выглядае як мёртвае злучэнне, а не як памылка DNS: браўзеры блакуюцца, выходзяць па тайм-аўце і часам аддаюць кэшаваны адрас, які потым састарэе.

Гэта таксама тлумачыць, чаму скарга прыходзіць у выглядзе «інтэрнэт зламаўся». Пінг да IP-адраса даказвае, што злучэнне ў парадку, і таму няспраўнасць выглядае як праблема праграмы. Спіс рэзалвераў — гэта першае, што трэба чытаць, і апошняе, што трэба правіць.

Міф: resolv.conf — гэта файл налад

Спытайце, чым насамрэч з'яўляецца гэты шлях, перш чым яго змяняць:

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

На хаспе з systemd-resolved гэта сімвалічная спасылка на загатоўчны файл, які паказвае на 127.0.0.53, а сапраўдныя серверы жывуць у стане асобнага злучэння, які друкуе resolvectl. На хаспе з NetworkManager гэта можа быць файл, які NetworkManager запісвае з актыўнага злучэння. У некаторых кліентах вендара гэта звычайны файл, які перазапісваецца на месцы пры падключэнні і, калі вам не пашанцуе, ніколі не аднаўляецца пры адключэнні. Гэта тры розныя ўладальнікі, і ручная праўка першых двух альбо нічога не робіць, альбо трымаецца да наступнай сеткавай падзеі.

resolvectl status — гэта від, які гаворыць праўду: DNS-серверы кожнага злучэння, дамены маршрутызацыі і тое, ці існуе яшчэ злучэнне тунэля. resolvectl query example.com ідзе далей і паказвае, які інтэрфейс адказаў. Выкарыстоўвайце абодва, перш чым кранаць файл, і памятайце, што браўзер з уласным бяспечным DNS усё гэта ігнаруе.

Знайдзіце ўладальніка, перш чым нешта правіць

Звычайна тры кампаненты спаборнічаюць за адну наладу: systemd-resolved, NetworkManager і тое, што ўсталяваў кліент VPN. Спачатку вызначце жывы:

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

Калі resolved актыўны і сімвалічная спасылка паказвае на яго загатоўку, глабальны файл — гэта згенераваны вынік, і ваша праўка касметычная. Калі злучэннем валодае NetworkManager, серверы належаць профілю злучэння, таму выпраўленне — гэта змена ўласцівасці праз nmcli, а не праўка файла. Калі працуе дэман вендара, толькі яго ўласны шлях аднаўлення перажыве наступнае падключэнне.

Ачысціце стан злучэння, які пакінуў кліент

Забіты кліент не можа выканаць свой хук ачысткі. SIGKILL наогул нельга перахапіць, а SIGINT і SIGTERM можна, таму тунэль, які «проста спыніўся» пасля жорсткага забойства, часта пакідае на месцы і рэгістрацыю інтэрфейса, і запіс рэзалвера. Знайдзіце канкрэтны PID і пашліце сігнал менавіта яму:

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

Не хапайцеся за pkill -f vpn або killall vpn, пакуль не прачытаеце поўны спіс супадзенняў. -f супастаўляе ўвесь радок загаду, таму ён можа скончыць скрыпт-абгортку, сесію рэдактара або незвязаны працэс, шлях якога змяшчае гэты радок. Завяршэнне не таго працэсу падчас працы — гэта спосаб, якім праблема рэзалвера ператвараецца ў страчаны файл.

resolvectl revert скідвае канфігурацыю DNS часу выканання гэтага злучэння, што вузей за перазапуск рэзалвера і нашмат вузей за праўку глабальнага файла. Калі злучэнне тунэля цалкам знікла, systemctl restart NetworkManager перабудоўвае стан злучэння, і гэта той крок, да якога пастаянна вяртаюцца зыходныя тэмы. Сачыце за менеджэрам службаў з Restart=always, бо ён можа адразу вярнуць забітага кліента і яго налады DNS.

Іншы кірунак: праштурханы DNS, які так і не прыйшоў

Люстраное адлюстраванне састарэлага запісу — гэта тунэль зусім без прыдатнага рэзалвера. Опцыя DNS у профілі — гэта запыт; кампанент, які кіруе злучэннем, павінен перадаць яе рэзалверу. Калі журнал паказвае, што сервер быў атрыманы, але злучэнне тунэля не нясе налад DNS, то адсутнічае інтэграцыя, а не сервер.

Праверце перадачу, зрабіўшы яе ўручную, — гэта аддзяляе «сервер няправільны» ад «ніхто яго не ўжыў»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Дамен маршрутызацыі «усё астатняе» адпраўляе кожнае імя на гэтае злучэнне, чаго хоча кліент поўнага тунэля і чаго не павінен выкарыстоўваць падзелены DNS. Гэтыя налады знікаюць пры наступным падключэнні. Каб зрабіць іх пастаяннымі ў NetworkManager, адключыце аўтаматычны DNS, задайце сервер на злучэнні і дадайце дамен:

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

Для карпаратыўнага тунэля, які павінен адказваць толькі на ўнутраныя імёны, пералічыце гэтыя зоны з вядучай тыльдай замест «усё астатняе», каб публічныя імёны працягвалі выкарыстоўваць лакальны рэзалвер.

Абыходы, якія становяцца наступнай аварыяй

Капіраванне resolv.conf перад падключэннем і аднаўленне яго пасля — законны радок у runbook, і гэта абыход, а не рамонт. Ён падводзіць менавіта тады, калі гэта важна, бо збой або прымусовы перазапуск прапускаюць аднаўленне. Запішыце гэта як абыход, каб наступны чалавек не будаваў на ім.

Адключэнне systemd-resolved і жорсткае прапісванне публічных сервераў — іншы папулярны ход. Ён робіць падключэнне і адключэнне прадказальнымі і выдаляе DNS асобнага злучэння для кожнай іншай сеткі, што ламае падзелены DNS для ўнутраных імёнаў і знішчае сэнс тунэля, прызначанага трымаць запыты ўнутры яго. Усталяванне resolvconf і замацаванне публічных сервераў каштуе столькі ж з дадатковым пластом. Разглядайце любы з іх як дыягностыку: калі ён аднаўляе прагляд, вы даведаліся, што вінаватая інтэграцыя рэзалвера, а не што публічныя серверы правільныя.

Трыванае выпраўленне — адзін уладальнік на пласт: вырашыце, які кампанент валодае DNS злучэння тунэля, а які — глабальнымі па змаўчанні, запішыце гэта і прыбярыце астатніх з шляху. Затым праверце пасля адключэння імем, якое вырашае толькі VPN. Калі прыватнае імя ўсё яшчэ адказвае, рэгістрацыя не была выдаленая; калі нічога не вырашаецца, файл паказвае на сервер, якога больш не існуе. І тое, і другое відаць у resolvectl да таго, як вы адкрыеце браўзер.