VPN DNS pārņem katru vaicājumu: izlabojiet dns-priority NetworkManager

Pieslēdzieties biroja VPN, un pēkšņi katrs nosaukuma vaicājums dodas uz uzņēmuma resolveri. Publiskie nosaukumi joprojām tiek atrisināti, tāpēc nekas neizskatās salūzis, kamēr neizdodas vietējā printera nosaukums vai split-horizon ieraksts neatgriež biroja adresi. Dažās Fedora instalācijās notiek pretējais: pakalpojumu sniedzēja resolveris turpina atbildēt arī pēc tuneļa pacelšanas. Abi ir viens jautājums — kurš resolveris pārvalda šo vaicājumu — un NetworkManager sistēmās atbilde mīt katra savienojuma DNS īpašībās.

Divi savienojumi, viens uzvarētājs resolveris

Katrs savienojums deklarē DNS prioritāti. Parastajiem savienojumiem pēc noklusējuma ir 50, bet VPN savienojumiem 0, un uzvar zemākā vērtība. Tieši šis noklusējums ir iemesls, kāpēc VPN savienojums klusi apsteidz vadu savienojumu katram domēnam, uz kuru tas pretendē: nulle uzvar piecdesmit, nevienam to neizvēloties.

Prioritāte sakārto kandidātus. Tā neierobežo, par ko jautā uzvarētājam. VPN savienojums bez meklēšanas domēna pretendē uz visu, tāpēc tā priekšroka arī sūta publiskos vaicājumus tunelī un sadalītā tuneļa gadījumā tur, kur uzņēmuma resolveris pārsūta.

Prioritāte nosaka secību, meklēšanas saraksts — piederību

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

Meklēšanas saraksts ir piederības paziņojums. Kails domēns, piemēram, corp.example, kļūst par meklēšanas sufiksu un maršrutēšanas domēnu. Tikai maršrutēšanas forma ~corp.example sūta vaicājumus zem šī sufiksa uz šo savienojumu, nepievienojot domēnu īsajiem nosaukumiem. Šī tilde ir atšķirība starp «jautā šim serverim» un «jautā šim serverim un pabeidz manu rakstīšanu».

Izmantojiet abas formas, kad lietotāji raksta īsus resursdatora nosaukumus un ieraksti tiek adresēti arī ar pilnībā kvalificētiem nosaukumiem. Izmantojiet tikai maršrutēšanas formu, kad vēlaties sadalījumu, nemainot to, kā resolveris pabeidz kailu nosaukumu.

Pēc tam padariet priekšroku skaidru un aktivizējiet no jauna:

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"

Negatīva prioritāte ir dokumentētais veids, kā pateikt «dod priekšroku šim savienojumam», un abu adrešu saimju iestatīšana saglabā konsekventu uzvedību resursdatorā ar IPv6 savienojumu. Īpašības maiņa, aktivizējot savienojumu no jauna, nemaina neko no tā, kas pašlaik darbojas, tāpēc secība beidzas ar skaidru up.

Ļaujiet systemd-resolved turēt sadalījumu

Noklusējuma dnsmasq spraudnis iepludina vaicājumus vienā vietējā resolverī, tāpēc atdalīšana pa saitēm paliek rupja. systemd-resolved atklāj sadalījumu pa saitēm, un resolvectl query nosauc saiti, kas atbildēja.

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

Pēc tam uzņēmuma saite nes corp.example, un publiskais resolveris apkalpo pārējo. Kad vaicājums nonāk nepareizajā saitē, komanda nosauc saiti, kas uz to atbildēja, un to zināt ir labāk nekā zināt tikai adresi.

Saskaņojiet DNS dizainu ar tuneļa tipu

Privātuma dizaini, kas visu sūta pa tuneli, nedrīkstētu nest sadalīšanas sarakstu, jo tas atdotu publiskos nosaukumus vietējam resolverim un atceltu nodomu. Sadalītā tuneļa dizainiem tas ir vajadzīgs: bez tā uzņēmuma resolveris redz katru publisko vaicājumu, un iestatījums salūzt tajā mirklī, kad tunelis nokrīt.

Tad ir kill switch, kas bloķē DNS ārpus tuneļa. Nosaukumi tiek atrisināti tuneļa zonām un neizdodas visur citur, kamēr savienojums ir pilnīgi vesels. Strādājošās atbildes ir skaidra atļauja LAN resolverim vai vietēja kešatmiņa, kas pārsūta tikai uzņēmuma zonu, un abas ir izņēmums ar īpašnieku, nevis tuneļa defekts.

Profils, kas saskarnes startā pārraksta resolvera konfigurāciju, uzvedas gandrīz tāpat: tiklīdz vietējais resolveris kļūst nesasniedzams, tiks atrisināti tikai tie nosaukumi, ko tunelis zina. Lai kāds mehānisms būtu spēkā, pierakstiet, kuriem nosaukumiem jādarbojas katrā stāvoklī, un nododiet šo sarakstu tam, kas apstrādā ziņojumus.

Pārbaudiet pa saitēm, pēc tam vēlreiz pēc atkārtotas pievienošanas

Pajautājiet vienu iekšēju un vienu publisku nosaukumu, un skatieties, kur vaicājums patiešām dodas. Noplūdes pārbaudes lapa pasaka, kurš resolveris atbildēja, nevis kuru saiti sistēma izvēlējās, tāpēc tā neko nepasaka par secību, ko tikko konfigurējāt.

Palaidiet abus vaicājumus vēlreiz pēc atvienošanas un atkārtotas pievienošanas. Prioritātes tiek piemērotas no jauna, kad savienojums tiek aktivizēts, un veca simboliskā saite var pārdzīvot jauninājumu, ko neviens neatceras. To, ko vēlaties pierakstīt beigās, ir tas, kurš resolveris pārvalda kuru sufiksu, plus pārbaude, kas būs spēkā arī rīt.