DNS via WireGuard werkt niet: 3 oorzaken

Waarom DNS niet meer werkt zodra de WireGuard-tunnel tot stand komt

DNS via WireGuard werkt op drie manieren niet. Voor elk probleem is er een eigen oplossing. Er wordt helemaal niets opgelost, namen worden wel opgelost maar de query's verlaten uw machine buiten de tunnel om, of de eigen resolverbeheerder van de client overschrijft de instelling enkele seconden nadat de interface is gestart. De tunnel is bijna nooit het probleem. Het probleem is de regel die de client vertelt welke resolver moet worden geraadpleegd en de routing die bepaalt hoe pakketten naar die resolver reizen.

WireGuard transporteert IP-pakketten en heeft geen kennis van DNS (domain name system, de service die namen zoals example.com omzet in IP-adressen). De regel DNS = in een clientblok [Interface] is geen WireGuard-instelling. Deze wordt gelezen door wg-quick, de shell-wrapper die de interface activeert. Vervolgens wijzigt wg-quick de resolverconfiguratie van de client zolang de tunnel actief is en herstelt deze configuratie bij wg-quick down. Elk probleem hieronder is daarom een routingprobleem of een probleem met wg-quick, en nooit een cryptografieprobleem. Als de tunnel zelf nog niet is geconfigureerd, begint u met een zelf gehoste WireGuard-VPN op uw eigen VPS en keert u daarna naar deze pagina terug.

Controleer eerst of de tunnel goed werkt voordat u DNS aanpast.

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

wg show moet de peer met een recente latest handshake tonen, en beide pings moeten antwoord geven. Als ping 1.1.1.1 een time-out geeft, hebt u een probleem met forwarding of NAT (network address translation) en geen DNS-probleem. Geen enkele resolverconfiguratie lost dat op. In elk voorbeeld hier wordt 10.8.0.0/24 gebruikt als het tunnelsubnet en 10.8.0.1 als het tunneladres van de server. Vervang deze waarden door uw eigen waarden.

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

Het symptoom is duidelijk. ping 1.1.1.1 werkt, maar curl https://example.com retourneert het volgende:

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

Vraag de tunnelresolver rechtstreeks op vanaf de client. dig maakt deel uit van het pakket dnsutils op Ubuntu en Debian.

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

De eerste opdracht retourneert een adres. Daarmee is bewezen dat pakketten via de tunnel het internet bereiken. De tweede opdracht retourneert niets en geeft ;; communication timed out; no servers could be reached weer. Dat is de volledige diagnose: uw client verwijst naar 10.8.0.1, maar 10.8.0.1 antwoordt niet op UDP-poort 53.

Er zijn twee mogelijke oorzaken. Er draait geen resolver op de server, of de firewall van de server verwijdert de query voordat deze aankomt. Controleer beide op de server.

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

Een resolver die actief is en correct luistert, toont een regel met 10.8.0.1:53 of 0.0.0.0:53. Op Ubuntu is 127.0.0.53:53 meestal de oorzaak van de verwarring. Dit is de stub-listener van systemd-resolved. Deze luistert op een loopbackadres en is bewust niet bereikbaar vanaf andere machines. Als u een VPN-client laat verwijzen naar een server waarvan de enige resolver deze stub is, ontstaat precies deze time-out.

De oplossing is een resolver die op het tunneladres luistert, plus één firewallregel waarmee peers de resolver kunnen 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 uitsluitend voor tunnelverkeer. Voeg met nftables deze twee regels toe aan de keten input in /etc/nftables.conf en laad de configuratie opnieuw 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. Scanners vinden een open recursieve resolver binnen enkele dagen en gebruiken deze om denial-of-serviceaanvallen te versterken. Uw provider merkt dat verkeer eerder op 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. De client hoeft de resolver nu alleen nog te gebruiken. Voeg de regel toe aan het [Interface]-blok van de client en start de interface opnieuw 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-lekken, omdat een split tunnel de resolver niet routeert

