Уређивање 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 грешка: прегледачи блокирају, истекне им време и понекад послуже кеширану адресу која касније застари.

То такође објашњава зашто жалба долази као „интернет је покварен“. Ping до IP адресе доказује да је веза у реду, што квара чини сличним проблему у апликацији. Листа резолвера је прва ствар коју треба прочитати и последња коју треба уредити.

Мит: resolv.conf је датотека подешавања

Питајте шта је путања заправо пре него што је промените:

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

На домаћину са systemd-resolved то је симболичка веза до stub датотеке која показује на 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 активан и симболичка веза показује на његов stub, глобална датотека је генерисани излаз и ваше уређивање је козметичко. Ако 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 пре него што отворите прегледач.