WireGuard DNS Sorunları ve Çözüm Yöntemleri

WireGuard tüneli kurulduğu anda DNS neden kesilir

WireGuard üzerinden DNS kullanımı üç farklı şekilde başarısız olur ve her birinin kendine özgü bir çözümü vardır. Hiçbir isim çözümlenemez, isimler çözümlenir ancak sorgular tünel dışından makinenizden çıkar veya istemcinin kendi çözümleyici yöneticisi, arayüz başladıktan saniyeler sonra ayarı üzerine yazar. Sorun neredeyse hiçbir zaman tünelin kendisi değildir. Sorun, istemciye hangi çözümleyiciye soracağını söyleyen tek satır ve bu çözümleyiciye giden paketlerin nasıl ilerleyeceğine karar veren yönlendirme (routing) ayarıdır.

WireGuard IP paketlerini taşır ve DNS (alan adı sistemi, example.com gibi isimleri IP adreslerine dönüştüren servis) hakkında hiçbir şey bilmez. Bir istemci [Interface] bloğundaki DNS = satırı bir WireGuard ayarı değildir. Bu satır, arayüzü ayağa kaldıran kabuk sarmalayıcısı wg-quick tarafından okunur; ardından wg-quick, tünel aktifken istemcinin çözümleyici yapılandırmasını düzenler ve wg-quick down komutunda bu ayarları geri yükler. Dolayısıyla aşağıdaki her sorun bir yönlendirme veya wg-quick sorunudur, asla bir şifreleme sorunu değildir. Eğer tünelin kendisi henüz kurulmadıysa, önce kendi VPS'inizde self-hosted WireGuard VPN kurulumu ile başlayın ve ardından bu sayfaya geri dönün.

DNS ayarlarına 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, eşi (peer) yakın tarihli bir latest handshake ile listelemeli ve her iki ping de yanıt vermelidir. Eğer ping 1.1.1.1 zaman aşımına uğruyorsa, DNS sorunundan ziyade büyük olasılıkla bir yönlendirme veya NAT (ağ adresi çevirisi) sorununuz vardır ve çözümleyici yapılandırmasını değiştirmek bir işe yaramayacaktır. ICMP paketlerini düşüren bir güvenlik duvarı da aynı zaman aşımına neden olur, bu yüzden yönlendirme kurallarını değiştirmeye başlamadan önce curl -sI https://1.1.1.1 ile doğrulama yapın. Eğer pingler yanıt veriyor ancak gerçek trafik başladığında aktarım hızı çöküyorsa, bu ayrı bir arıza hattıdır ve yavaş WireGuard neredeyse her zaman MTU kaynaklıdır, bu sayfadaki başka bir şeyden kaynaklanmaz. Buradaki her örnekte tünel alt ağı olarak 10.8.0.0/24 ve sunucunun tünel adresi olarak 10.8.0.1 kullanılmıştır. Kendi değerlerinizi kullanın.

Birinci hata: Çözücü yanıt vermediği için hiçbir adres çözümlenemiyor

Belirti kesindir. ping 1.1.1.1 çalışır ancak curl https://example.com şu çıktıyı verir:

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

Tünel çözücüsüne doğrudan istemci üzerinden sorgu gönderin. dig, Ubuntu ve Debian üzerinde 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 çıktısını verir. Teşhisin tamamı budur: istemciniz 10.8.0.1 adresine yönlendirilmiştir ve 10.8.0.1, UDP 53 numaralı portta yanıt vermemektedir.

Buna iki durum neden olur. Ya sunucuda çalışan bir çözücü yoktur ya da sunucu güvenlik duvarı sorguyu ulaşmadan önce düşürüyordur. Her ikisini de sunucu üzerinde kontrol edin.

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

