WireGuard DNS Çalışmıyor: 3 Sorun ve Çözümü

WireGuard tüneli etkinleştiği anda DNS neden çalışmaz?

WireGuard üzerinden DNS 3 şekilde başarısız olur ve her durumun ayrı bir çözümü vardır. Hiçbir ad çözümlenmez. Adlar çözümlenir, ancak sorgular tünelin dışından makinenizden çıkar. Ya da istemcinin kendi çözümleyici yöneticisi, arayüz başlatıldıktan birkaç saniye sonra ayarı geçersiz kılar. Sorun neredeyse hiçbir zaman tünelin kendisi değildir. Sorun, istemciye hangi çözümleyiciye başvuracağını bildiren satır ve bu çözümleyiciye giden paketlerin hangi rotayı izleyeceğini belirleyen yönlendirmedir.

WireGuard IP paketlerini taşır ve DNS hakkında hiçbir bilgiye sahip değildir (ad alanı sistemi; example.com gibi adları IP adreslerine dönüştüren hizmet). İstemci [Interface] bloğundaki DNS = satırı bir WireGuard ayarı değildir. Bu satır, arayüzü etkinleştiren kabuk sarmalayıcısı wg-quick tarafından okunur. Ardından wg-quick, tünel etkin durumdayken istemcinin çözümleyici yapılandırmasını düzenler ve tünel wg-quick down durumuna geldiğinde yapılandırmayı geri yükler. Bu nedenle aşağıdaki sorunların tümü yönlendirme sorunu veya wg-quick sorunudur; kriptografi sorunu değildir. Tünelin kendisi henüz oluşturulmadıysa kendi VPS'niz üzerinde barındırılan bir WireGuard VPN ile başlayın ve ardından bu sayfaya dönün.

DNS ayarlarına hiç dokunmadan önce tünelin sağlıklı olduğunu doğrulayın.

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

wg show çıktısında yakın tarihli bir latest handshake ile eş gösterilmeli ve her iki ping isteğine de yanıt alınmalıdır. ping 1.1.1.1 zaman aşımına uğrarsa DNS sorunu yerine iletme veya NAT (ağ adresi çevirisi) sorununuz vardır; hiçbir çözümleyici yapılandırması bunu gideremez. Buradaki tüm örneklerde tünel alt ağı olarak 10.8.0.0/24 ve sunucunun tünel adresi olarak 10.8.0.1 kullanılır. Kendi değerlerinizi kullanın.

Birinci arıza: çözümleyici hiç yanıt vermediği için hiçbir ad çözümlenmiyor

Belirti nettir. ping 1.1.1.1 çalışır, curl https://example.com ise şunu döndürür:

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

Tünel çözümleyicisine doğrudan istemciden sorgu gönderin. dig, Ubuntu ve Debian sistemlerinde dnsutils paketinden gelir.

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

İlk komut bir adres döndürür. Bu, paketlerin tünel üzerinden internete ulaştığını kanıtlar. İkinci komut hiçbir şey döndürmez ve ;; communication timed out; no servers could be reached yazdırır. Tanı nettir: istemciniz 10.8.0.1 adresini kullanacak şekilde yapılandırılmıştır ve 10.8.0.1, UDP port 53 üzerinden yanıt vermemektedir.

Buna iki neden yol açar. Sunucuda hiçbir çözümleyici çalışmıyor olabilir veya sunucunun güvenlik duvarı sorguyu sunucuya ulaşmadan düşürüyor olabilir. Sunucuda her iki durumu da denetleyin.

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

Çalışan ve doğru adrese bağlanmış bir çözümleyici, 10.8.0.1:53 veya 0.0.0.0:53 içeren bir satır gösterir. Ubuntu sistemlerinde genellikle şaşırtıcı olan 127.0.0.53:53 değeridir. Bu, bir loopback adresine bağlanan ve diğer makinelerden bilerek erişilemeyen systemd-resolved stub listener bileşenidir. VPN istemcisini yalnızca bu stub çözümleyicisine sahip bir sunucuya yönlendirmek, tam olarak bu zaman aşımına neden olur.

Çözüm, tünel adresini dinleyen bir çözümleyici ve eşlerin bu çözümleyiciye erişmesine izin veren bir güvenlik duvarı kuralıdır.

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'

