DNS-ul VPN-ului preia fiecare interogare: corectați dns-priority în NetworkManager

Conectați VPN-ul biroului și deodată fiecare interogare de nume merge la resolverul corporativ. Numele publice încă se rezolvă, așa că nimic nu pare stricat până când nu eșuează numele unei imprimante locale sau o înregistrare split-horizon nu returnează adresa biroului. În unele instalări Fedora se întâmplă invers: resolverul furnizorului continuă să răspundă după ce tunelul este ridicat. Ambele sunt o singură întrebare — care resolver deține această interogare — iar în sistemele NetworkManager răspunsul trăiește în proprietățile DNS ale fiecărei conexiuni.

Două conexiuni, un singur resolver câștigător

Fiecare conexiune declară o prioritate DNS. Conexiunile obișnuite au implicit 50, iar conexiunile VPN au 0, și câștigă valoarea mai mică. Tocmai acest implicit face ca o conexiune VPN să depășească în tăcere legătura cu cablu pentru fiecare domeniu pe care îl revendică: zero învinge cincizeci fără ca cineva să fi ales asta.

Prioritatea ordonează candidații. Ea nu limitează despre ce este întrebat câștigătorul. O conexiune VPN fără domeniu de căutare revendică totul, așa că preferarea ei trimite și interogările publice în tunel și, într-un proiect cu tunel divizat, acolo unde resolverul corporativ redirecționează.

Prioritatea decide ordinea, lista de căutare decide proprietatea

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

Lista de căutare este declarația de proprietate. Un domeniu gol precum corp.example devine un sufix de căutare și un domeniu de rutare. Forma doar pentru rutare ~corp.example trimite interogările de sub acel sufix către această conexiune fără a adăuga domeniul la numele scurte. Acea tildă este diferența dintre „întreabă acest server” și „întreabă acest server și termină-mi tastarea”.

Folosiți ambele forme când utilizatorii tastează nume scurte de gazdă și înregistrările sunt adresate și prin nume complet calificate. Folosiți doar forma de rutare când doriți divizarea fără a schimba modul în care resolverul completează un nume gol.

Apoi faceți preferința explicită și reactivați:

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"

O prioritate negativă este modul documentat de a spune „preferă această conexiune”, iar setarea ambelor familii de adrese menține comportamentul consecvent pe o gazdă cu conectivitate IPv6. Schimbarea proprietății fără reactivarea conexiunii nu schimbă nimic din ce rulează acum, de aceea secvența se termină cu un up explicit.

Lăsați systemd-resolved să țină divizarea

Pluginul dnsmasq implicit direcționează interogările într-un singur resolver local, așa că separarea pe legătură rămâne grosieră. systemd-resolved expune divizarea pe legătură, iar resolvectl query numește legătura care a răspuns.

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

După aceea, legătura corporativă poartă corp.example, iar un resolver public servește restul. Când o interogare ajunge pe legătura greșită, comanda numește legătura care i-a răspuns, iar să știi asta e mai bine decât să știi doar adresa.

Potriviți proiectul DNS cu tipul de tunel

Proiectele de confidențialitate care trimit totul prin tunel nu ar trebui să aibă o listă de divizare, pentru că ar returna numele publice resolverului local și ar anula intenția. Proiectele cu tunel divizat au nevoie de una: fără ea resolverul corporativ vede fiecare interogare publică, iar configurația se strică în momentul în care tunelul cade.

Apoi există kill switch-ul care blochează DNS-ul din afara tunelului. Numele se rezolvă pentru zonele tunelului și eșuează oriunde altundeva în timp ce conexiunea este perfect sănătoasă. Răspunsurile viabile sunt o permisiune explicită pentru resolverul din LAN sau un cache local care redirecționează doar zona corporativă, iar oricare dintre ele este o excepție cu proprietar, nu un defect al tunelului.

Un profil care rescrie configurația resolverului la pornirea interfeței se comportă aproape la fel: odată ce resolverul local este inaccesibil, se rezolvă doar numele pe care tunelul le cunoaște. Indiferent de mecanismul aplicabil, notați ce nume ar trebui să funcționeze în fiecare stare și dați acea listă celui care tratează rapoartele.

Verificați pe legătură, apoi din nou după reconectare

Întrebați un nume intern și unul public, și urmăriți unde merge de fapt interogarea. O pagină de verificare a scurgerilor spune care resolver a răspuns, nu care legătură a ales sistemul, așa că nu spune nimic despre ordinea pe care tocmai ați configurat-o.

Rulați din nou cele două interogări după deconectare și reconectare. Prioritățile sunt reaplicate când o conexiune se activează, iar o legătură simbolică veche poate supraviețui unui upgrade de care nimeni nu își amintește. Ce vreți să lăsați scris la final este care resolver deține care sufix, plus o verificare care mai este valabilă mâine.