DNS werkt niet over WireGuard: drie veelvoorkomende fouten

Waarom DNS wegvalt zodra de WireGuard-tunnel wordt geactiveerd

DNS over WireGuard faalt op drie manieren, en voor elk probleem is een specifieke oplossing. Ofwel er wordt helemaal niets opgelost, ofwel namen worden wel opgelost maar de queries verlaten uw machine buiten de tunnel om, of de eigen resolver-manager van de client overschrijft de instelling seconden nadat de interface is gestart. De tunnel is bijna nooit het probleem. Het probleem is de regel die de client vertelt welke resolver hij moet raadplegen, en de routering die bepaalt hoe pakketten naar die resolver reizen.

WireGuard verplaatst IP-pakketten en weet niets van DNS (domain name system, de service die namen zoals example.com omzet in IP-adressen). De DNS =-regel in een [Interface]-blok van een client is geen WireGuard-instelling. Deze wordt gelezen door wg-quick, de shell-wrapper die de interface opstart, waarna wg-quick de resolver-configuratie van de client bewerkt terwijl de tunnel actief is en deze herstelt bij wg-quick down. Elk onderstaand probleem is dus een routeringsprobleem of een wg-quick-probleem, nooit een cryptografisch probleem. Als de tunnel zelf nog niet is opgezet, begin dan bij een zelfgehoste WireGuard VPN op uw eigen VPS en keer daarna terug naar deze pagina.

Bevestig dat de tunnel gezond is voordat u überhaupt aan DNS sleutelt.

sudo wg show
ping -c 3 10.8.0.1
ping -c 3 1.1.1.1

wg show hoort de peer met een recente latest handshake weer te geven, en beide pings zouden antwoord moeten geven. Als ping 1.1.1.1 een time-out geeft, heeft u een forwarding- of NAT (network address translation)-probleem in plaats van een DNS-probleem, en zal geen enkele resolver-configuratie helpen. Als de pings wel antwoord geven maar de doorvoer instort zodra er echt verkeer plaatsvindt, is dat een afzonderlijk probleem, en trage WireGuard is bijna altijd te herleiden naar MTU in plaats van naar iets op deze pagina. Elk voorbeeld hier gebruikt 10.8.0.0/24 als het tunnel-subnet en 10.8.0.1 als het tunnel-adres van de server. Vervang deze door uw eigen gegevens.

Fout één: niets wordt omgezet, omdat de resolver nooit antwoordt

Het symptoom is specifiek. ping 1.1.1.1 werkt en curl https://example.com geeft dit terug:

curl: (6) Could not resolve host: example.com

Bevraag de tunnel-resolver rechtstreeks vanaf de client. dig is afkomstig uit het dnsutils-pakket op Ubuntu en Debian.

dig +short @1.1.1.1 example.com
dig +short @10.8.0.1 example.com

Het eerste commando geeft een adres terug, wat bewijst dat pakketten via de tunnel het internet bereiken. Het tweede geeft niets terug en toont ;; communication timed out; no servers could be reached. Dat is de volledige diagnose: uw client is ingesteld op 10.8.0.1 en 10.8.0.1 antwoordt niet op UDP-poort 53.

Twee oorzaken veroorzaken dit. Of er draait geen resolver op de server, of de serverfirewall blokkeert de query voordat deze aankomt. Controleer beide op de server.

sudo ss -ulnp | grep ':53'
sudo nft list ruleset

Een resolver die draait en correct is gebonden, toont een regel met 10.8.0.1:53 of 0.0.0.0:53. Op Ubuntu is de verrassing meestal 127.0.0.53:53: dat is de systemd-resolved stub-listener, die een loopback-adres bindt en bewust onbereikbaar is vanaf andere machines. Een VPN-client instellen op een server waarvan de enige resolver die stub is, resulteert precies in deze time-out.

De oplossing is een resolver die luistert op het tunneladres, plus één firewallregel die toestaat dat peers deze bereiken.