Ardından portu yalnızca tünel trafiği için açın. nftables kullanıyorsanız /etc/nftables.conf içindeki input zincirine bu iki satırı ekleyin ve sudo systemctl reload nftables ile yeniden yükleyin.

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

ufw kullanıyorsanız sudo ufw allow in on wg0 to any port 53 aynı işi yapar. Port 53'ü genel internete hiçbir zaman açmayın. Açık bir recursive resolver, tarayıcılar tarafından birkaç gün içinde bulunur ve hizmet reddi saldırılarını büyütmek için kullanılır. Sağlayıcınız bu trafiği sizden önce fark eder.

İstemciden dig +short @10.8.0.1 example.com komutunu yeniden çalıştırın. Çıktıda bir adres bulunması, çözümleyici yolunun çalıştığı anlamına gelir. Bu durumda istemcinin artık yalnızca bu çözümleyiciyi kullanması gerekir. Satırı istemcinin [Interface] bloğuna ekleyin ve arayüzü sudo wg-quick down wg0 && sudo wg-quick up wg0 ile yeniden başlatın.

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

İkinci arıza: DNS sızıntıları; split tunnel, resolver trafiğini yönlendirmez

Bu durum daha kötüdür, çünkü her şey çalışıyor gibi görünür. Adlar çözümlenir, sayfalar yüklenir ve sorgular güvenilmeyen yerel ağ üzerinden açık metin olarak iletilir.

Buna iki yapılandırma neden olur. İlki, AllowedIPs = 0.0.0.0/0, ::/0 içeren ancak DNS = satırı bulunmayan istemcidir. wg-quick varsayılan rotayı kendi yönlendirme tablosuna ekler ve suppress_prefixlength 0 ile bir kural oluşturur. Bu kural, makinenin yazıcısına erişebilmesi için daha özgül yerel rotaların kullanılmaya devam etmesini sağlar. İstemcinin DHCP üzerinden öğrendiği resolver, genellikle 192.168.1.1 adresindeki yönlendirici, bu yerel rotalardan biriyle eşleşir. Trafiğiniz tünelden geçer. Ancak yerel ağ, aradığınız tüm adların listesini almaya devam eder.

İkincisi, AllowedIPs = 10.8.0.0/24 ile DNS = 9.9.9.9 kullanılan bir split tunnel yapılandırmasıdır. 9.9.9.9, AllowedIPs içinde olmadığı için istemcinin bu adrese tünel üzerinden giden bir rotası yoktur. Bu nedenle sorgu, ilk durumdaki gibi yerel bağlantı üzerinden çıkar.

Gerçekte hangi resolver'ın yanıt verdiğini kanıtlayın. whoami.akamai.net, sorguyu yapan özyinelemeli resolver'ın IP adresiyle yanıt veren herkese açık bir test adıdır. Böylece yanıtı sunucunuzun herkese açık adresiyle karşılaştırabilirsiniz.

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

resolvectl status, her bağlantı için bir blok yazdırır. Ethernet veya kablosuz bağlantınıza ait blokta hâlâ Current DNS Server: 192.168.1.1 gösterilirken wg0 bloğunda hiç sonuç yoksa sızıntı vardır. dig +short whoami.akamai.net komutunun sunucunuzun adresi yerine ev geniş bant bağlantınızın adresini döndürmesi, durumu uzak uçtan doğrular. tcpdump satırı, tartışmayı sona erdiren kanıttır: sağlıklı çıktıda 53 numaralı porta giden tüm paketler wg0 üzerinden geçer. Sızıntıda ise paketler wlan0 veya enp3s0 üzerinden geçer.

Düzeltme iki bölümden oluşur ve her ikisi de gereklidir. DNS değerini tünelin içinde bulunan bir adrese ayarlayın ve bu adresin AllowedIPs içinde olduğundan emin olun.

