DNS на VPN го презема секое пребарување: поправете dns-priority во NetworkManager

Поврзете се со канцеларискиот VPN и одеднаш секое пребарување на име оди кај корпоративниот resolver. Јавните имиња сѐ уште се решаваат, така што ништо не изгледа расипано додека не откаже името на локален печатач или записот split-horizon не ја врати адресата на канцеларијата. На некои инсталации на Fedora се случува спротивното: resolver-от на давателот продолжува да одговара откако тунелот ќе се подигне. Двете се едно прашање — кој resolver го поседува ова барање — а во системите со NetworkManager одговорот живее во DNS-својствата на секоја врска.

Две врски, еден победнички resolver

Секоја врска декларира DNS-приоритет. Обичните врски стандардно имаат 50, а VPN-врските 0, и победува помалата вредност. Токму тоа стандардно поставување е причината зошто VPN-врската тивко ја надминува жичената врска за секој домен што го бара: нулата победува педесет без некој да го избрал тоа.

Приоритетот ги подредува кандидатите. Тој не ограничува што се прашува победникот. VPN-врска без домен за пребарување бара сѐ, па нејзиното претпочитување ги праќа и јавните барања во тунелот и, при поделен тунел, таму каде корпоративниот resolver препраќа.

Приоритетот го одредува редоследот, списокот за пребарување — сопственоста

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 ги праќа барањата под таа наставка на оваа врска без да го додаде доменот на кратките имиња. Таа тилда е разликата меѓу „прашај го овој сервер“ и „прашај го овој сервер и доврши го моето пишување“.

Користете ги двете форми кога корисниците пишуваат кратки имиња на домаќини и записите се адресираат и со целосно квалификувани имиња. Користете ја само формата за рутирање кога сакате поделба без да го менувате начинот на кој resolver-от го дополнува голиот домен.

Потоа направете ја предноста експлицитна и реактивирајте ја врската:

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

Усогласете го DNS-дизајнот со типот на тунел

Дизајните за приватност што сѐ испраќаат низ тунелот не треба да носат список за поделба, зашто тој би ги вратил јавните имиња на локалниот resolver и би ја поништил намерата. Дизајните со поделен тунел го потребуваат: без него корпоративниот resolver го гледа секое јавно барање, и поставувањето се крши во мигот кога тунелот ќе падне.

Потоа е тука kill switch-от што блокира DNS надвор од тунелот. Имињата се решаваат за зоните на тунелот и откажуваат насекаде друго додека врската е сосема здрава. Работливите одговори се експлицитна дозвола за LAN resolver-от или локален кеш што препраќа само корпоративната зона, и секој од нив е исклучок со сопственик, а не дефект во тунелот.

Профил што ја препишува конфигурацијата на resolver-от при стартување на интерфејсот се однесува речиси исто: штом локалниот resolver е недостапен, ќе се решаваат само имињата што ги знае тунелот. Каков и механизам да важи, запишете кои имиња треба да работат во секоја состојба и дајте го тој список на оној што ги обработува извештаите.

Проверете по врска, потоа повторно по преповрзувањето

Прашајте едно внатрешно и едно јавно име и гледајте каде барањето навистина оди. Страницата за проверка на истекување ви кажува кој resolver одговорил, а не која врска ја избрал системот, така што не кажува ништо за редоследот што штотуку го поставивте.

Пуштете ги двете барања повторно по исклучување и повторно поврзување. Приоритетите се применуваат повторно кога врската се активира, а стара симболичка врска може да го преживее ажурирањето што никој не го памети. Она што сакате да го запишете на крајот е кој resolver поседува која наставка, плус проверка што ќе важи и утре.