Уредувањето на 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 пред да отворите прелистувач.