[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, 10.8.0.0/24 içinde bulunur. Bu nedenle sorgu şifrelenir ve sunucuya gönderilir. Split tunnel üzerinde herkese açık bir resolver kullanmakta ısrar ediyorsanız bunu bir ana bilgisayar rotası olarak ekleyin: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Paketler böylece tünellenir. Ancak yerel ağ, önceki oturumlardan bu sağlayıcıyı seçtiğinizi yine görebilir. Kendi çalıştırdığınız bir resolver bu sorunu ortadan kaldırır.

Resolver ataması, elle oluşturulan WireGuard ile koordineli bir mesh arasındaki görünür farklardan biridir. Bu fark, WireGuard ile Tailscale karşılaştırması bölümünde açıklanan ödünleşimin bir parçasıdır. Kendi barındırdığınız Headscale control server'ı çalıştırmak, anahtar materyalinizi üçüncü bir tarafa teslim etmeden bu koordinasyonu sağlar.

Üçüncü arıza: Linux istemcilerinde resolvconf ile systemd-resolved çakışıyor

macOS, Windows, iOS ve Android istemcileri DNS = ayarını resmi uygulama üzerinden uygular ve genellikle sorun çıkarmaz. Sorun Linux'ta ortaya çıkar. Burada ayar, hangi resolver yöneticilerinden birinin kullanıldığını tahmin etmek zorunda olan bir kabuk betiği tarafından uygulanır.

İlk arıza belirgindir. sudo wg-quick up wg0 şu iletiyle durur:

resolvconf: command not found

wg-quick, resolvconf dosyasını çağırır. Ancak bu ikili kurulu değildir. systemd-resolved ile iletişim kuran uygulamayı kurun ve ardından arayüzü yeniden etkinleştirin.

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

İkinci arıza sessizdir ve bir akşamın kaybedilmesine neden olan da budur. Arayüz etkinleşir, resolvectl status wg0 doğru biçimde DNS Servers: 10.8.0.1 değerini gösterir, ancak sorgular hâlâ eski resolver'a gider. systemd-resolved her bağlantı için ayrı bir resolver listesi tutar ve her sorgu için bir bağlantı seçer. Adlar için bir bağlantı varsayılan rota olarak işaretlenmediği sürece kablosuz bağlantının resolver'ını kullanmaya devam eder. Bunun nedeni, kablosuz bağlantıda bir arama etki alanı bulunması, sizin bağlantınızda ise bulunmamasıdır.

Resolver'ı ayarlayın ve varsayılan rotayı aynı adımda tanımlayın. %i, arayüz adını alır. Bu nedenle bu blok her arayüzde değişiklik yapılmadan çalışır.

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

PostUp komutunu bu şekilde kullandığınızda DNS = satırını silin. Aksi halde resolver durumunu iki mekanizma yazar ve sonrasında yalnızca biri temizleme işlemini gerçekleştirir. ~. bağımsız değişkeni kritik bölümdür. wg0 değerini her ad için yönlendirme etki alanı olarak işaretler. Böylece systemd-resolved, her sorgu için bağlantı seçmek yerine tüm sorguları oraya gönderir. Doğrulayın.

resolvectl status wg0

Sağlıklı çıktıda DNS Servers: 10.8.0.1 ve Default Route: yes bulunur. Default Route, no değerini gösteriyorsa resolvectl domain bölümü çalışmamıştır ve bağlantı seçimine geri dönülmüştür.

Belirtilmesi gereken bir durum daha vardır. /etc/resolv.conf, /run/systemd/resolve/stub-resolv.conf konumuna sembolik bağlantı yerine gerçek bir dosyaysa dosyanın sahibi başka bir bileşendir. Bu genellikle NetworkManager veya bir container runtime olur. Başka bir şeyi hata ayıklamadan önce ls -l /etc/resolv.conf komutunu çalıştırın. Çünkü her ağ değişikliğinde bu dosyayı yeniden yazan bir araç, en uygunsuz anda yaptığınız değişiklikleri geri alır.

Yükseltme: tünel üzerinden kendi filtreleme çözümleyiciniz

Sorgular tünelden güvenilir biçimde geçmeye başladığında, uzak uçtaki çözümleyici bir denetim noktası hâline gelir. AdGuard Home burada çalıştırıldığında, bağlanan tüm cihazlara istemci yazılımı veya cihaz başına yapılandırma gerektirmeden engelleme listesi filtrelemesi ve sorgu günlüğü sağlanır. Temmuz 2026'da denetlenen resmi kurulum betiği tek satırdan oluşur.

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

Kurulum sihirbazı ilk çalıştırmada 3000 numaralı bağlantı noktasını dinler. Bu bağlantı noktasını herkese açık hâle getirmek yerine tünel üzerinden http://10.8.0.1:3000 adresine erişin. Sihirbazda hem DNS dinleme adresini hem de yönetim dinleme adresini 10.8.0.1 olarak ayarlayın. Birinci hatadaki unbound hâlâ aynı adresi kullanıyorsa önce sudo systemctl disable --now unbound ile durdurun. Çünkü tek bir adreste UDP 53 numaralı bağlantı noktasına iki işlem bağlanamaz ve ikinci işlem listen udp 10.8.0.1:53: bind: address already in use ile sonlanır.

İstemci yapılandırmalarında zaten DNS = 10.8.0.1 belirtiliyorsa değişiklik yapılması gerekmez. Sorgu günlüğünde artık tüm eşlerden gelen her arama gösterilir. Bu, karşılıksız bir kazanım değil, gerçek bir gizlilik tercihidir. Güveni internet sağlayıcınızdan kendinize aktarırsınız ve bu sistemi güncel tutmanız gerekir. İnternete açık bir sunucuda önce temel önlemler alınmalıdır. Yeni bir VPS'te ilk on dakika bu önlemleri kapsar.

FAQ

WireGuard tünelim bağlanıyor, ancak adlar neden çözümlenmiyor?

Tünel paketleri taşır ve adları hiç işlemez. Bu nedenle çalışan bir tünel ile bozuk ad çözümleme, yönlendirdiğiniz çözümleyicinin yanıt vermediği anlamına gelir. İstemciden dig +short @10.8.0.1 example.com ile test edin. communication timed out yanıtı, tünel adresinde hiçbir çözümleyicinin dinlemediği veya systemd-resolved stub'unun yalnızca 127.0.0.53 adresine bağlandığı ya da sunucu güvenlik duvarının wg0 üzerinden gelen UDP 53 numaralı port trafiğini engellediği anlamına gelir. Önce dinleyiciyi düzeltin. Ardından portu yalnızca wg0 için açın.

DNS sızıntısı olup olmadığını WireGuard üzerinden nasıl denetlerim?

İstemcide sudo tcpdump -ni any -c 10 port 53 komutunu çalıştırın ve gezinirken arabirim sütununu izleyin. Her paket wg0 üzerinde olmalıdır. Paketler kablosuz veya ethernet arabiriminizde görünüyorsa sorgular açık metin olarak dışarı çıkıyordur. dig +short whoami.akamai.net ikinci bir doğrulama sağlar. Bu komut, sorguyu alan özyinelemeli çözümleyicinin genel adresiyle yanıt verir. Sunucunuzun adresi olmayan bir yanıt, sızıntıyı doğrular.

Bölünmüş tünel kullanıyorsam DNS = satırına ihtiyacım var mı?

Evet. Çözümleyici adresi ayrıca AllowedIPs içinde bulunmalıdır. Aksi halde istemcinin bu adrese giden rotası olmaz. AllowedIPs = 10.8.0.0/24 ile 10.8.0.1 adresindeki çözümleyici kapsanır ve sorgu şifrelenir. 9.9.9.9 gibi genel bir çözümleyici kapsanmaz. Bu nedenle DNS satırı doğru görünse bile sorgu yerel bağlantı üzerinden dışarı çıkar.

resolvectl doğru sunucuyu gösterdiği halde sorgular neden başka yere gidiyor?

systemd-resolved her bağlantı için ayrı bir çözümleyici listesi tutar ve her sorgu için bir bağlantı seçer. Bu nedenle wg0 üzerindeki doğru giriş, başka bir bağlantı adlar için varsayılan rotayı taşıdığı sürece yok sayılır. İstemcinin [Interface] bloğuna PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. ekleyin ve DNS = satırını kaldırın. Ardından resolvectl status wg0, Default Route: yes bildirmelidir.

Birden çok istemcide sorun varsa önce hangisini düzeltmeliyim?

Bir Linux istemcisini düzeltin. Mekanizmayı gösteren tek platform budur. resolvectl status ve tcpdump, hangi çözümleyicinin yanıt verdiğini ve paketin hangi arabirim üzerinden taşındığını gösterir. Telefon ve masaüstü uygulamaları aynı DNS ve AllowedIPs değerlerini görünür bir ağ yapılandırması olmadan uygular. Linux istemcisi doğru çalıştığında, zaten doğruladığınız bir yapılandırmayı kopyalamış olursunuz.