Dit is ernstiger, omdat alles lijkt te werken. Namen worden omgezet, pagina's laden en de query's gaan als 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 een regel voor DNS =. wg-quick installeert de standaardroute in zijn eigen routingtabel en voegt een regel toe met suppress_prefixlength 0. Hierdoor blijven specifiekere lokale routes bewust actief, zodat de machine bijvoorbeeld nog steeds zijn printer kan bereiken. De resolver die de client via DHCP heeft ontvangen, meestal de router op 192.168.1.1, valt onder een van die lokale routes. Uw verkeer gaat door de tunnel. Het lokale netwerk ontvangt nog steeds de volledige lijst met namen die u opvraagt.

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

Controleer welke resolver daadwerkelijk antwoord geeft. whoami.akamai.net is een openbare testnaam die antwoordt met het IP-adres van de recursieve resolver die de query heeft uitgevoerd. Zo kunt u het antwoord vergelijken met het openbare adres van uw server.

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

resolvectl status geeft één blok per verbinding weer. Als het blok voor uw ethernet- of draadloze verbinding nog steeds Current DNS Server: 192.168.1.1 toont, terwijl het blok wg0 niets toont, is dat het lek. Als dig +short whoami.akamai.net uw adres voor thuisbreedband teruggeeft in plaats van het adres van uw server, wordt dit vanaf de externe kant bevestigd. De regel tcpdump levert het doorslaggevende bewijs: bij een correcte configuratie gaat elk pakket naar poort 53 via wg0. Bij een lek gaat het via wlan0 of enp3s0.

De oplossing bestaat uit twee delen. Beide zijn vereist. Stel DNS in op een adres dat binnen de tunnel ligt en zorg ervoor dat dit 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 valt binnen 10.8.0.0/24. De query wordt daardoor versleuteld en naar de server verzonden. Als u op een split tunnel toch een openbare resolver wilt gebruiken, voegt u deze toe als hostroute: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. De pakketten worden dan door de tunnel geleid, maar het lokale netwerk kan nog steeds zien dat u deze provider in eerdere sessies hebt gekozen. Met een resolver die u zelf beheert, voorkomt u dit probleem.

Het toewijzen 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 zelf gehoste Headscale-controlserver krijgt u die coördinatie zonder uw sleutelmateriaal aan een derde partij te verstrekken.

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

macOS-, Windows-, iOS- en Android-clients passen DNS = toe via de officiële app en veroorzaken weinig problemen. Op Linux wordt de instelling toegepast door een shellscript dat moet bepalen welke van meerdere resolverbeheerders u gebruikt.

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

resolvconf: command not found

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

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 blijft onopgemerkt. Deze fout kost vaak een avond. De interface komt omhoog, resolvectl status wg0 toont correct DNS Servers: 10.8.0.1 en zoekopdrachten gaan nog steeds naar de oude resolver. systemd-resolved houdt per link een afzonderlijke resolverlijst bij en selecteert per query een link. Als geen enkele link als standaardroute voor namen is gemarkeerd, blijft systemd-resolved de resolver van de draadloze link gebruiken. Die link heeft namelijk een zoekdomein en uw link niet.

Stel de resolver in en claim de standaardroute in dezelfde stap. %i wordt vervangen door 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 regel DNS = wanneer u PostUp op deze manier gebruikt. Anders schrijven twee mechanismen de resolverstatus en ruimt slechts één ervan die status daarna op. Het argument ~. is het belangrijkste onderdeel. Hiermee wordt wg0 ingesteld als het routeringsdomein voor elke naam, zodat systemd-resolved alle queries daarheen stuurt in plaats van per query een link te selecteren. Controleer de configuratie.

resolvectl status wg0

Een gezonde uitvoer bevat DNS Servers: 10.8.0.1 en Default Route: yes. Als Default Route no bevat, is het onderdeel resolvectl domain niet uitgevoerd en gebruikt u opnieuw linkselectie.

