VPN Açıkken DNS ve WebRTC Sızıntısı Nasıl Test Edilir?

VPN uygulamasında “bağlandı” yazması ile tarayıcıdaki bütün ağ yollarının tünelden geçmesi aynı şey değil. Tek bir IP kontrol sayfasının yeşil sonuç vermesi de DNS sorgularının, IPv6 trafiğinin ve WebRTC bağlantı adaylarının beklenen yolu kullandığını kanıtlamaz.

Sağlıklı test, VPN kapalıyken alınan başlangıç kaydını VPN açıkken aynı koşullarla karşılaştırır. Sonuçları yorumlamadan önce de kullandığınız hizmetin tam tünel mi, split tunnel mı ve hangi DNS politikasını vaat ettiğini bilmek gerekir.

---

Önce beklenen sonucu bir satırda yazın​

Tam tünel kullanıyorsanız genel beklenti; web isteğinde VPN çıkış IP'sinin, DNS tarafında sağlayıcının tarif ettiği çözümleyicinin ve desteklenen IPv4/IPv6 yollarında tünel davranışının görülmesidir. Split tunnel ayarında belirli uygulamaların veya adreslerin doğrudan çıkması bilinçli olabilir; test sonucu buna göre okunmalıdır.

• VPN modu: Tam tünel, split tunnel veya yalnız tarayıcı eklentisi mi?
• DNS vaadi: VPN'in kendi resolver'ı, sistem DNS'i veya seçili bir DoH sağlayıcısı mı?
• IP kapsamı: IPv4 ve IPv6 birlikte mi destekleniyor; IPv6 desteklenmiyorsa engelleniyor mu?
• WebRTC beklentisi: Doğrudan adaylar mı, yalnız VPN yolu mu, yoksa TURN relay mi kullanılacak?

Kurumsal VPN'de iç ağ alan adlarının kurum DNS'ine gitmesi tasarım gereği olabilir. Gizlilik VPN'inde evdeki ISP resolver'ını görmek ise beklenmeyen bir yolun işareti olabilir. Aynı sonuç her senaryoda aynı hükmü vermez.

Karşılaştırmayı dört ayrı sütunda yapın​

Önce hassas sekmeleri kapatın. VPN kapalıyken genel IPv4, varsa IPv6, DNS resolver kuruluşu ve WebRTC aday türlerini not edin. Ardından VPN'e bağlanıp aynı tarayıcı profiliyle aynı testleri tekrarlayın. IP adreslerini açık foruma veya destek ekran görüntüsüne koymayın; karşılaştırma için “ISP” ve “VPN çıkışı” gibi maskeli etiketler yeterlidir.

1. Web isteğinin gördüğü IPv4 ve IPv6 adreslerini ayrı kaydedin.
2. DNS testinde görünen recursive resolver kuruluşlarını kaydedin.
3. WebRTC testinde host, srflx ve relay adaylarını ayrı okuyun.
4. Wi-Fi ve mobil bağlantıda, aynı VPN sunucusuyla sonucu tekrar edin.

Mümkünse iki bağımsız test hizmeti kullanın ve bu sayfaların gizlilik politikasını okuyun. Test sayfasının kendi görebildiği veri kadar rapor ürettiğini unutmayın; tek site bütün cihaz trafiğinizi gözlemleyemez.

DNS sonucu tam olarak neyi kanıtlar?​

DNS leak testi genellikle size özel alan adları çözdürtür ve yetkili sunucuya hangi recursive resolver'ın ulaştığını gösterir. VPN açıkken eski ISP resolver'ı görülüyorsa ve hizmet kendi DNS yolunu vaat ediyorsa araştırılacak gerçek bir fark vardır. Fakat listede tanınmış genel bir resolver bulunması, sorgunun tünele girmeden gittiğini tek başına kanıtlamaz.

