VPN DNS perima kiekvieną užklausą: sutvarkykite dns-priority NetworkManager

Prisijunkite prie biuro VPN ir staiga kiekviena vardo užklausa keliauja į įmonės resolverį. Vieši vardai vis dar sprendžiami, todėl niekas neatrodė sulūžę, kol nepavyksta vietinio spausdintuvo vardas arba split-horizon įrašas negrąžina biuro adreso. Kai kuriuose Fedora dieginiuose nutinka priešingai: tiekėjo resolveris atsakinėja ir po to, kai tunelis pakeltas. Abu atvejai yra vienas klausimas — kuris resolveris valdo šią užklausą — o NetworkManager sistemose atsakymas glūdi kiekvieno ryšio DNS savybėse.

Du ryšiai, vienas laimintis resolveris

Kiekvienas ryšys deklaruoja DNS prioritetą. Įprasti ryšiai pagal nutylėjimą turi 50, o VPN ryšiai 0, ir laimi mažesnė reikšmė. Būtent šis numatytasis nustatymas yra priežastis, kodėl VPN ryšys tyliai aplenkia laidinį ryšį kiekvienam domenui, į kurį pretenduoja: nulis nugali penkiasdešimt niekam nieko nesirinkus.

Prioritetas surikiuoja kandidatus. Jis neriboja, ko klausiama laimėtojo. VPN ryšys be paieškos domeno pretenduoja į viską, todėl jo pirmenybė taip pat siunčia viešas užklausas į tunelį, o padalinto tunelio atveju — ten, kur įmonės resolveris persiunčia.

Prioritetas nusprendžia tvarką, paieškos sąrašas — nuosavybę

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

Paieškos sąrašas yra nuosavybės pareiškimas. Grynas domenas, pavyzdžiui, corp.example, tampa paieškos priesaga ir maršrutizavimo domenu. Tik maršrutizavimo forma ~corp.example siunčia užklausas pagal tą priesagą šiam ryšiui nepridedant domeno prie trumpų vardų. Ta tildė yra skirtumas tarp „klausk šio serverio“ ir „klausk šio serverio ir pabaik mano rašymą“.

Naudokite abi formas, kai naudotojai rašo trumpus kompiuterių vardus, o įrašai taip pat adresuojami visiškai kvalifikuotais vardais. Naudokite tik maršrutizavimo formą, kai norite padalijimo nepakeisdami to, kaip resolveris užbaigia gryną vardą.

Tada padarykite pirmenybę aiškią ir iš naujo aktyvuokite:

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"

Neigiamas prioritetas yra dokumentuotas būdas pasakyti „teik pirmenybę šiam ryšiui“, o abiejų adresų šeimų nustatymas išlaiko nuoseklų elgesį kompiuteryje su IPv6 ryšiu. Savybės keitimas iš naujo neaktyvavus ryšio nekeičia nieko, kas dabar veikia, todėl seka baigiasi aiškia up komanda.

Leiskite systemd-resolved išlaikyti padalijimą

Numatytasis dnsmasq papildinys suplaukia užklausas į vieną vietinį resolverį, todėl atskyrimas pagal jungtį lieka grubus. systemd-resolved atskleidžia padalijimą pagal jungtį, o resolvectl query įvardija jungtį, kuri atsakė.

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

Po to įmonės jungtis neša corp.example, o viešas resolveris aptarnauja likusią dalį. Kai užklausa patenka į netinkamą jungtį, komanda įvardija jungtį, kuri į ją atsakė, ir tai žinoti geriau nei žinoti vien adresą.

Suderinkite DNS projektą su tunelio tipu

Privatumo projektai, kurie viską siunčia per tunelį, neturėtų turėti padalijimo sąrašo, nes jis grąžintų viešus vardus vietiniam resolveriui ir panaikintų tikslą. Padalinto tunelio projektams jo reikia: be jo įmonės resolveris mato kiekvieną viešą užklausą, o sąranka sugenda tą akimirką, kai tunelis nukrenta.

Tada yra kill switch, kuris blokuoja DNS už tunelio ribų. Vardai sprendžiami tunelio zonoms ir nepavyksta visur kitur, nors ryšys visiškai sveikas. Veikiantys atsakymai yra aiškus leidimas LAN resolveriui arba vietinė talpykla, persiunčianti tik įmonės zoną, ir abu yra išimtis su savininku, o ne tunelio defektas.

Profilis, kuris paleidžiant sąsają perrašo resolverio konfigūraciją, elgiasi beveik taip pat: kai vietinis resolveris tampa nepasiekiamas, bus sprendžiami tik tunelio žinomi vardai. Kad ir koks mechanizmas būtų taikomas, užrašykite, kurie vardai turi veikti kiekvienoje būsenoje, ir perduokite tą sąrašą tam, kas nagrinėja pranešimus.

Tikrinkite pagal jungtį, o po pakartotinio prisijungimo dar kartą

Paklauskite vieno vidinio ir vieno viešo vardo ir stebėkite, kur užklausa iš tikrųjų keliauja. Nuotėkio tikrinimo puslapis pasako, kuris resolveris atsakė, o ne kurią jungtį sistema pasirinko, todėl jis nieko nesako apie tvarką, kurią ką tik nustatėte.

Paleiskite abi užklausas dar kartą po atjungimo ir pakartotinio prisijungimo. Prioritetai vėl taikomi, kai ryšys aktyvuojamas, o sena simbolinė nuoroda gali išgyventi naujinimą, kurio niekas nepamena. Ką norite užsirašyti pabaigoje — kuris resolveris valdo kurią priesagą, ir patikrinimas, kuris galios ir rytoj.