VPN-DNS tar varje uppslag: åtgärda dns-priority i NetworkManager

Anslut kontors-VPN: et och plötsligt går varje namnsökning till företagets resolver. Publika namn löses fortfarande, så inget ser trasigt ut förrän ett lokalt skrivarnamn misslyckas eller en split-horizon-post returnerar kontorets adress. På vissa Fedora-installationer händer det motsatta: leverantörens resolver fortsätter svara efter att tunneln är uppe. Båda är en och samma fråga — vilken resolver som äger den här frågan — och på NetworkManager-system bor svaret i DNS-egenskaperna per anslutning.

Två anslutningar, en vinnande resolver

Varje anslutning anger en DNS-prioritet. Vanliga anslutningar har som standard 50 och VPN-anslutningar 0, och det lägre värdet vinner. Just den standarden är skälet till att en VPN-anslutning tyst går före den kabelanslutna för varje domän den gör anspråk på: noll slår femtio utan att någon har valt det.

Prioriteten ordnar kandidaterna. Den begränsar inte vad vinnaren tillfrågas om. En VPN-anslutning utan sökdomän gör anspråk på allt, så att föredra den skickar också publika frågor in i tunneln och, i en delad tunnel, dit företagets resolver vidarebefordrar.

Prioriteten avgör ordningen, söklistan avgör ägandet

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

Söklistan är ägandeförklaringen. En bar domän som corp.example blir ett söksuffix och en routingdomän. Formen endast för routing ~corp.example skickar uppslag under det suffixet till den här anslutningen utan att lägga till domänen på korta namn. Det tilde-tecknet är skillnaden mellan ”fråga den här servern” och ”fråga den här servern och gör klart min skrivning”.

Använd båda formerna när användare skriver korta värdnamn och posterna även adresseras med fullt kvalificerade namn. Använd bara routingformen när du vill ha delningen utan att ändra hur resolvern kompletterar ett bart namn.

Gör sedan preferensen explicit och aktivera igen:

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 är det dokumenterade sättet att säga ”föredra den här anslutningen”, och att sätta båda adressfamiljerna håller beteendet konsekvent på en värd med IPv6-anslutning. Att ändra egenskapen utan att aktivera anslutningen igen ändrar inget av det som körs nu, därför slutar sekvensen med ett uttryckligt up.

Låt systemd-resolved hålla delningen

Standardinsticksprogrammet dnsmasq samlar frågorna i en lokal resolver, så uppdelningen per länk förblir grov. systemd-resolved visar delningen per länk, och resolvectl query namnger länken som svarade.

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

Därefter bär företagslänken corp.example och en publik resolver betjänar resten. När ett uppslag hamnar på fel länk namnger kommandot länken som svarade på det, och att veta det är bättre än att bara känna till adressen.

Anpassa DNS-designen till tunneltypen

Integritetsdesigner som skickar allt genom tunneln bör inte ha en delningslista, eftersom den skulle lämna tillbaka publika namn till den lokala resolvern och omintetgöra avsikten. Delade tunnlar behöver en: utan den ser företagets resolver varje publik fråga, och konfigurationen går sönder i samma stund som tunneln faller.

Sedan finns kill switch som blockerar DNS utanför tunneln. Namn löses för tunnelns zoner och misslyckas överallt annars medan anslutningen är helt frisk. De användbara svaren är ett uttryckligt tillstånd för LAN-resolvern eller en lokal cache som bara vidarebefordrar företagszonen, och båda är ett undantag med en ägare, inte ett fel i tunneln.

En profil som skriver om resolverkonfigurationen när gränssnittet startar beter sig ungefär likadant: när den lokala resolvern är oåtkomlig löses bara de namn som tunneln känner till. Vilken mekanism som än gäller, skriv ned vilka namn som ska fungera i varje tillstånd och ge listan till den som hanterar rapporterna.

Verifiera per länk och sedan igen efter återanslutning

Fråga efter ett internt och ett publikt namn, och se vart frågan faktiskt tar vägen. En läcktestssida berättar vilken resolver som svarade, inte vilken länk systemet valde, så den säger inget om ordningen du just konfigurerade.

Kör de två frågorna igen efter att ha kopplat från och till igen. Prioriteter tillämpas på nytt när en anslutning aktiveras, och en gammal symbolisk länk kan överleva en uppgradering som ingen minns. Det du vill ha nedskrivet till slut är vilken resolver som äger vilket suffix, plus en kontroll som fortfarande gäller i morgon.