VPN-DNS pakt elke opzoeking: herstel dns-priority in NetworkManager

Verbind de kantoor-VPN en plotseling gaat elke naamopzoeking naar de bedrijfsresolver. Openbare namen worden nog steeds opgelost, dus niets lijkt stuk tot een lokale printernaam faalt of een split-horizon-record het kantooradres teruggeeft. Op sommige Fedora-installaties gebeurt het omgekeerde: de resolver van de provider blijft antwoorden nadat de tunnel staat. Beide zijn één vraag — welke resolver deze query bezit — en op NetworkManager-systemen leeft het antwoord in de DNS-eigenschappen per verbinding.

Twee verbindingen, één winnende resolver

Elke verbinding verklaart een DNS-prioriteit. Gewone verbindingen staan standaard op 50 en VPN-verbindingen op 0, en de laagste waarde wint. Precies die standaard is de reden dat een VPN-verbinding de bekabelde verbinding stil voorbijstreeft voor elk domein dat zij claimt: nul verslaat vijftig zonder dat iemand dat koos.

De prioriteit ordent de kandidaten. Zij beperkt niet waar de winnaar naar gevraagd wordt. Een VPN-verbinding zonder zoekdomein claimt alles, dus haar voorkeur stuurt ook openbare query's de tunnel in en, in een split-tunnelontwerp, naar waar de bedrijfsresolver doorstuurt.

Prioriteit bepaalt de volgorde, de zoeklijst bepaalt het eigendom

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

De zoeklijst is de eigendomsverklaring. Een kaal domein zoals corp.example wordt een zoekachtervoegsel en een routingdomein. De vorm alleen voor routing ~corp.example stuurt opzoekingen onder dat achtervoegsel naar deze verbinding zonder het domein aan korte namen toe te voegen. Die tilde is het verschil tussen «vraag deze server» en «vraag deze server en maak mijn typwerk af».

Gebruik beide vormen wanneer gebruikers korte hostnamen typen en de records ook met volledig gekwalificeerde namen worden geadresseerd. Gebruik alleen de routingvorm wanneer je de splitsing wilt zonder te veranderen hoe de resolver een kale naam aanvult.

Maak daarna de voorkeur expliciet en reactiveer:

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"

Een negatieve prioriteit is de gedocumenteerde manier om te zeggen «geef deze verbinding voorrang», en beide adresfamilies instellen houdt het gedrag consistent op een host met IPv6-connectiviteit. De eigenschap wijzigen zonder de verbinding te reactiveren verandert niets aan wat nu draait, daarom eindigt de reeks met een expliciete up.

Laat systemd-resolved de splitsing vasthouden

De standaard dnsmasq-plug-in trechtert query's in één lokale resolver, dus de scheiding per link blijft grof. systemd-resolved toont de splitsing per link, en resolvectl query noemt de link die antwoordde.

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

Daarna draagt de bedrijfslink corp.example en bedient een openbare resolver de rest. Wanneer een opzoeking op de verkeerde link belandt, noemt de opdracht de link die erop antwoordde, en dat weten is beter dan alleen het adres kennen.

Stem het DNS-ontwerp af op het tunneltype

Privacyontwerpen die alles door de tunnel sturen, horen geen splitsingslijst te hebben, want die zou openbare namen teruggeven aan de lokale resolver en de bedoeling tenietdoen. Split-tunnelontwerpen hebben er een nodig: zonder die lijst ziet de bedrijfsresolver elke openbare query, en de opzet breekt op het moment dat de tunnel valt.

Dan is er de kill switch die DNS buiten de tunnel blokkeert. Namen worden opgelost voor de zones van de tunnel en falen overal elders terwijl de verbinding volkomen gezond is. De werkbare antwoorden zijn een uitdrukkelijke toestemming voor de LAN-resolver of een lokale cache die alleen de bedrijfszone doorstuurt, en beide zijn een uitzondering met een eigenaar, geen defect in de tunnel.

Een profiel dat de resolverconfiguratie bij het starten van de interface herschrijft, gedraagt zich bijna hetzelfde: zodra de lokale resolver onbereikbaar is, worden alleen de namen opgelost die de tunnel kent. Welk mechanisme ook geldt, schrijf op welke namen in elke toestand moeten werken, en geef die lijst aan wie de meldingen afhandelt.

Controleer per link, en daarna opnieuw na opnieuw verbinden

Vraag één interne en één openbare naam, en kijk waar de query echt heen gaat. Een lekkagetestpagina vertelt welke resolver antwoordde, niet welke link het systeem koos, dus zij zegt niets over de volgorde die je net hebt geconfigureerd.

Voer de twee query's opnieuw uit na een verbreking en herverbinding. Prioriteiten worden opnieuw toegepast wanneer een verbinding activeert, en een oude symbolische link kan een upgrade overleven die niemand zich herinnert. Wat je aan het einde opgeschreven wilt hebben, is welke resolver welk achtervoegsel bezit, plus een controle die morgen nog geldt.