sudo apt update && sudo apt install -y unbound
printf 'server:\n  interface: 10.8.0.1\n  access-control: 10.8.0.0/24 allow\n' \
  | sudo tee /etc/unbound/unbound.conf.d/wireguard.conf
sudo systemctl restart unbound
sudo ss -ulnp | grep '10.8.0.1:53'

Open vervolgens de poort alleen voor tunnelverkeer. Voeg met nftables deze twee regels toe aan de input-chain in /etc/nftables.conf en herlaad met sudo systemctl reload nftables.

udp dport 53 iifname "wg0" accept
tcp dport 53 iifname "wg0" accept

Met ufw doet sudo ufw allow in on wg0 to any port 53 hetzelfde. Open poort 53 nooit voor het openbare internet. Een open recursieve resolver wordt binnen enkele dagen gevonden door scanners en gebruikt om denial-of-service-aanvallen te versterken; uw provider zal dat verkeer eerder opmerken dan u.

Voer dig +short @10.8.0.1 example.com opnieuw uit vanaf de client. Een adres in de uitvoer betekent dat het resolverpad werkt, dus de client hoeft het nu alleen nog maar te gebruiken. Voeg de regel toe aan het [Interface]-blok van de client en herstart de interface met sudo wg-quick down wg0 && sudo wg-quick up wg0.

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

Fout twee: DNS-lekkages, omdat een split tunnel de resolver niet routeert

Dit is ernstiger, omdat alles lijkt te werken. Namen worden omgezet, pagina's laden en de queries reizen in leesbare tekst over het lokale netwerk dat u niet wilde vertrouwen.

Twee configuraties veroorzaken dit. De eerste is een client met AllowedIPs = 0.0.0.0/0, ::/0 en zonder DNS =-regel. wg-quick installeert de standaardroute in zijn eigen routeringstabel en voegt een regel toe met suppress_prefixlength 0, die specifiekere lokale routes bewust in stand houdt zodat de machine nog steeds zijn printer kan bereiken. De resolver die de client via DHCP heeft geleerd, doorgaans de router op 192.168.1.1, komt overeen met een van die lokale routes. Uw verkeer gaat via de tunnel. Het lokale netwerk ontvangt echter nog steeds de volledige lijst met namen die u opzoekt.

De tweede is een split tunnel: AllowedIPs = 10.8.0.0/24 met DNS = 9.9.9.9. Omdat 9.9.9.9 zich niet binnen AllowedIPs bevindt, heeft de client geen route ernaartoe via de tunnel, waardoor de query via de lokale verbinding vertrekt, precies zoals in het eerste geval.

Controleer welke resolver daadwerkelijk antwoordt. whoami.akamai.net is een publieke testnaam die antwoordt met het IP-adres van de recursieve resolver die de vraag stelde, zodat u het antwoord kunt vergelijken met het publieke adres van uw server.

resolvectl status
dig +short whoami.akamai.net
sudo tcpdump -ni any -c 10 port 53

resolvectl status toont één blok per verbinding. Als het blok voor uw ethernet- of draadloze verbinding nog steeds Current DNS Server: 192.168.1.1 toont terwijl het wg0-blok niets laat zien, is dat de lekkage. dig +short whoami.akamai.net dat uw thuisnetwerkadres teruggeeft in plaats van het adres van uw server, bevestigt dit vanaf de andere kant. De tcpdump-regel is het bewijs dat discussies beëindigt: gezonde output plaatst elk pakket op poort 53 op wg0, en een lekkage plaatst ze op wlan0 of enp3s0.

De oplossing bestaat uit twee delen en beide zijn vereist. Stel DNS in op een adres dat zich binnen de tunnel bevindt en zorg ervoor dat dat adres binnen AllowedIPs valt.

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 10.20.0.0/16

10.8.0.1 bevindt zich binnen 10.8.0.0/24, dus de query wordt versleuteld en naar de server verzonden. Als u per se een publieke resolver wilt gebruiken op een split tunnel, voeg deze dan toe als hostroute: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. De pakketten worden dan getunneld, hoewel het lokale netwerk nog steeds kan zien dat u die provider hebt gekozen op basis van eerdere sessies. Een resolver die u zelf beheert, voorkomt dit probleem.

