DNS i VPN-së merr çdo kërkim: rregulloni dns-priority në NetworkManager

Lidhni VPN-në e zyrës dhe papritmas çdo kërkim emri shkon te resolver-i i korporatës. Emrat publikë ende zgjidhen, kështu që asgjë nuk duket e prishur derisa dështon emri i një printeri lokal ose një regjistrim split-horizon kthen adresën e zyrës. Në disa instalime Fedora ndodh e kundërta: resolver-i i ofruesit vazhdon të përgjigjet pasi tuneli është ngritur. Të dyja janë një pyetje — cili resolver zotëron këtë kërkesë — dhe në sistemet NetworkManager përgjigjja jeton në vetitë DNS të secilës lidhje.

Dy lidhje, një resolver fitues

Çdo lidhje deklaron një përparësi DNS. Lidhjet e zakonshme kanë si parazgjedhje 50 dhe lidhjet VPN 0, dhe fiton vlera më e ulët. Pikërisht kjo parazgjedhje është arsyeja pse një lidhje VPN kalon në heshtje përpara lidhjes me kabllo për çdo domen që pretendon: zero mposht pesëdhjetë pa e zgjedhur askush.

Përparësia rendit kandidatët. Ajo nuk kufizon se për çfarë pyetet fituesi. Një lidhje VPN pa domen kërkimi pretendon gjithçka, kështu që preferimi i saj i dërgon edhe kërkesat publike brenda tunelit dhe, në një dizajn tuneli të ndarë, atje ku resolver-i i korporatës përcjell.

Përparësia vendos renditjen, lista e kërkimit zotërimin

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

Lista e kërkimit është deklarata e zotërimit. Një domen i zhveshur si corp.example bëhet prapashtesë kërkimi dhe domen rrugëzimi. Forma vetëm për rrugëzim ~corp.example i dërgon kërkimet nën atë prapashtesë kësaj lidhjeje pa e shtuar domenin te emrat e shkurtër. Ajo tildë është ndryshimi midis «pyet këtë server» dhe «pyet këtë server dhe përfundo shkrimin tim».

Përdorni të dyja format kur përdoruesit shkruajnë emra të shkurtër hosti dhe regjistrimet adresohen edhe me emra plotësisht të kualifikuar. Përdorni vetëm formën e rrugëzimit kur dëshironi ndarjen pa ndryshuar mënyrën se si resolver-i plotëson një emër të zhveshur.

Më pas bëni preferencën të qartë dhe riaktivizoni:

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"

Një përparësi negative është mënyra e dokumentuar për të thënë «prefero këtë lidhje», dhe vendosja e të dy familjeve të adresave e mban sjelljen konsistente në një host me lidhje IPv6. Ndryshimi i vetisë pa riaktivizuar lidhjen nuk ndryshon asgjë nga ajo që po funksionon tani, prandaj sekuenca përfundon me një up të qartë.

Lëreni systemd-resolved të mbajë ndarjen

Shtojca e parazgjedhur dnsmasq i derdh kërkesat në një resolver lokal, kështu që ndarja për lidhje mbetet e trashë. systemd-resolved e shfaq ndarjen për çdo lidhje, dhe resolvectl query emërton lidhjen që u përgjigj.

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

Pas kësaj lidhja e korporatës mban corp.example dhe një resolver publik shërben pjesën tjetër. Kur një kërkesë arrin në lidhjen e gabuar, komanda emërton lidhjen që iu përgjigj, dhe ta dish këtë është më mirë sesa të dish vetëm adresën.

Përshtatni dizajnin e DNS me llojin e tunelit

Dizajnet e privatësisë që dërgojnë gjithçka përmes tunelit nuk duhet të mbajnë një listë ndarjeje, sepse ajo do t'i kthente emrat publikë resolver-it lokal dhe do ta anulonte qëllimin. Dizajnet me tunel të ndarë kanë nevojë për një: pa të resolver-i i korporatës sheh çdo kërkesë publike, dhe konfigurimi prishet në momentin që tuneli bie.

Më pas është kill switch që bllokon DNS jashtë tunelit. Emrat zgjidhen për zonat e tunelit dhe dështojnë kudo tjetër ndërsa lidhja është plotësisht e shëndetshme. Përgjigjet e zbatueshme janë një leje e qartë për resolver-in e LAN-it ose një cache lokal që përcjell vetëm zonën e korporatës, dhe secila prej tyre është përjashtim me pronar, jo defekt në tunel.

Një profil që rishkruan konfigurimin e resolver-it në nisjen e ndërfaqes sillet pothuajse njësoj: sapo resolver-i lokal bëhet i paarritshëm, zgjidhen vetëm emrat që njeh tuneli. Cilido mekanizëm që zbatohet, shkruani cilët emra duhet të funksionojnë në secilën gjendje dhe jepini atë listë atij që merret me raportet.

Verifikoni për çdo lidhje dhe pastaj përsëri pas rilidhjes

Pyetni një emër të brendshëm dhe një publik, dhe shikoni ku shkon në të vërtetë kërkesa. Një faqe e kontrollit të rrjedhjeve ju tregon cili resolver u përgjigj, jo cila lidhje zgjodhi sistemi, prandaj nuk thotë asgjë për renditjen që sapo konfiguruat.

Ekzekutoni përsëri të dyja kërkesat pas një shkëputjeje dhe rilidhjeje. Përparësitë zbatohen përsëri kur një lidhje aktivizohet, dhe një lidhje simbolike e vjetër mund t'i mbijetojë një përditësimi që askush nuk e mban mend. Ajo që dëshironi të keni shkruar në fund është cili resolver zotëron cilën prapashtesë, plus një kontroll që vlen edhe nesër.