VPN-DNS tar hvert oppslag: fiks dns-priority i NetworkManager

Koble til kontor-VPN-en, og plutselig går hvert navneoppslag til bedriftens resolver. Offentlige navn løses fortsatt, så ingenting ser ødelagt ut før et lokalt skrivernavn feiler eller en split-horizon-post returnerer kontoradressen. På noen Fedora-oppsett skjer det motsatte: leverandørens resolver fortsetter å svare etter at tunnelen er oppe. Begge er ett spørsmål — hvilken resolver som eier denne spørringen — og på NetworkManager-systemer bor svaret i DNS-egenskapene per tilkobling.

To tilkoblinger, én vinnende resolver

Hver tilkobling oppgir en DNS-prioritet. Vanlige tilkoblinger har som standard 50 og VPN-tilkoblinger 0, og den laveste verdien vinner. Nettopp den standarden er grunnen til at en VPN-tilkobling stille overstyrer den kablede forbindelsen for hvert domene den gjør krav på: null slår femti uten at noen har valgt det.

Prioriteten ordner kandidatene. Den begrenser ikke hva vinneren blir spurt om. En VPN-tilkobling uten søkedomene gjør krav på alt, så å foretrekke den sender også offentlige spørringer inn i tunnelen og, i et splitt-tunnel-design, dit bedriftens resolver videresender.

Prioriteten avgjør rekkefølgen, søkelisten avgjør eierskapet

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

Søkelisten er eierskapserklæringen. Et bart domene som corp.example blir et søkesuffiks og et rutingdomene. Formen kun for ruting ~corp.example sender oppslag under det suffikset til denne tilkoblingen uten å legge domenet til korte navn. Den tildea er forskjellen mellom «spør denne serveren» og «spør denne serveren og gjør skrivingen min ferdig».

Bruk begge formene når brukerne skriver korte vertsnavn og postene også adresseres med fullt kvalifiserte navn. Bruk bare rutingformen når du vil ha delingen uten å endre hvordan resolveren fullfører et bart navn.

Gjør 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"

En negativ prioritet er den dokumenterte måten å si «foretrekk denne tilkoblingen», og å sette begge adressefamiliene holder atferden konsistent på en vert med IPv6-tilkobling. Å endre egenskapen uten å aktivere tilkoblingen på nytt endrer ingenting av det som kjører nå, derfor slutter sekvensen med en eksplisitt up.

La systemd-resolved holde delingen

Standard dnsmasq-plugin samler spørringene i én lokal resolver, så adskillelsen per lenke blir grov. systemd-resolved viser delingen per lenke, og resolvectl query navngir lenken som svarte.

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 bærer bedriftslenken corp.example, og en offentlig resolver betjener resten. Når et oppslag treffer feil lenke, navngir kommandoen lenken som svarte på det, og å vite det er bedre enn å bare kjenne adressen.

Tilpass DNS-designet til tunneltypen

Personvernsdesign som sender alt gjennom tunnelen bør ikke ha en delingsliste, fordi den ville gi offentlige navn tilbake til den lokale resolveren og oppheve hensikten. Splitt-tunnel-design trenger en: uten den ser bedriftens resolver hver offentlig spørring, og oppsettet bryter sammen i det øyeblikket tunnelen faller.

Så er det kill switch-en som blokkerer DNS utenfor tunnelen. Navn løses for tunnelens soner og feiler overalt ellers mens tilkoblingen er helt sunn. De brukbare svarene er en uttrykkelig tillatelse for LAN-resolveren eller en lokal hurtigbuffer som bare videresender bedriftssonen, og begge er et unntak med en eier, ikke en feil i tunnelen.

En profil som skriver om resolverkonfigurasjonen ved oppstart av grensesnittet, oppfører seg omtrent likt: når den lokale resolveren er utilgjengelig, løses bare navnene tunnelen kjenner. Uansett hvilken mekanisme som gjelder, skriv ned hvilke navn som skal virke i hver tilstand, og gi listen til den som håndterer rapportene.

Verifiser per lenke, og deretter igjen etter ny tilkobling

Spør om ett internt og ett offentlig navn, og se hvor spørringen faktisk går. En lekkasjetestside forteller hvilken resolver som svarte, ikke hvilken lenke systemet valgte, så den sier ingenting om rekkefølgen du nettopp konfigurerte.

Kjør de to spørringene igjen etter å ha koblet fra og til på nytt. Prioriteter brukes på nytt når en tilkobling aktiveres, og en gammel symbolsk lenke kan overleve en oppgradering ingen husker. Det du vil ha skrevet ned til slutt, er hvilken resolver som eier hvilket suffiks, pluss en sjekk som fortsatt gjelder i morgen.