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 makinenizden tünel dışında çı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 bir 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 bunu geri yükler. Dolayısıyla aşağıdaki her sorun bir yönlendirme sorunu veya wg-quick sorunudur, asla bir kriptografi sorunu değildir. Eğer tünelin kendisi henüz kurulmadıysa, kendi VPS'inizde self-hosted WireGuard VPN kurulumu ile başlayın ve sonrasında 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 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 sorunu değil, bir yönlendirme veya NAT (ağ adresi çevirisi) sorununuz vardır ve çözümleyici yapılandırması üzerinde yapılacak hiçbir değişiklik işe yaramayacaktır. Eğer pingler yanıt veriyor ancak gerçek trafik başladığında verim düşü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 yerleştirin.

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: DNS sızıntıları, çünkü split tunnel çözümleyiciyi yönlendirmez

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, varsayılan rotayı kendi yönlendirme tablosuna kurar ve suppress_prefixlength 0 ile bir kural ekler; bu kural, makinenin yazıcısına erişebilmesi için daha spesifik yerel rotaları kasıtlı olarak canlı tutar. İstemcinin DHCP aracılığıyla öğrendiği çözümleyici, genellikle 192.168.1.1 adresindeki yönlendiricidir ve bu yerel rotalardan biriyle eşleşir. Trafiğiniz tünel üzerinden akar. Yerel ağ ise arattığınız tüm isimlerin listesini almaya 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 vakadaki gibi yerel bağlantı üzerinden çıkar.

Hangi çözümleyicinin gerçekten yanıt verdiğini kanıtlayın. whoami.akamai.net, sorguyu yapan özyinelemeli (recursive) çözümleyicinin 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, sızıntı budur. 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 her 53 numaralı port paketi wg0 üzerinde görünür; sızıntı durumunda ise bu paketler wlan0 veya enp3s0 üzerinde görünür.

Çö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 sayede sorgu şifrelenir ve sunucuya gönderilir. Split tunnel üzerinde genel bir çözümleyici kullanmakta ısrar ediyorsanız, bunu bir host route olarak ekleyin: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Paketler tünellenmiş olur, ancak yerel ağ, önceki oturumlardan o sağlayıcıyı seçtiğinizi yine de görebilir. Kendi çalıştırdığınız bir çözümleyici bu soruyu ortadan kaldırır.

Resolver ataması, elle oluşturulan WireGuard ile koordineli bir mesh arasındaki görünür farklardan biridir ve bu fark WireGuard ile Tailscale karşılaştırması içindeki ödünleşimin bir parçasıdır. Self-hosted Headscale control server çalıştırmak, anahtar materyalinizi üçüncü bir tarafa teslim etmeden bu koordinasyonu sağlar. Son ifade endişe kaynağıysa şu noktaya dikkat edilmelidir: Tailscale, trafiğinizi şifreleyen anahtarları hiçbir zaman elinde tutmaz; asıl sorulması gereken, güvenliği ihlal edilmiş bir koordinasyon sunucusunun veya ele geçirilmiş bir kimlik hesabının ağınıza ne ekleyebileceğidir.

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

macOS, Windows, iOS ve Android istemcileri DNS = ayarını resmi uygulama aracılığıyla uygular ve genellikle sorun çıkarmaz. Linux tarafında ise ayar, sisteminizde hangi çözümleyici yöneticisinin (resolver manager) ç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. systemd-resolved ile iletişim kuran uygulamayı yükleyin ve ardından arayüzü tekrar ayağa kaldırın.

sudo apt install -y openresolv
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 şekilde DNS Servers: 10.8.0.1 değerini gösterir ancak DNS sorguları hala eski çözümleyiciye gitmeye devam eder. systemd-resolved, her bağlantı için ayrı bir çözümleyici listesi tutar ve sorgu başına bir bağlantı seçer. Bir bağlantı "varsayılan rota" (default route) olarak işaretlenmediği sürece, kablosuz ağ bağlantısının çözümleyicisini kullanmaya devam eder; çünkü o bağlantı bir arama alan adına (search domain) sahiptir, sizinki ise sahip değildir.