Çalışan ve doğru şekilde bağlanan bir çözücü, 10.8.0.1:53 veya 0.0.0.0:53 içeren bir satır gösterir. Ubuntu'da sürpriz genellikle 127.0.0.53:53 olur: bu, loopback adresine bağlanan ve diğer makinelerden erişilmesi kasıtlı olarak engellenen systemd-resolved stub dinleyicisidir. Bir VPN istemcisini, tek çözücüsü bu stub olan bir sunucuya yönlendirmek tam olarak bu zaman aşımı hatasına yol açar.

Çözüm, tünel adresini dinleyen bir çözücü ve eşlerin buna ulaşmasına 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ğine açın. nftables ile, /etc/nftables.conf içindeki input zincirine şu 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 ile sudo ufw allow in on wg0 to any port 53 aynı işi yapar. 53 numaralı portu asla genel internete açmayın. Açık bir yinelemeli (recursive) çözücü, tarayıcılar tarafından günler içinde bulunur ve hizmet engelleme saldırılarını (DoS) güçlendirmek için kullanılır; servis sağlayıcınız bu trafiği sizden önce fark edecektir.

İstemci üzerinde dig +short @10.8.0.1 example.com komutunu tekrar çalıştırın. Çıktıda bir adresin görünmesi, çözücü yolunun çalıştığı anlamına gelir; artık istemcinin sadece bunu kullanması yeterlidir. İlgili satırı istemci [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 hata: Split tunnel yapılandırması çözümleyiciyi yönlendirmediği için oluşan DNS sızıntıları

Bu durum daha kötüdür, çünkü her şey çalışıyor gibi görünür. İsimler çözümlenir, sayfalar yüklenir ve sorgular, güvenmediğiniz yerel ağ üzerinden şifrelenmemiş (cleartext) olarak iletilir.

Buna iki yapılandırma neden olur. Birincisi, AllowedIPs = 0.0.0.0/0, ::/0 içeren ancak DNS = satırı bulunmayan bir istemcidir. wg-quick, kendi yönlendirme tablosuna varsayılan rotayı yükler ve suppress_prefixlength 0 ile bir kural ekler; bu kural, makinenin yazıcısına erişebilmesi için daha spesifik yerel rotaları bilerek aktif tutar. İstemcinin DHCP aracılığıyla öğrendiği çözümleyici (genellikle 192.168.1.1 adresindeki yönlendirici), bu yerel rotalardan biriyle eşleşir. Trafiğiniz tünel üzerinden akar, ancak yerel ağ arattığınız tüm isimlerin listesini görmeye devam eder.

İkincisi ise split tunnel yapılandırmasıdır: DNS = 9.9.9.9 ile AllowedIPs = 10.8.0.0/24. 9.9.9.9, AllowedIPs içinde yer almadığı için istemcinin tünel üzerinden ona giden bir rotası yoktur; bu nedenle sorgu, tıpkı ilk vakada olduğu gibi yerel bağlantı üzerinden çıkar.

Hangi çözümleyicinin yanıt verdiğini kanıtlayın. whoami.akamai.net, sorguyu yapan yinelemeli çözümleyicinin (recursive resolver) IP adresini döndüren genel bir test ismidir; böylece bu yanıtı sunucunuzun genel 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ız için olan blok hala Current DNS Server: 192.168.1.1 gösterirken wg0 bloğu hiçbir şey göstermiyorsa, bu bir sızıntıdır. dig +short whoami.akamai.net komutunun sunucunuzun adresi yerine evinizdeki geniş bant adresinizi döndürmesi, durumu uzak uçtan doğrular. tcpdump satırı, tartışmaları sonlandıran kanıttır: sağlıklı bir çıktıda makineden çıkan her 53 numaralı port paketi wg0 üzerindedir; sızıntı durumunda ise bu paketler wlan0 veya enp3s0 üzerindedir. 127.0.0.53 adresine veya adresinden lo üzerindeki paketler, yerel systemd-resolved stub ile konuşan uygulamalardır ve bunlar sızıntı değildir.

Çözüm iki aşamalıdır ve her ikisi de gereklidir. DNS değerini tünel içinde yer alan 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 yer alır; bu nedenle sorgu şifrelenir ve sunucuya gönderilir. Split tunnel üzerinde genel bir çözümleyici kullanmakta ısrar ediyorsanız, onu bir host rotası olarak ekleyin: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Bu durumda paketler tünellenir, ancak yerel ağ önceki oturumlardan o sağlayıcıyı seçtiğinizi görmeye devam edebilir. Kendi çalıştırdığınız bir çözümleyici bu soruyu ortadan kaldırır.

Çözümleyici ataması, elle yapılandırılmış WireGuard ile koordine edilmiş bir ağ (mesh) arasındaki gözle görülür farklardan biridir ve bu, WireGuard ve Tailscale karşılaştırması konusundaki ödünleşimlerin bir parçasıdır. Kendi kendine barındırılan bir Headscale kontrol sunucusu çalıştırmak, anahtar materyalinizi üçüncü bir tarafa vermeden bu koordinasyonu sağlar. Eğer endişelendiğiniz konu buysa, Tailscale trafiğinizi şifreleyen anahtarları asla tutmaz bilgisini not edin; daha kritik soru, ele geçirilmiş bir koordinasyon sunucusunun veya çalınmış bir kimlik hesabının ağınıza neler ekleyebileceğidir.

Üçüncü hata: Linux istemcilerinde resolvconf ve systemd-resolved çakışması

macOS, Windows, iOS ve Android istemcileri DNS = ayarını resmi uygulama üzerinden uygular ve genellikle sorun çıkarmaz. Linux tarafında ise bu ayar, sisteminizde yüklü olan birden fazla çözümleyici yöneticisinden hangisinin çalıştığını tahmin etmeye çalışan bir kabuk betiği ile uygulanır.

İlk hata belirgindir. sudo wg-quick up wg0 şu hata ile durur:

resolvconf: command not found

wg-quick, resolvconf komutunu çağırır ancak bu ikili dosya yüklü değildir. Debian 12 ve Ubuntu 24.04 veya sonraki sürümlerde, systemd-resolved ile iletişim kuran resolvconf komutu systemd-resolved paketi ile birlikte gelir; bu nedenle paketi yükleyin ve ardından arayüzü tekrar ayağa kaldırın. Ubuntu 22.04'te bunun için ayrı bir paket yoktur; bu durumda sudo ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf ile uyumluluk bağlantısını kendiniz oluşturun ve yükleme adımını atlayın.

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

İkinci hata sessizdir ve bir akşamınızı harcamanıza neden olabilir. Arayüz ayağa kalkar, resolvectl status wg0 doğru bir şekilde DNS Servers: 10.8.0.1 değerini gösterir ancak sorgular hala eski çözümleyiciye ulaşmaya devam eder. systemd-resolved, wg0 ayarını görmezden gelmiyor. Hiçbir yönlendirme alanıyla eşleşmeyen bir isim, varsayılan rota olarak kabul edilen her bağlantının DNS sunucularına gönderilir; DNS sunucuları olan ve yönlendirme alanı (route-only domain) tanımlanmamış bir bağlantı, varsayılan olarak bu şekilde kabul edilir. Bu nedenle sorgu aynı anda hem 10.8.0.1 adresine hem de kablosuz bağlantıdaki yönlendiriciye gider ve ilk başarılı yanıt kazanan olur. Yönlendirici bir atlama (hop) uzaklıktadır ve genellikle ilk yanıtı o verir; sorgu her iki durumda da şifrelenmemiş (cleartext) olarak çıkmış olur. lan gibi kablosuz bağlantının kendi arama alanına giren isimler, en spesifik yönlendirme alanı kazandığı için yalnızca o bağlantıya gider.

wg-quick, DNS = ayarını systemd'nin kendi resolvconf sarmalayıcısı üzerinden uyguladığında, zaten bir "catch-all" (her şeyi kapsayan) yönlendirme alanı talep eder. Bu nedenle bu hata genellikle başka bir resolvconf uygulaması veya bir ağ yöneticisi ayarı uyguladığında ortaya çıkar. Ayarı açıkça belirtmek, tahmin yürütme gerekliliğini ortadan kaldırır.

Çözümleyiciyi ayarlayın ve "catch-all" yönlendirme alanını aynı adımda tanımlayın. %i, arayüz adına genişletilir, bu nedenle bu blok herhangi bir 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 aracını bu şekilde kullandığınızda DNS = satırını silin; aksi takdirde iki farklı mekanizma çözümleyici durumunu yazar ve sonrasında yalnızca biri temizlik yapar. ~. argümanı işin önemli kısmıdır: wg0 değerini her isim için yönlendirme alanı (route-only domain) haline getirir, böylece systemd-resolved daha spesifik bir alanla eşleşmeyen isimleri diğer bağlantılara göndermeyi durdurur. lan gibi başka bir bağlantının kendi alanına giren isimler, yerel ana bilgisayarlar için genellikle istediğiniz gibi o bağlantıya gitmeye devam eder. Bunu doğrulayın.

resolvectl status wg0

Sağlıklı bir çıktı DNS Servers: 10.8.0.1 ve DNS Domain: ~. değerlerini içerir. Eğer ~. eksikse, resolvectl domain kısmı çalışmamıştır ve wg0 diğer bağlantılarla yarışmaya devam ediyordur. Kontrol için varsayılan rota bayrağını kullanmayın: ~. olmasa bile yes (veya systemd sürümüne bağlı olarak Protocols satırında +DefaultRoute) değerini okur, çünkü yönlendirme alanı olmayan bir bağlantı zaten varsayılan rotadır.

Bahsetmeye değer bir durum daha vardır. Eğer /etc/resolv.conf, /run/systemd/resolve/stub-resolv.conf dosyasına giden bir sembolik bağlantı değil de gerçek bir dosyaysa, bu dosya genellikle NetworkManager veya bir konteyner çalışma zamanı tarafından yönetiliyordur. Başka bir hata ayıklama yapmadan önce ls -l /etc/resolv.conf komutunu çalıştırın; çünkü her ağ değişikliğinde bu dosyayı yeniden yazan bir araç, yaptığınız işi en olmadık zamanda geri alacaktır.

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

Sorgular tünel üzerinden güvenilir bir şekilde iletilmeye başlandığında, uzak uçtaki çözümleyici bir kontrol noktası haline gelir. Burada AdGuard Home çalıştırmak, bağlı olan her cihaza engel listesi filtrelemesi ve sorgu günlüğü sağlar; üstelik herhangi bir istemci yazılımı veya cihaz bazlı yapılandırma gerektirmez. Ekim 2026 itibarıyla kontrol edilen resmi kurulum betiği tek satırdır.

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

Kurulum sihirbazı ilk çalıştırıldığında 3000 numaralı portu dinler. Bu portu herkese açık hale getirmek yerine tünel üzerinden http://10.8.0.1:3000 adresinden erişin ve sihirbazda hem DNS dinleme adresini hem de yönetici dinleme adresini 10.8.0.1 olarak ayarlayın. Eğer birinci hatadan kalan unbound hala aynı adresi tutuyorsa, önce sudo systemctl disable --now unbound ile durdurun; aksi takdirde ikisi de aynı adreste 53 numaralı UDP portu için çakışacak ve AdGuard Home listen udp 10.8.0.1:53: bind: address already in use hatasıyla kapanacaktır.

İstemci yapılandırmaları zaten DNS = 10.8.0.1 adresini gösteriyorsa herhangi bir değişiklik yapılmasına gerek yoktur. Sorgu günlüğü artık her eşten gelen tüm aramaları gösterecektir; ancak bir istemciyi günlüğe kaydetmekten hariç tutarsanız bu durum ücretsiz bir kazançtan ziyade gerçek bir gizlilik kararıdır: güveni internet servis sağlayıcınızdan kendinize devredersiniz ve sunucuyu güncel tutmak sizin sorumluluğunuzdadır. İnternete açık bir sunucunun öncelikle temel güvenlik önlemlerine sahip olması gerekir ve yeni bir VPS üzerinde ilk on dakika bu konuları kapsamaktadır.

FAQ

WireGuard tunelim bağlanıyor ancak isim çözümlemesi neden çalışmıyor?

Tünel yalnızca paketleri taşır, isim çözümleme işlemleriyle ilgilenmez. Çalışan bir tünelde isim çözümleme hataları, hedeflediğiniz çözümleyicinin yanıt vermediği anlamına gelir. İstemci üzerinden dig +short @10.8.0.1 example.com ile test yapın. communication timed out yanıtı, ya o tünel adresinde dinleme yapan bir çözümleyici olmadığını (genellikle systemd-resolved stub'ının yalnızca 127.0.0.53 adresine bağlı olması nedeniyle) ya da sunucu güvenlik duvarının wg0 üzerinden gelen UDP 53 numaralı portu engellediğini gösterir. Önce dinleyiciyi düzeltin, ardından portu yalnızca wg0 için açın.

DNS trafiğimin WireGuard üzerinden sızıp sızmadığını nasıl kontrol ederim?

İstemci üzerinde sudo tcpdump -ni any -c 10 port 53 komutunu çalıştırın ve internette gezinirken arayüz sütununu izleyin. Makineden çıkan her paket wg0 üzerinde olmalıdır; 127.0.0.53 adresine giden veya oradan gelen lo üzerindeki paketler yerel systemd-resolved stub'ına aittir ve normaldir. Eğer paketler kablosuz veya ethernet arayüzünüzde görünüyorsa, sorgular açık metin olarak dışarı çıkıyor demektir. dig +short whoami.akamai.net ikinci bir doğrulama sağlar; çünkü sorguyu yapan yinelemeli çözümleyicinin genel adresini yanıt olarak döndürür. Sunucunuzun adresi olmayan bir yanıt, sızıntıyı doğrular.

Split tunnel kullanıyorsam DNS = satırına ihtiyacım var mı?

Evet, ayrıca çözümleyici adresi de AllowedIPs içinde yer almalıdır, aksi takdirde istemcinin ona ulaşacak bir rotası olmaz. AllowedIPs = 10.8.0.0/24 ile 10.8.0.1 adresindeki bir çözümleyici kapsanır ve sorgu şifrelenir. 9.9.9.9 gibi genel bir çözümleyici kapsanmadığı için, DNS satırı doğru görünse bile sorgu yerel bağlantı üzerinden dışarı çıkar.

resolvectl doğru sunucuyu göstermesine rağmen sorgular neden başka yere gidiyor?

systemd-resolved, herhangi bir yönlendirme alanıyla eşleşmeyen isimleri aynı anda tüm varsayılan rota bağlantılarına (wg0 dahil) gönderir ve genellikle yerel yönlendiriciden gelen ilk başarılı yanıtı döndürür. İstemci [Interface] bloğuna PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. ekleyin ve DNS = satırını kaldırın. resolvectl status wg0 bu durumda DNS Domain: ~. bildirmeli ve başka hiçbir bağlantının daha spesifik bir alan adıyla talep etmediği her isim yalnızca wg0 adresine gitmelidir.

Birden fazla istemci bozuksa hangisini önce düzeltmeliyim?

Bir Linux istemcisini düzeltin; çünkü mekanizmayı size gösteren tek platform budur. resolvectl status ve tcpdump size hangi çözümleyicinin yanıt verdiğini ve paketi hangi arayüzün taşıdığını söyler. Telefon ve masaüstü uygulamaları aynı DNS ve AllowedIPs değerlerini görünür bir altyapı olmadan uygular; bu nedenle Linux istemcisini düzelttiğinizde, zaten doğrulanmış bir yapılandırmayı kopyalamış olursunuz.