De toewijzing van resolvers is een van de zichtbare verschillen tussen handmatig opgebouwde WireGuard-configuraties en een gecoördineerd meshnetwerk. Dit is onderdeel van de afweging in WireGuard vergeleken met Tailscale. Met een zelfgehoste Headscale-controlserver krijgt u die coördinatie zonder uw sleutelmateriaal aan een derde partij over te dragen. Als juist dat laatste punt u zorgen baart, moet u weten dat Tailscale nooit de sleutels bewaart waarmee uw verkeer wordt versleuteld. De relevantere vraag is welke extra toegang een gecompromitteerde coördinatieserver of een gestolen identiteitsaccount tot uw netwerk kan geven.

Fout drie: resolvconf en systemd-resolved conflicteren op Linux-clients

macOS, Windows, iOS en Android-clients passen DNS = toe via de officiële app en veroorzaken zelden problemen. Op Linux wordt de instelling toegepast door een shell-script dat moet raden welke van de verschillende resolver-managers u gebruikt.

De eerste fout is duidelijk zichtbaar. sudo wg-quick up wg0 stopt met:

resolvconf: command not found

wg-quick roept resolvconf aan, en dat binaire bestand is niet geïnstalleerd. Installeer de implementatie die communiceert met systemd-resolved en breng de interface daarna opnieuw omhoog.

sudo apt install -y openresolv
sudo systemctl restart systemd-resolved
sudo wg-quick down wg0 && sudo wg-quick up wg0
resolvectl status wg0

De tweede fout is stil en kost vaak een hele avond om op te lossen. De interface komt omhoog, resolvectl status wg0 toont correct DNS Servers: 10.8.0.1, maar opzoekingen gaan nog steeds naar de oude resolver. systemd-resolved houdt een aparte resolver-lijst per link bij en kiest per query een link. Tenzij één link is gemarkeerd als de standaardroute voor namen, blijft het de resolver van de draadloze verbinding gebruiken, omdat die link een zoekdomein bevat en de uwe niet.

Stel de resolver in en claim de standaardroute in dezelfde stap. %i wordt uitgebreid naar de interfacenaam, dus dit blok werkt ongewijzigd op elke interface.

[Interface]
Address = 10.8.0.2/32
PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~.
PostDown = resolvectl revert %i

Verwijder de DNS =-regel wanneer u PostUp op deze manier gebruikt, omdat anders twee mechanismen de resolver-status schrijven en slechts één daarvan achteraf opschoont. Het ~.-argument is het belangrijkste onderdeel: het markeert wg0 als het routeringsdomein voor elke naam, zodat systemd-resolved alle queries daarheen stuurt in plaats van per query een link te kiezen. Controleer dit.

resolvectl status wg0

Een gezonde output bevat DNS Servers: 10.8.0.1 en Default Route: yes. Als Default Route de waarde no bevat, is het resolvectl domain-gedeelte niet uitgevoerd en bent u terug bij link-selectie.

Eén ander geval is het benoemen waard. Als /etc/resolv.conf een echt bestand is in plaats van een symbolische link naar /run/systemd/resolve/stub-resolv.conf, dan is een ander proces de eigenaar, meestal NetworkManager of een container-runtime. Voer ls -l /etc/resolv.conf uit voordat u iets anders debugt, omdat een tool die dat bestand bij elke netwerkwijziging overschrijft, uw werk ongedaan maakt op het minst gunstige moment.

De upgrade: uw eigen filterende resolver via de tunnel

Zodra DNS-queries betrouwbaar door de tunnel worden verstuurd, fungeert de resolver aan de andere kant als centraal controlepunt. Door daar AdGuard Home te draaien, krijgen alle verbonden apparaten blokkeerlijsten en een query-log, zonder dat er client-software of configuratie per apparaat nodig is. Het officiële installatiescript, gecontroleerd in juli 2026, bestaat uit één regel.

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

