DNS през VPN поема всяко търсене: оправете dns-priority в NetworkManager

Свържете служебния VPN и изведнъж всяко търсене на име отива към корпоративния резолвер. Публичните имена все още се разрешават, така че нищо не изглежда счупено, докато не се провали име на локален принтер или запис split-horizon не върне адреса на офиса. При някои инсталации на Fedora се случва обратното: резолверът на доставчика продължава да отговаря след вдигане на тунела. И двете са един въпрос — кой резолвер притежава тази заявка — а при системите с NetworkManager отговорът живее в DNS свойствата на всяка връзка.

Две връзки, един печеливш резолвер

Всяка връзка обявява приоритет за DNS. Обикновените връзки по подразбиране са 50, а VPN връзките — 0, и по-ниската стойност печели. Точно тази стойност по подразбиране е причината VPN връзката тихо да изпреварва кабелната за всеки домейн, за който претендира: нулата побеждава петдесет, без някой да я е избирал.

Приоритетът подрежда кандидатите. Той не ограничава за какво се пита победителят. VPN връзка без домейн за търсене претендира за всичко, затова предпочитането ѝ също изпраща публичните заявки в тунела и, при разделен тунел, към каквото корпоративният резолвер препраща.

Приоритетът решава реда, списъкът за търсене решава собствеността

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Списъкът за търсене е декларацията за собственост. Гол домейн като corp.example става суфикс за търсене и маршрутен домейн. Формата само за маршрутизиране ~corp.example изпраща заявките под този суфикс към тази връзка, без да добавя домейна към кратките имена. Тази тилда е разликата между „питай този сървър“ и „питай този сървър и довърши писането ми“.

Използвайте и двете форми, когато потребителите пишат кратки имена на хостове, а записите се адресират и с напълно квалифицирани имена. Използвайте само маршрутната форма, когато искате разделянето, без да променяте как резолверът допълва голо име.

След това направете предпочитанието явно и активирайте отново:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Отрицателният приоритет е документираният начин да кажете „предпочитай тази връзка“, а задаването и на двете семейства адреси запазва поведението последователно на хост с IPv6 свързаност. Промяната на свойството без повторно активиране на връзката не променя нищо, което работи в момента, затова последователността завършва с явна команда up.

Оставете systemd-resolved да държи разделянето

Плъгинът dnsmasq по подразбиране насочва заявките към един локален резолвер, така че разделянето по връзки остава грубо. systemd-resolved показва разделянето за всяка връзка и resolvectl query посочва връзката, която е отговорила.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

След това корпоративната връзка носи corp.example, а публичен резолвер обслужва останалото. Когато заявка попадне на грешната връзка, командата посочва връзката, която ѝ е отговорила, и да знаете това е по-добре от това да знаете само адреса.

Съобразете DNS дизайна с типа тунел

Дизайните за поверителност, които пращат всичко през тунела, не бива да носят списък за разделяне, защото той би върнал публичните имена към локалния резолвер и би отменил намерението. Дизайните с разделен тунел се нуждаят от такъв: без него корпоративният резолвер вижда всяка публична заявка и настройката се чупи в мига, в който тунелът падне.

После има kill switch, който блокира DNS извън тунела. Имената се разрешават за зоните на тунела и се провалят навсякъде другаде, докато връзката е напълно здрава. Работещите отговори са явно разрешение за локалния резолвер на LAN или локален кеш, който препраща само корпоративната зона, и всяко от двете е изключение със собственик, а не дефект в тунела.

Профил, който пренаписва конфигурацията на резолвера при стартиране на интерфейса, се държи почти по същия начин: щом локалният резолвер е недостъпен, ще се разрешават само имената, които тунелът познава. Който и механизъм да важи, запишете кои имена трябва да работят във всяко състояние и дайте този списък на този, който приема сигналите.

Проверете по връзки, после отново след повторно свързване

Питайте едно вътрешно и едно публично име и гледайте накъде всъщност отива заявката. Страницата за проверка на изтичане ви казва кой резолвер е отговорил, а не коя връзка е избрала системата, така че не казва нищо за подредбата, която току-що настроихте.

Пуснете двете заявки отново след прекъсване и повторно свързване. Приоритетите се прилагат наново, когато връзка се активира, а стара символна връзка може да преживее обновяване, което никой не помни. Това, което искате записано накрая, е кой резолвер притежава кой суфикс, плюс проверка, която още утре да е в сила.