IETF RFC 8484, DoH sorgu-cevap çiftinin HTTPS alışverişine eşlendiğini tanımlar. Tarayıcı kendi DoH istemcisini kullanıyorsa sistem DNS'inden farklı bir resolver seçebilir. Mozilla'nın güncel DoH ayarları da Firefox'ta varsayılan korumanın VPN, kurumsal politika veya ağ sinyallerine göre DoH'yi kapatabildiğini; daha yüksek koruma modlarının seçili sağlayıcıyı sürekli kullanabildiğini gösteriyor.

Bu nedenle tarayıcı DNS testi, başka uygulamaların ve işletim sisteminin bütün DNS trafiği hakkında hüküm vermez. Daha güçlü kanıt için kontrollü paket yakalama veya yönetilen resolver kaydı gerekir; bu işlemler yetkili olduğunuz cihaz ve ağlarda yapılmalıdır.

WebRTC adayını IP listesi sanmayın​

WebRTC bağlantı kurarken ICE adayları toplar. W3C WebRTC standardı, adaylarda IPv4, IPv6 veya alan adı bulunabileceğini ve bu bilgilerin yerel ağ topolojisi hakkında beklenenden fazlasını açığa çıkarabileceğini belirtiyor.

• host: Yerel arayüz adayıdır. Modern tarayıcı bunu mDNS adıyla maskeleyebilir; .local görmek genel ISP adresinin sızdığı anlamına gelmez.
• srflx: STUN aracılığıyla öğrenilen server-reflexive adaydır. Tam tünel beklentisinde görünen genel adres VPN çıkışıyla karşılaştırılmalıdır.
• relay: TURN sunucusunun aktarma adayıdır; kullanıcının doğrudan genel IP'si değildir.

Bir adayın listede görünmesi, seçildiği veya medya taşıdığı anlamına gelmez. Adayla açığa çıkan adresi ve gerçekten seçilen candidate pair’i ayrı yorumlayın.

IETF RFC 8828, split-tunnel VPN'de hem VPN'in hem ISP'nin genel adresinin keşfedilebildiğini; proxy arkasında doğrudan internet yolu açıksa STUN'ın proxy'yi aşarak istemcinin genel adresini açığa çıkarabildiğini açıklıyor. Buna karşılık hiç srflx adayı görmemek de “sızıntı kesinlikle yok” kanıtı değildir; tarayıcı gizlilik politikası, test sayfasının STUN yapılandırması veya ağ engeli aday toplamını sınırlayabilir.

IPv4 ve IPv6'yı ayrı sınayın​

VPN'in IPv4'ü tünele alıp IPv6'yı doğrudan bırakması mümkündür. VPN öncesi IPv6 varken bağlantı sonrası ISP IPv6 adresi görülüyorsa full-tunnel beklentisiyle çelişir. VPN sonrası IPv6'nın hiç olmaması ise sızıntı değil, sağlayıcının IPv6'yı engelleme tercihi olabilir; yine de hizmet vaadiyle karşılaştırılmalıdır.

Sorun varsa kill switch, split-tunnel listesi, VPN DNS ayarı, tarayıcı DoH modu ve istemci sürümünü tek tek kontrol edin. WebRTC'yi gelişigüzel tümden kapatmak görüşme uygulamalarını bozabilir; önce tarayıcının ve VPN sağlayıcısının resmî gizlilik ayarlarını kullanın.

VPN'in temel sınırları için VPN nedir rehberine, daha geniş gizlilik katmanları için VPN ve gizlilik kontrol listesine, iki IP ailesini teknik olarak ayırmak için IPv4/IPv6 teşhis akışına bakabilirsiniz.

Bu rehber için belirli bir VPN markasında sızıntı ölçümü yapılmadı; verilenler sonuç okuma çerçevesidir. Siz test ederken fark hangi sütunda çıkıyor: IPv4, IPv6, DNS resolver mı, WebRTC adayı mı? Gerçek adresi değil yalnızca türü paylaşın.

Güncelleme: 16 Ağustos 2026. Tarayıcıların DoH ve WebRTC gizlilik davranışı sürümle değişebileceği için testi hedef tarayıcı ve VPN sürümünde yenileyin.

---