VPN-DNS tek kvar oppslag: rett opp dns-priority i NetworkManager

Kopla til kontor-VPN-en, og med ein gong går kvart namneoppslag til verksemda sin resolver. Offentlege namn vert framleis løyste, så ingenting ser øydelagt ut før eit lokalt skrivarnamn feilar eller ein split-horizon-post returnerer kontoradressa. På nokre Fedora-oppsett skjer det motsette: resolvaren til leverandøren svarar framleis etter at tunnelen er oppe. Begge er eitt spørsmål — kva resolver som eig denne spørjinga — og på NetworkManager-system bur svaret i DNS-eigenskapane per tilkopling.

To tilkoplingar, éin vinnande resolver

Kvar tilkopling oppgjev ein DNS-prioritet. Vanlege tilkoplingar har som standard 50 og VPN-tilkoplingar 0, og den lågaste verdien vinn. Nettopp den standarden er grunnen til at ei VPN-tilkopling stille overstyrer den kabelbundne for kvart domene ho krev: null slår femti utan at nokon har valt det.

Prioriteten ordnar kandidatane. Han avgrensar ikkje kva vinnaren vert spurd om. Ei VPN-tilkopling utan søkjedomene krev alt, så å føretrekke ho sender også offentlege spørjingar inn i tunnelen og, i eit splitt-tunnel-design, dit verksemda sin resolver videresender.

Prioriteten avgjer rekkjefølgja, søkjelista avgjer eigarskapet

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

Søkjelista er eigarskapserklæringa. Eit bart domene som corp.example vert eit søkjesuffiks og eit rutingsdomene. Forma berre for ruting ~corp.example sender oppslag under det suffikset til denne tilkoplinga utan å leggje domenet til korte namn. Den tildea er skilnaden mellom «spør denne tenaren» og «spør denne tenaren og gjer skrivinga mi ferdig».

Bruk begge formene når brukarane skriv korte vertsnamn og postane også vert adresserte med fullt kvalifiserte namn. Bruk berre rutingsforma når du vil ha delinga utan å endre korleis resolvaren fullfører eit bart namn.

Gjer deretter preferansen eksplisitt og aktiver på nytt:

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"

Ein negativ prioritet er den dokumenterte måten å seie «føretrekk denne tilkoplinga», og å setje begge adressefamiliane held åtferda konsistent på ein vert med IPv6-tilkopling. Å endre eigenskapen utan å aktivere tilkoplinga på nytt endrar ingenting av det som køyrer no, difor sluttar sekvensen med ein eksplisitt up.

La systemd-resolved halde delinga

Standard dnsmasq-plugin samlar spørjingane i éin lokal resolver, så skiljet per lenkje vert grovt. systemd-resolved viser delinga per lenkje, og resolvectl query namngjev lenkja som svara.

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

Etter det ber verksemdslenkja corp.example, og ein offentleg resolver tener resten. Når eit oppslag treffer feil lenkje, namngjev kommandoen lenkja som svara på det, og å vite det er betre enn å berre kjenne adressa.

Tilpass DNS-designet til tunneltypen

Personvernsdesign som sender alt gjennom tunnelen bør ikkje ha ei delingsliste, fordi ho ville gje offentlege namn attende til den lokale resolvaren og oppheve føremålet. Splitt-tunnel-design treng ei: utan ho ser verksemda sin resolver kvar offentleg spørjing, og oppsettet bryt saman i det augneblinken tunnelen fell.

Så er det kill switch-en som blokkerer DNS utanfor tunnelen. Namn vert løyste for sonene til tunnelen og feilar overalt elles medan tilkoplinga er heilt sunn. Dei brukbare svara er ei uttrykkeleg løyve for LAN-resolvaren eller ein lokal snøgglager som berre videresender verksemdssona, og begge er eit unntak med ein eigar, ikkje ein feil i tunnelen.

Ein profil som skriv om resolverkonfigurasjonen ved oppstart av grensesnittet, oppfører seg om lag likt: når den lokale resolvaren er utilgjengeleg, vert berre namna tunnelen kjenner løyste. Uansett kva mekanisme som gjeld, skriv ned kva namn som skal verke i kvar tilstand, og gje lista til den som handsamar rapportane.

Stadfest per lenkje, og deretter igjen etter ny tilkopling

Spør om eitt internt og eitt offentleg namn, og sjå kvar spørjinga faktisk går. Ei lekkasjetestside fortel kva resolver som svara, ikkje kva lenkje systemet valde, så ho seier ingenting om rekkjefølgja du nettopp konfigurerte.

Køyr dei to spørjingane igjen etter å ha kopla frå og til på nytt. Prioritetar vert brukte på nytt når ei tilkopling aktiverer, og ei gammal symbolsk lenkje kan overleve ein oppgradering ingen hugsar. Det du vil ha skrive ned til slutt, er kva resolver som eig kva suffiks, pluss ein sjekk som framleis gjeld i morgon.