Waarom privé-DNS-namen op VPN-clients mislukken en waar je moet kijken

Je opent een laptop in een hotelkamer, start de client, typt de naam van de interne fileserver en krijgt niets terug. De tunnel meldt verbonden, en een ping naar een adres binnen hetzelfde subnet antwoordt nog steeds, dus de transportlaag zelf is in orde. Alleen de naam faalt, en dat gat beperkt het probleem tot twee plaatsen: welke resolver de client heeft gevraagd en of het antwoord dat hij kreeg terug door de tunnel kan. Los het ene op en sla het andere over, en de fout schuift gewoon op.

Controleer voordat je een profiel aanpast wat de client met de naam doet. Op Linux laat resolvectl query files.corp.example zien welke link en welke resolver het antwoord hebben opgeleverd. Op Windows laat Resolve-DnsName files.corp.example de server zien die antwoordde en het adres dat hij teruggaf.

Lees het antwoord voordat je iets verandert

Komt de naam binnen een paar milliseconden terug als NXDOMAIN, dan heeft de query je zone nooit bereikt en heeft een of andere publieke of hotelresolver geantwoord. Komt hij pas na een lange pauze terug, dan gooit iets onderweg UDP-poort 53 weg en is de client uiteindelijk teruggevallen. Komt het juiste adres terug maar blijft de verbinding hangen, dan is de opzoeking in orde en zit je probleem in de routering of in de dienst zelf.

Die driedeling scheelt een uur giswerk. Ze vertelt je ook of je de VPN überhaupt moet aanraken: een naam die naar het juiste privéadres oplost, heeft het resolverpad al bewezen, dus het werk dat overblijft zit op het datapad.

Geef de resolver vanuit de tunnel uit

Clients vallen in twee groepen uiteen. De ene groep kan tijdens het opzetten van de verbinding door de server een resolver krijgen; de andere houdt de instelling in een lokaal bestand dat geen enkele gateway op afstand kan wijzigen.

OpenVPN zit in de eerste groep. Op de server reizen push "dhcp-option DNS 10.8.0.53" en push "dhcp-option DOMAIN corp.example" over het controlekanaal, maar alleen als in de clientconfiguratie pull nog aan staat. Een met de hand bewerkte client met pull-filter ignore "dhcp-option" ziet ze nooit, en die ene regel verklaart verrassend veel gevallen van „de server pusht het, maar mijn laptop denkt van niet“.

WireGuard zit in de tweede groep, omdat het protocol helemaal geen optie-onderhandeling kent. De resolver en het zoekdomein gaan in het eigen [Interface]-blok van de client, bijvoorbeeld als DNS = 10.8.0.53, corp.example. wg-quick past dat toe via resolvconf of systemd-resolved, en op Windows installeert de officiële client NRPT-regels die alleen bestaan zolang de tunnel actief is – Get-DnsClientNrptPolicy somt ze op, wat een snelle manier is om te zien of de client je bestand ooit heeft toegepast.

IPsec/IKEv2 zit ertussenin. De attr-plugin van strongSwan kan een DNS-server uit een pool teruggeven, en een Windows-client accepteert dat normaal, maar een profiel dat zijn eigen naamserver vastzet, wint van alles wat de gateway aanbiedt. Op een Linux-client zijn de gelijkwaardige handmatige stappen resolvectl dns wg0 10.8.0.53 gevolgd door resolvectl domain wg0 '~corp.example'; beide verdwijnen samen met de interface, wat precies is wat je wilt voor een instelling die aan de tunnel gebonden is.

Baken het achtervoegsel af in plaats van elke query op te slokken

De hele resolverlijst van de client naar je interne server wijzen is makkelijk en meestal verkeerd. Elk publiek domein lost dan op via de uitgang van je datacenter, dus CDN's geven verre adressen terug, en één storing in de resolver sleept het browsen van de gebruiker mee.

Stuur alleen het privé-achtervoegsel naar binnen. Bij systemd-resolved is een domein dat met ~ begint alleen routering, dus ~corp.example betekent dat queries onder dat achtervoegsel naar de servers van die link gaan terwijl al het andere het fysieke netwerk blijft gebruiken. Windows doet hetzelfde met NRPT-regels die op een naamruimte zijn afgebakend, en macOS met een aanvullend resolverbestand onder /etc/resolver/.

Multicastnamen verdienen een eigen antwoord. .local-namen zijn van nature link-local (RFC 6762) en een punt-tot-punt-tun-interface draagt die multicastgroep niet, dus een extra publieke resolver publiceert ze niet en een interne unicastresolver geeft er NXDOMAIN op terug. Een reflector zoals avahi in reflectormodus kan twee segmenten overbruggen, maar dat is een beslissing aan serverzijde die geen client kan vragen. Moet een printer of NAS op naam bereikbaar zijn, geef hem dan een A-record in je zone.

Bewijs dat het antwoord terug kan

Een correct antwoord dat naar een onbereikbaar adres wijst, ziet er precies als een resolverprobleem uit tot je de route controleert. Vraag de kernel waar het antwoord heen zou gaan: ip route get 10.20.5.20 noemt de interface en, nuttiger, het bronadres dat hij zou gebruiken.

Let op het resolveradres zelf. Een client met DNS = 10.8.0.53 naast AllowedIPs = 10.20.0.0/16 stuurt zijn queries via de fysieke NIC naar buiten, waar ze stilletjes sterven, omdat de resolver niet binnen een prefix valt die de tunnel opeist. Die mismatch is de meest voorkomende enkelvoudige oorzaak in dit hele gebied, en hij blijft onzichtbaar tenzij je de DNS-instelling regel voor regel met de toegestane prefixen vergelijkt.

Overlappende bereiken veroorzaken de tegenovergestelde fout. Het antwoord is juist, de route bestaat, en hij wijst naar de verkeerde host, omdat 192.168.0.0/24 thuis specifieker is dan de route van de tunnel naar hetzelfde bereik. Nummer één kant opnieuw of push een smallere route, en controleer dan de firewall en het antwoordpad van de diensthost; de notities van strongSwan over doorgifte dekken de sysctl-kant van dat pad.

Certificaten zijn een aparte identiteitscontrole die mensen op DNS afschuiven. Meldt de browser een naamverschil in plaats van een resolutiefout, dan werkte de opzoeking al en is de SAN op het certificaat wat gerepareerd moet worden. Test HTTPS tegen de naam, nooit tegen het kale IP.

Test opnieuw vanaf de client, niet vanaf de gateway

Test in de toepassing waarover de gebruiker klaagt, want een opzoeking op de opdrachtregel bewijst niet dat de browser dezelfde weg neemt. Het beveiligde DNS van Chrome en network.trr.mode van Firefox kunnen de systeemresolver volledig omzeilen, en als ze dat doen, mislukt een privénaam of lekt hij naar een publieke resolver. resolvectl query vergelijken met een met de hand uitgevoerde dig @10.8.0.53 files.corp.example vertelt je welke van de twee is gebeurd.

Verbreek daarna de verbinding en maak hem opnieuw voordat je het opgelost noemt. Instellingen die met de hand op een interface zijn gezet, verdwijnen met de interface, en een profiel dat er alleen correct uitzag door een achtergebleven lokale aanpassing zal bij de volgende start falen.

Een korte checklist voor de volgende machine: de naam lost op via de resolver van de tunnel, het achtervoegsel is afgebakend in plaats van globaal, het resolveradres ligt binnen de toegestane prefixen, de host uit het antwoord antwoordt op de dienstpoort, en het certificaat dekt de naam die de gebruiker typte.