VPN-DNS tager hvert opslag: ret dns-priority i NetworkManager

En VPN-forbindelse har som standard prioritet 0 og gør krav på hvert domæne. Sæt en negativ prioritet for rækkefølgen, og brug derefter routingdomæner til at give resten tilbage.

Tilslut kontor-VPN’en, og pludselig går hvert navneopslag til virksomhedens resolver. Offentlige navne opløses stadig, så intet ser i stykker ud, før et lokalt printernavn fejler, eller en split-horizon-post returnerer kontorets adresse. På nogle Fedora-opsætninger sker det modsatte: udbyderens resolver svarer fortsat, efter at tunnelen er oppe. Begge er ét spørgsmål — hvilken resolver der ejer denne forespørgsel — og på NetworkManager-systemer bor svaret i DNS-egenskaberne for hver forbindelse.

To forbindelser, én vindende resolver

Hver forbindelse angiver en DNS-prioritet. Almindelige forbindelser har som standard 50 og VPN-forbindelser 0, og den lavere værdi vinder. Netop den standard er grunden til, at en VPN-forbindelse stille overtrumfer det kablede link for hvert domæne, den gør krav på: nul slår halvtreds, uden at nogen har valgt det.

Prioriteten ordner kandidaterne. Den begrænser ikke, hvad vinderen bliver spurgt om. En VPN-forbindelse uden søgedomæne gør krav på alt, så hvis man foretrækker den, sendes offentlige forespørgsler også ind i tunnelen og, i et split-tunnel-design, derhen hvor virksomhedens resolver videresender.

Prioriteten afgør rækkefølgen, søgelisten afgør ejerskabet

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

Søgelisten er ejerskabserklæringen. Et bart domæne som corp.example bliver et søgesuffiks og et routingdomæne. Formen kun til routing ~corp.example sender opslag under det suffiks til denne forbindelse uden at tilføje domænet til korte navne. Den tilde er forskellen mellem »spørg denne server« og »spørg denne server og gør min skrivning færdig«.

Brug begge former, når brugerne skriver korte værtsnavne, og posterne også adresseres med fuldt kvalificerede navne. Brug kun routingformen, når du vil have opdelingen uden at ændre, hvordan resolveren færdiggør et bart navn.

Gør derefter præferencen eksplicit, og genaktiver:

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 dokumenterede måde at sige »foretræk denne forbindelse«, og når begge adressefamilier sættes, forbliver adfærden ens på en vært med IPv6-forbindelse. At ændre egenskaben uden at genaktivere forbindelsen ændrer intet af det, der kører nu, og derfor slutter sekvensen med en eksplicit up.

Lad systemd-resolved holde opdelingen

Det standard dnsmasq-plugin samler forespørgsler i én lokal resolver, så adskillelsen for hvert link forbliver grov. systemd-resolved viser opdelingen for hvert link, og resolvectl query navngiver det link, der svarede.

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

Derefter bærer virksomhedslinket corp.example, og en offentlig resolver betjener resten. Når et opslag når det forkerte link, navngiver kommandoen det link, der svarede på det, og at vide det er bedre end at kende adressen alene.

Tilpas DNS-designet til tunneltypen

Privatlivsdesign, der sender alt gennem tunnelen, bør ikke have en opdelingsliste, fordi den ville give offentlige navne tilbage til den lokale resolver og ophæve hensigten. Split-tunnel-design har brug for en: uden den ser virksomhedens resolver hver offentlig forespørgsel, og opsætningen bryder sammen i det øjeblik, tunnelen falder.

Så er der kill switch, som blokerer DNS uden for tunnelen. Navne opløses for tunnelens zoner og fejler alle andre steder, mens forbindelsen er helt sund. De brugbare svar er en udtrykkelig tilladelse til LAN-resolveren eller en lokal cache, der kun videresender virksomhedszonen, og begge er en undtagelse med en ejer snarere end en fejl i tunnelen.

En profil, der omskriver resolverkonfigurationen ved grænsefladestart, opfører sig stort set på samme måde: når den lokale resolver er utilgængelig, opløses kun de navne, tunnelen kender. Uanset hvilken mekanisme der gælder, så skriv ned, hvilke navne der skal virke i hver tilstand, og giv listen til den, der håndterer rapporterne.

Kontrollér for hvert link, og igen efter genopkobling

Spørg til ét internt og ét offentligt navn, og se, hvor forespørgslen faktisk går hen. En lækagetestside fortæller, hvilken resolver der svarede, ikke hvilket link systemet valgte, så den siger intet om den rækkefølge, du netop har konfigureret.

Kør de to forespørgsler igen efter afbrydelse og genopkobling. Prioriteter anvendes igen, når en forbindelse aktiveres, og et gammelt symbolsk link kan overleve en opgradering, som ingen husker. Det, du vil have skrevet ned til sidst, er hvilken resolver der ejer hvilket suffiks, plus et tjek, der stadig holder i morgen.

Relaterede artikler