Er is nog een situatie die het vermelden waard is. Als /etc/resolv.conf een echt bestand is in plaats van een symbolische link naar /run/systemd/resolve/stub-resolv.conf, wordt het bestand door iets anders beheerd, meestal NetworkManager of een containerruntime. Voer ls -l /etc/resolv.conf uit voordat u iets anders debugt. Een hulpprogramma dat dit bestand bij elke netwerkwijziging opnieuw overschrijft, maakt uw wijzigingen op het minst geschikte moment ongedaan.

De upgrade: uw eigen filterende resolver via de tunnel

Zodra query's betrouwbaar door de tunnel gaan, wordt de resolver aan het andere uiteinde een controlepunt. Als u AdGuard Home daar uitvoert, krijgen alle verbonden apparaten blocklistfiltering en een querylogboek, zonder clientsoftware en zonder configuratie per apparaat. 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 uitvoering op port 3000. Open deze via de tunnel op http://10.8.0.1:3000 in plaats van deze port openbaar open te stellen. Stel in de wizard zowel het DNS-listenadres als het admin-listenadres in op 10.8.0.1. Als unbound uit fout één nog steeds hetzelfde adres gebruikt, stopt u dit eerst met sudo systemctl disable --now unbound. Twee processen kunnen namelijk niet UDP-port 53 op één adres binden. Het tweede proces wordt dan beëindigd met listen udp 10.8.0.1:53: bind: address already in use.

De clientconfiguraties hoeven niet te worden gewijzigd als daarin al DNS = 10.8.0.1 staat. Het querylogboek toont nu elke lookup van elke peer. Dat is een echte privacykeuze en geen kosteloze verbetering: u verplaatst het vertrouwen van uw internetprovider naar uzelf. U bent ook verantwoordelijk voor het up-to-date houden van die server. Een server die aan het internet is blootgesteld, moet eerst de basisbeveiliging op orde hebben. de eerste tien minuten op een nieuwe VPS behandelt deze stappen.

FAQ

Waarom maakt mijn WireGuard-tunnel verbinding, maar worden namen niet omgezet?

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

Hoe controleer ik of mijn DNS-verkeer via WireGuard lekt?

Voer sudo tcpdump -ni any -c 10 port 53 uit op de client en controleer de interfacekolom terwijl u websites bezoekt. Elk pakket moet op wg0 staan. Als de pakketten op uw draadloze of ethernetinterface verschijnen, verlaten de query's het systeem als niet-versleuteld verkeer. dig +short whoami.akamai.net biedt een tweede controle. Deze opdracht antwoordt met het openbare adres van de recursieve resolver die de query heeft uitgevoerd. Een antwoord dat niet het adres van uw server is, bevestigt het lek.

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

Ja. Het resolveradres moet ook binnen AllowedIPs vallen, anders heeft de client er geen route naartoe. Met AllowedIPs = 10.8.0.0/24 valt een resolver op 10.8.0.1 binnen het bereik en wordt de query versleuteld. Een openbare resolver zoals 9.9.9.9 valt er niet binnen. De query verlaat het systeem dan via de lokale verbinding, ook al lijkt de regel DNS correct.

Waarom toont resolvectl de juiste server, maar gaan zoekopdrachten toch ergens anders naartoe?

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

Welke client moet ik als eerste herstellen als meerdere clients niet werken?

Herstel eerst één Linux-client, omdat alleen dit platform laat zien hoe het mechanisme werkt. resolvectl status en tcpdump tonen welke resolver heeft geantwoord en via welke interface het pakket is verzonden. Apps op telefoons en desktops passen dezelfde waarden voor DNS en AllowedIPs toe zonder de onderliggende configuratie zichtbaar te maken. Zodra de Linux-client correct werkt, kopieert u dus een configuratie die u al hebt gecontroleerd.