Çözümleyiciyi ayarlayın ve aynı adımda varsayılan rotayı talep edin. %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 komutunu bu şekilde kullandığınızda DNS = satırını silin; aksi takdirde iki farklı mekanizma çözümleyici durumunu yazar ve sonrasında sadece biri temizlik yapar. ~. argümanı işin önemli kısmıdır: wg0 değerini her isim için yönlendirme alanı (routing domain) olarak işaretler, böylece systemd-resolved sorgu başına bağlantı seçmek yerine tüm sorguları oraya gönderir. Doğrulayın.

resolvectl status wg0

Sağlıklı bir çıktı DNS Servers: 10.8.0.1 ve Default Route: yes değerlerini içermelidir. Eğer Default Route çıktısı no ise, resolvectl domain kısmı çalışmamıştır ve tekrar bağlantı seçimi durumuna dönmüşsünüz demektir.

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ğ değil de gerçek bir dosyaysa, bu dosya başka bir servise, genellikle NetworkManager veya bir container çalışma zamanına aittir. 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şlemleri en beklenmedik anda 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 istemci yazılımı veya cihaz bazlı yapılandırma gerektirmeksizin engelleme listesi filtrelemesi ve sorgu günlüğü sağlar. Temmuz 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 dış dünyaya açmak yerine tünel üzerinden http://10.8.0.1:3000 adresinden erişin ve sihirbaz içerisinde 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; çünkü iki süreç aynı adres üzerinde 53 numaralı UDP portunu aynı anda dinleyemez ve ikincisi listen udp 10.8.0.1:53: bind: address already in use hatasıyla sonlanı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; bu durum ücretsiz bir kazançtan ziyade gerçek bir gizlilik kararıdır: güveni internet servis sağlayıcınızdan kendinize aktarırsınız ve sunucunun yamalarını güncel tutmak sizin sorumluluğunuzdadır. İnternete açık bir sunucuda temel güvenlik önlemleri önceden alınmalıdır; yeni bir VPS üzerinde ilk on dakika rehberi bu konuları kapsamaktadır.

FAQ

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

Tünel yalnızca paketleri taşır, isim çözümleme işlemleriyle ilgilenmez. Tünel çalışırken çözümleme başarısız oluyorsa, hedeflediğiniz çözümleyici yanıt vermiyordur. İstemci üzerinden dig +short @10.8.0.1 example.com ile test yapın. communication timed out yanıtı, tünel adresinde hiçbir çözümleyicinin dinleme yapmadığını gösterir. Bunun nedeni genellikle systemd-resolved stub'ının yalnızca 127.0.0.53 adresine bağlanması veya sunucu güvenlik duvarının wg0 üzerinden gelen UDP 53 numaralı portu engellemesidir. Önce dinleyiciyi düzeltin, ardından portu yalnızca wg0 için açın.

DNS'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. Her paket wg0 üzerinde görünmelidir. Eğer paketler kablosuz veya ethernet arayüzünüzde görünüyorsa, sorgular şifrelenmemiş olarak dışarı çıkıyordur. dig +short whoami.akamai.net ikinci bir doğrulama sağlar; çünkü sorguyu yapan yinelemeli çözümleyicinin genel IP adresini döndürür. Sunucunuzun adresi dışındaki bir yanıt, sızıntıyı doğrular.

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

Evet, çö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 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östermesine rağmen 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 bir girdi, başka bir bağlantı isimler için varsayılan rotayı tuttuğunda göz ardı edilir. İ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 Default Route: yes bildirmelidir.

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 yüzden Linux istemcisini düzelttiğinizde, zaten doğrulanmış bir yapılandırmayı kopyalamış olursunuz.