DNS преко VPN-а преузима сваки упит: поправите dns-priority у NetworkManager-у

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

Две везе, један resolver победник

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

Приоритет поређа кандидате. Он не ограничава о чему се победника пита. VPN веза без домена претраге полаже право на све, па њено преферирање шаље и јавне упите у тунел, а у split-tunnel дизајну и онамо камо корпоративни 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 поседује који суфикс, уз проверу која важи и сутра.