De installatiewizard luistert bij de eerste keer opstarten op poort 3000. Benader deze via de tunnel op http://10.8.0.1:3000 in plaats van de poort publiek open te stellen. Stel in de wizard zowel het DNS-luisteradres als het beheer-luisteradres in op 10.8.0.1. Als unbound uit de eerste foutmelding nog steeds hetzelfde adres gebruikt, stop deze dan eerst met sudo systemctl disable --now unbound. Twee processen kunnen namelijk niet tegelijkertijd UDP-poort 53 op hetzelfde adres binden; het tweede proces zal afsluiten met listen udp 10.8.0.1:53: bind: address already in use.

Client-configuraties hoeven niet te worden aangepast als deze al naar DNS = 10.8.0.1 wijzen. De query-log toont nu elke opzoekopdracht van elke peer. Dit is een bewuste keuze voor privacy in plaats van een gratis voordeel: u verplaatst het vertrouwen van uw internetprovider naar uzelf, en u bent zelf verantwoordelijk voor het up-to-date houden van de server. Een server die aan het internet is blootgesteld, vereist eerst de basisbeveiliging; de eerste tien minuten op een nieuwe VPS behandelt deze stappen.

FAQ

Waarom brengt mijn WireGuard-tunnel verbinding tot stand, maar worden namen niet omgezet?

De tunnel transporteert pakketten en verwerkt zelf geen namen. Een werkende tunnel met niet-werkende opzoekingen betekent dat de resolver waarnaar u verwijst, niet antwoordt. Test dit met dig +short @10.8.0.1 example.com vanaf de client. Een communication timed out-antwoord betekent dat er geen resolver luistert op dat tunneladres, vaak omdat de systemd-resolved stub alleen bindt aan 127.0.0.53, of dat de serverfirewall UDP-poort 53 blokkeert die binnenkomt op wg0. Herstel eerst de listener en open daarna de poort uitsluitend voor wg0.

Hoe controleer ik of mijn DNS lekt via WireGuard?

Voer sudo tcpdump -ni any -c 10 port 53 uit op de client en observeer de interface-kolom terwijl u surft. Elk pakket hoort via wg0 te verlopen. Als ze verschijnen op uw draadloze of ethernet-interface, verlaten de queries het systeem in leesbare tekst. dig +short whoami.akamai.net biedt een tweede controle, omdat dit antwoordt met het publieke adres van de recursieve resolver die de vraag stelde. Een antwoord dat niet het adres van uw server is, bevestigt het lek.

Heb ik de DNS =-regel nodig als ik een split tunnel gebruik?

Ja, en het resolver-adres moet zich ook binnen AllowedIPs bevinden, anders heeft de client geen route ernaartoe. Met AllowedIPs = 10.8.0.0/24 is een resolver op 10.8.0.1 gedekt en wordt de query versleuteld. Een publieke resolver zoals 9.9.9.9 is niet gedekt, waardoor de query via de lokale verbinding verloopt, ook al lijkt de DNS-regel correct.

Waarom toont resolvectl de juiste server, maar gaan opzoekingen toch ergens anders heen?

systemd-resolved houdt per verbinding een resolverlijst bij en kiest per query een verbinding. Een correcte invoer op wg0 wordt daarom genegeerd als een andere verbinding de standaardroute voor namen bevat. Voeg PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. toe aan het [Interface]-blok van de client en verwijder de DNS =-regel. resolvectl status wg0 zou daarna Default Route: yes moeten rapporteren.

Welke client moet ik eerst repareren als er meerdere defect zijn?

Repareer één Linux-client, omdat dit het enige platform is dat u het mechanisme toont. resolvectl status en tcpdump vertellen u welke resolver antwoordde en welke interface het pakket transporteerde. Telefoon- en desktop-apps passen dezelfde DNS- en AllowedIPs-waarden toe zonder zichtbare configuratie. Zodra de Linux-client correct is, kopieert u een configuratie die u al heeft bewezen.