VPN Sızıntıları Açıklandı: DNS, WebRTC ve IPv6 Sızıntıları (ve Bunları Gerçekten Nasıl Test Edersiniz)

VPN uygulamanız Bağlandı diyor. Bu tek kelime bir garanti gibi hissettirir, ama yalnızca cihazınızın VPN sunucusuyla şifreli bir tünel kurduğu anlamına gelir. Kimliğinizi açık eden trafiğin her parçasının gerçekten bu tüneli kullanıp kullanmadığı hakkında hiçbir şey söylemez. Üç yaygın arıza biçimi — DNS sızıntıları, WebRTC sızıntıları ve IPv6 sızıntıları — uygulama orada güven veren yeşil tikini gösterirken her biri gerçek IP adresinizi ya da gezinme etkinliğinizi ifşa edebilir.

Bu rehber, tek bir sızıntıya odaklanan ve sonunda 'şu VPN'i al' diyen sayfaların asla yapmadığı üç şeyi yapar. Birincisi, her sızıntının ardındaki gerçek mekanizmayı açıklar; böylece bağlı bir VPN'in sizi neden hâlâ ele verebileceğini anlarsınız. İkincisi, bir satıcıya güvenmek zorunda olmadığınız ücretsiz ve bağımsız araçlarla nasıl kendi kendinize test yapacağınızı adım adım gösterir. Üçüncüsü, işletim sistemi, tarayıcı ve modem bazında tam çözümleri verir — ve düzeltmenin gerçekten tuttuğunu doğrulayan yeniden-test disiplinini öğretir. Marka övgüsü yok, satış ortağı linki yok; sadece mekanik.

Bir VPN sızıntısı aslında nedir

Sızıntı, şifreli tünelin içinden geçmesi gerekirken bunun yerine normal internet bağlantınız üzerinden dışarı çıkan ve VPN'in gizlemesi gereken bilgiyi açığa veren her türlü trafiktir. Bu rehberdeki üç sızıntı iki farklı şeyi ifşa eder. Bir DNS sızıntısı, baktığınız web sitelerini İSS'nize (ya da kazara kullandığınız çözücüyü kim işletiyorsa ona) açık eder. Bir WebRTC sızıntısı ve bir IPv6 sızıntısı ise gerçek IP adresinizi — yani çevrimiçi gerçek konumunuzu ve kimliğinizi — ziyaret ettiğiniz web sitelerine doğrudan açık edebilir.

Baştan anlaşılması gereken en önemli şey şu: bunlar ayrı nedenleri ve ayrı çözümleri olan ayrı sorunlardır. Rakipler bunu gizler çünkü tek-tıkla satış anlatısı için elverişsizdir, ama işin tamamı budur. Bir DNS sızıntısını tıkayıp hâlâ WebRTC üzerinden IP'nizi sızdırabilirsiniz. Tarayıcınızda WebRTC'yi sıkılaştırıp hâlâ IPv6 üzerinden sızdırabilirsiniz. Birini kapatmak diğer ikisi hakkında size hiçbir şey söylemez. İşte bu yüzden gerçek bir sızıntı testi her seferinde üçünü birden kontrol eder.

Her sızıntı nasıl olur (mekanizma)

DNS sızıntıları: tünelden kaçan sorgular

Cihazınız example.com adresini yüklemeden önce, bir DNS çözücüden bu adı bir IP adresine çevirmesini ister. VPN doğru yapılandırıldığında, bu DNS sorgusu tünelin içinden VPN'in denetlediği bir çözücüye gider. Bir DNS sızıntısı, sorgunun bunun yerine açık bağlantı üzerinden İSS'nizin çözücüsüne (ya da modeminizin dayattığı bir çözücüye) gitmesiyle olur. Sayfa içeriği hâlâ tünelden akıyor olsa bile, sorgunun kendisi ziyaret ettiğiniz her alan adını üçüncü bir tarafa açık eder — ve bunu gerçek IP'nize bağlar.

Her zamanki suçlular şunlardır: VPN'in DNS ayarlarını yok sayan bir işletim sistemi, tüneli atlayan, sabit kodlanmış bir çözücü (örneğin elle ayarlanmış bir 8.8.8.8 ya da 1.1.1.1) veya DNS'i VPN dışına yönlendiren bölünmüş-tünel kuralları. Özellikle Windows'ta, akıllı çok-yuvalı ad çözümleme (smart multi-homed name resolution) adlı bir özellik, DNS sorgularını her ağ arayüzünden aynı anda fırlatıp ilk yanıtı vereni — ki bu çoğu zaman İSS'nizinkidir — kullanabilir.

WebRTC sızıntıları: IP'nizi dağıtan tarayıcı

WebRTC (Web Real-Time Communication), sayfa içi görüntülü aramaların, sesli sohbetin ve uçtan uca dosya aktarımının ardındaki tarayıcı teknolojisidir. İki ucu doğrudan bağlamak için WebRTC'nin cihazın kendi IP adreslerini keşfetmesi gerekir. Bunu, tarayıcıya gördükleri genel IP'yi yanıt veren STUN sunucularıyla yapar ve ayrıca yerel ağ adreslerini de sıralar. Bir web sayfası bu ICE adaylarını (ICE candidates) bir JavaScript API'si üzerinden okuyabilir — herhangi bir izin istemi olmadan ve siz hiçbir şeye tıklamadan.

İşte WebRTC'yi çalışan bir VPN'le bile tehlikeli kılan yakalama noktası: bu keşif, tarayıcınızın normal sayfa yüklemeleri için kullandığı proxy yolunun dışında gerçekleşebilir. Sayfa, sonunda işletim sisteminizin gerçek saydığı genel IP'yi görebilir; ki bu, VPN'inkinin değil sizin gerçek adresiniz olabilir. Bir WebRTC sızıntısı bir tarayıcı sorunudur. VPN'inizin DNS ayarları ya da kill switch'i tarafından düzeltilmez; tam da bu yüzden DNS sızıntısını düzelten insanlar IP'lerinin hâlâ göründüğünü görünce şoke olur.

IPv6 sızıntıları: tünelin asla döşemediği bir yoldaki trafik

Birçok VPN tüneli yalnızca IPv4 trafiği taşır. İSS'niz ve ev ağınız da IPv6 bağlantısı sağlıyorsa — ki bu giderek varsayılan hâle geliyor — o zaman IPv6 destekli bir hedefe yapılan her istek, yalnızca IPv4 taşıyan tünelin tamamen dışında, yerel IPv6 bağlantınız üzerinden gidebilir. Web sitesi gerçek IPv6 adresinizi görür. VPN bu trafiğe hiç dokunmamıştır ve çoğu zaman onu fark bile etmemiştir, çünkü yalnızca IPv4 tarafını izliyordu.

Bir IPv6 sızıntısının bu kadar sessizce yaygın olmasının nedeni budur: hiçbir şey bozulmaz, hiçbir şey yanlış görünmez ve VPN başarı bildirir. Çözüm ya cihazda veya ağda IPv6'yı devre dışı bırakmak, ya da IPv6'yı açıkça tünelleyen veya bağlıyken engelleyen bir VPN kullanmaktır. Sağlayıcınızın bunu sessizce halledeceğini ummak bir strateji değildir — bunu test edersiniz.

Testi yapın: ücretsiz araçlar ve sonuçları nasıl okunur

VPN sağlayıcınızın size gösterdiği 'IP'niz gizli' sayfası yerine bağımsız, üçüncü taraf araçları kullanın — bir satıcının başarı bildirmek için her türlü çıkarı vardır. Her testi VPN bağlıyken, gerçekten kullandığınız aynı tarayıcıda ve aynı cihazda yapın. Referans noktası olarak, önce bir kez VPN kapalıyken çalıştırmaya değer; böylece gerçek IP'nizin ve İSS'nizin nasıl göründüğünü bilirsiniz; ardından VPN'i açın ve bu değerlerin kaybolduğunu doğrulayın.

Adım 1 — DNS sızıntı testi

dnsleaktest.com adresini açın ve Extended test'i (Genişletilmiş test) çalıştırın. Bir dizi benzersiz ana bilgisayar adı yükler ve bunları hangi DNS sunucularının çözdüğünü bildirir. Temiz bir sonuç, VPN sağlayıcınıza ait çözücüleri (ya da VPN'in kullandığı bir gizlilik çözücüsünü) gösterir ve önemlisi, başka bir yerdeki sunucuya bağlandıysanız İSS'nizin adını veya kendi ülkenizi listelemez. Sızdıran bir sonuç ise İSS'nizin çözücüsünü veya beklemediğiniz gerçek konumunuzdaki sunucuları gösterir. ipleak.net aynı DNS bilgisini IP'nizin yanında gösterir, ki bu çapraz doğrulama için kullanışlıdır.

Adım 2 — WebRTC sızıntı testi

browserleaks.com/webrtc adresini açın. WebRTC aracılığıyla keşfettiği Public IP Address (Genel IP Adresi) kısmına bakın. Temiz bir sonuç ya hiç genel IP göstermez ya da yalnızca VPN sunucusunun IP'sini gösterir. Sızdıran bir sonuç, sayfa başlığı (ki normal bir HTTP isteği kullanır) VPN IP'sini gösterse bile WebRTC bölümünde gerçek genel IP'nizi gösterir — bu uyumsuzluk klasik WebRTC sızıntısı imzasıdır. 10.x, 172.16–31.x, 192.168.x aralıklarındaki ya da .local mDNS aralıklarındaki yerel adresler genellikle zararsızdır; asıl tehlike gerçek genel IP'nizin görünmesidir.

Adım 3 — IPv6 ve genel IP testi

ipleak.net adresini açın. IPv4 adresinizi, varsa IPv6 adresinizi ve DNS sunucularınızı tek bir sayfada gösterir. Temiz bir sonuç yalnızca VPN'in IP'sini (seçtiğiniz ülkeyle eşleşen) ve ya hiç IPv6 adresi göstermez ya da yine VPN'e ait bir IPv6 gösterir. Sızdıran bir sonuç ise İSS'nizden bir IPv6 adresi, veya iki farklı konuma işaret eden bir IPv4/IPv6 çifti gösterir. Bir VPN IPv4'ünün yanında gerçek bir IPv6 görüyorsanız, bu ders kitabı niteliğinde bir IPv6 sızıntısıdır.

IPv4'ünüzü gizleyip IPv6'nızı açık eden bir VPN sizi yarı yarıya korumamıştır — IPv6 farkındalığı olan herhangi bir siteye göre, hiç VPN kullanmıyorsunuz demektir.

İşletim sistemi, tarayıcı ve modem bazında tam çözümler

DNS sızıntılarını düzeltin

• VPN uygulamasında: 'Yalnızca VPN DNS kullan', 'DNS sızıntı koruması' ya da 'VPN dışı DNS'i engelle' gibi her seçeneği etkinleştirin. Birçok uygulamada bu varsayılan olarak açıktır, ama üçüncü taraf OpenVPN/WireGuard yapılandırmalarında çoğu zaman açık değildir.

• Windows: DNS'i arayüzlere dağıtan akıllı çok-yuvalı ad çözümlemeyi devre dışı bırakın. Windows Pro'da Grup İlkesi'ndeki 'Akıllı çok-yuvalı ad çözümlemeyi kapat' ayarını Etkin yapabilirsiniz; aksi takdirde DNS'i ayarlayan ve diğer çözücüleri engelleyen bir VPN istemcisini tercih edin. Test ederken adaptörlerinizden elle yapılandırılmış her genel DNS'i (8.8.8.8, 1.1.1.1) kaldırın.

• macOS / Linux: ağ ayarlarında veya /etc/resolv.conf içinde tüneli atlayan, sabit kodlanmış bir çözücü olmadığından emin olun; DNS'i VPN istemcisinin yönetmesine izin verin. systemd-resolved kullanan Linux'ta, VPN'in bir alan adı rotası ayarladığını doğrulayın; böylece sorgular onun çözücüsüne gider.

• Modem: VPN'i modemde çalıştırıyorsanız, modemin DNS'ini VPN'in çözücüsüne ayarlayın ve İSS tarafından atanan her DNS'i devre dışı bırakın. Ayrıca DNS'i araya girip yönlendiren modem özelliklerini de devre dışı bırakın (bazı 'ebeveyn denetimi' veya 'DNS rebind koruması' ayarları).

WebRTC sızıntılarını düzeltin (yalnızca tarayıcı)

• Firefox: adres çubuğuna about:config yazın, uyarıyı kabul edin, media.peerconnection.enabled araması yapın ve değerini false yapın. Bu, WebRTC'yi tamamen devre dışı bırakır. Aramalar için WebRTC'ye ihtiyacınız varsa açık bırakın ama keşfedilen IP'yi maskeleyen bir VPN/eklentiye dayanın ve yeniden test edin.

• Chrome / Edge: WebRTC'yi tamamen devre dışı bırakacak yerleşik bir anahtar yoktur. Şunu bilin: uBlock Origin'in eski 'WebRTC'nin yerel IP adreslerini sızdırmasını önle' seçeneği 2021'de masaüstü eklentisinden kaldırıldı ve var olduğunda bile yalnızca yerel/LAN adreslerini maskeliyordu — sizi gerçekten açık eden genel-IP ifşasını asla durdurmadı, yani insanların sandığı çözüm hiçbir zaman olmadı. Modern Chromium, mDNS kullanarak yerel IP'leri zaten gizliyor ( chrome://flags adresinde 'Anonymize local IPs exposed by WebRTC' bayrağıyla doğrulayabilirsiniz). Genel IP ifşasını denetlemek için özel bir WebRTC-denetim eklentisi kullanın ve ardından bir sızıntı testiyle doğrulayın, çünkü eklentilerin bunu ne kadar tam engellediği değişir.

• Safari: WebRTC ifşası varsayılan olarak daha sınırlıdır, ama yine de test edin. İhtiyacınız yoksa Geliştir (Develop) menüsündeki deneysel/WebRTC özellikleri üzerinden devre dışı bırakabilirsiniz.

• Gerçeklik kontrolü: WebRTC'yi devre dışı bırakmak Google Meet'i, tarayıcıdaki Discord'u, Jitsi'yi ve benzeri araçları bozabilir. Bunlara ihtiyacınız varsa, pratik yol WebRTC'yi tamamen öldürmek yerine yalnızca VPN IP'sini veren bir tarayıcı/eklentidir — yeniden test ederek doğrulanır.

IPv6 sızıntılarını düzeltin

• En iyi seçenek: açıkça IPv6 sızıntı koruması sunan bir VPN kullanın (bağlıyken IPv6'yı engeller ya da tüneller). Bu ayarı açın ve yeniden test edin.

• Windows: etkin adaptörde IPv6'yı devre dışı bırakın (Ağ adaptörü Özellikleri, Internet Protocol Version 6 işaretini kaldırın), ya da VPN'in IPv6 engellemesini kullanın. IPv6'yı kaldıramayan bir VPN'i kullanmayı bıraktığınızda yeniden etkinleştirin.

• macOS: VPN'iniz IPv6'yı tünelleyemiyorsa, Sistem Ayarları'nda ağ hizmetinin Configure IPv6 seçeneğini Link-local only (ya da komut satırından Off) olarak ayarlayın.

• Linux: tünel yalnızca IPv4 ise, IPv6'yı arayüz bazında veya sistem genelinde sysctl ile devre dışı bırakın (örneğin net.ipv6.conf.all.disable_ipv6=1).

• Modem: VPN'i modemde çalıştırıyorsanız, modemin IPv6/WAN IPv6'sını devre dışı bırakın; böylece ağdaki hiçbir cihaz onun üzerinden sızdıramaz. Bu, tüm bir hane için en temiz çözümdür.

'Bağlı' bir VPN neden hâlâ sızdırır

Üç testi de bir kez geçtikten sonra bile koruma kalıcı değildir — sessizce bozulabilen bir durumdur. 'Bağlı' bir VPN'in sessizce sızdırmaya başladığı anlar şunlardır:

• Ağ değişiklikleri: Wi-Fi'den Ethernet'e geçmek, erişim noktası değiştirmek ya da telefonunuzun Wi-Fi ile hücresel arasında geçiş yapması, VPN kurallarını yeniden kurmadan önce trafiği bir an için tünelin dışına yönlendirebilir.

• Uyku ve uyanma: bir dizüstü bilgisayar uykudan uyandığında, ağ çoğu zaman VPN yeniden bağlanmadan önce geri gelir. Birkaç saniyeliğine trafik çıplak bağlantıyı kullanır — arka plan uygulamalarının gerçek IP'nizle eve telefon etmesine yetecek kadar uzun.

• Yeniden bağlanmalar ve kopmalar: tünel her koptuğunda ve yeniden bağlandığında, bir kill switch engellemediği sürece trafiğin kaçabileceği bir pencere vardır.

• Captive portal'lar: otel, havalimanı ve kafe Wi-Fi'leri, internet çalışmadan önce bir giriş sayfası yüklemenizi gerektirir. O sayfa tasarım gereği VPN'in dışında yüklenir ve bazı kurulumlar siz sonradan elle yeniden bağlanana kadar sızdırmaya devam eder.

• Bölünmüş tünelleme (split tunneling): belirli uygulamaları — ya da DNS'i — VPN'den hariç tuttuysanız, bu istisnalar yapılandırma gereği sızıntıdır. DNS'in sessizce 'baypas' listesinde olmadığını iki kez kontrol edin.

• IPv6'nın geri gelmesi: bir işletim sistemi güncellemesi ya da ağ sıfırlaması, daha önce devre dışı bıraktığınız IPv6'yı sessizce yeniden etkinleştirip o yolu uyarmadan yeniden açabilir.

Kill switch'ler ve sızıntı koruma ayarları — ve nasıl sessizce başarısız olurlar

Bir kill switch, kopma-ve-yeniden-bağlanma sorunu için bir güvenlik ağıdır: tünel düştüğünde, VPN geri gelene kadar tüm internet trafiğini engeller; böylece bu aralıkta hiçbir şey kaçmaz. Yerleşik sızıntı koruması (DNS sızıntı koruması, IPv6 engelleme, ağ-kilidi özellikleri), DNS ve IPv6'nın yalnızca tüneli kullanmasını zorunlu kılar. İkisini de açın — elle izleyemediğiniz arıza pencerelerini onlar yönetir.

Ama sessiz arıza biçimlerini anlayın. Bir kill switch yalnızca uygulama tünelin düştüğünü algıladığında devreye girer; tünel teknik olarak ayaktayken DNS ya da IPv6 onun etrafından sızıyorsa, kill switch hiçbir sorun görmez ve hiçbir şey yapmaz. Uygulama düzeyindeki kill switch'ler yalnızca VPN uygulamasının kendi trafiğini korur, tüm sistemi değil. Bazı kill switch'ler uyku/uyanma penceresinde ya da açılışta oturum açmadan önce devreye girmez. Ve kapalıyken trafiği tamamen engelleyen 'güvenlik duvarı tarzı' bir kill switch, bir internet kesintisiyle karıştırılıp insanları onu devre dışı bırakmaya itebilir. Çıkarılacak ders: bir kill switch riski azaltır, testin yerini almaz. Ayarlarınızın işe yaradığının tek kanıtı geçilen bir testtir.

Zararsız sonuç vs. gerçek gizlilik açığı

Bir sızıntı testi sayfasındaki her tanıdık olmayan kayıt felaket değildir. Farkı bilmek, hayalet kovalamanızı — ya da gerçek bir açığı görmezden gelmenizi — önler.

• Zararsız: WebRTC'nin yalnızca yerel/özel adresleri (10.x, 172.16–31.x, 192.168.x) ya da bir mDNS .local ana bilgisayar adını göstermesi. Bunlar sizi bir web sitesine karşı tanımlamaz.

• Zararsız: VPN sağlayıcınıza ait ya da onun kullandığı bir gizlilik çözücüsüne ait DNS çözücüleri, VPN sunucunuzdan farklı bir şehirde olsalar bile — sağlayıcılar çözücü filoları işletir.

• Zararsız: IPv6'yı devre dışı bıraktığınızda hiç IPv6 adresi olmaması. Bu bir hata değil, hedeftir.

• Gerçek açık: kasıtlı olarak başka bir yere bağlandığınızda gerçek genel IP'nizi (IPv4 ya da IPv6), gerçek şehrinizi/İSS'nizi ya da kendi ülkenizi gösteren herhangi bir test.

• Gerçek açık: gerçek İSS'nizin adını veren DNS sonuçları, ya da iki farklı konuma çözülen bir IPv4 ve IPv6.

• Gerçek açık: sayfa başlığı VPN IP'sini gösterirken WebRTC bölümünün gerçek IP'nizi göstermesi — bu uyumsuzluğun kendisi sızıntıdır.

Pratik kural: olmaması gereken bir yerde genel bir IP'nin ya da İSS'nizin adının görünmesi gerçek bir açıktır. Özel/yerel adresler ve sağlayıcıya ait çözücüler gürültüdür.

Yeniden-test disiplini: sizi gerçekten koruyan alışkanlık

Bir sızıntı testi bir anlık görüntüdür, bir sertifika değil. Koruyucu durum ağ değişikliklerinde, uyku hâllerinde, yeniden bağlanmalarda ve captive portal'larda bozulduğu için, test yalnızca test ettiğiniz koşullar için anlamlıdır. Şu alışkanlığı edinin:

1. Her düzeltmeden sonra yeniden test edin — bir ayarı değiştirin, sonra devam etmeden önce o belirli sızıntının kapandığını doğrulayın. Üçünü birden düzeltip bir kez test etmek hangi değişikliğin işe yaradığını gizler.

2. Her ağ değişikliğinden sonra yeniden test edin — yeni Wi-Fi, hücresele geçiş, Ethernet takmak ya da bir captive portal girişinin ardından.

3. Uykudan uyandıktan ve bir VPN yeniden bağlanmasından sonra yeniden test edin, çünkü bunlar en yüksek riskli pencerelerdir.

4. İşletim sistemi ve uygulama güncellemelerinden sonra yeniden test edin; bunlar sessizce IPv6'yı yeniden etkinleştirebilir ya da DNS davranışını sıfırlayabilir.

5. Her seferinde üç testi birlikte çalıştırın — DNS, WebRTC ve IPv6 bağımsızdır ve birinde temiz bir sonuç diğerleri hakkında size hiçbir şey söylemez.

Pratik çıkarım

'Bağlı' bir başlangıç noktasıdır, gizliliğin kanıtı değil. Üç sızıntıyı da bağımsız araçlarla test edin — DNS için dnsleaktest.com, WebRTC için browserleaks.com/webrtc ve IPv6 ile genel IP'niz için ipleak.net. Bunlara ayrı sorunlar olarak yaklaşın: VPN DNS'ini işletim sistemi ya da modem düzeyinde zorunlu kılın, WebRTC'yi tarayıcıda etkisiz hâle getirin ve IPv6'yı engelleyin ya da tünelleyin. İzleyemediğiniz boşluklar için kill switch'inizi ve yerleşik sızıntı korumanızı açın, ama onlara asla körü körüne güvenmeyin. Sonra her düzeltmeden ve her ağ değişikliğinden sonra yeniden test edin. On dakikalık test, gerçek açığınız hakkında herhangi bir sağlayıcının pazarlama sayfasının söyleyebileceğinden çok daha fazlasını söyler.

Sıkça Sorulan Sorular

VPN sızıntı testi nedir ve nasıl yaparım?

Bir VPN sızıntı testi, VPN bağlıyken herhangi bir trafiğin şifreli tünelinizden kaçıp gerçek IP adresinizi ya da DNS sorgularınızı açık edip etmediğini kontrol eder. Yapmak için VPN'inizi bağlayın, ardından dnsleaktest.com, browserleaks.com/webrtc ve ipleak.net gibi bağımsız araçları ziyaret edin. Bunlardan herhangi biri gerçek genel IP'nizi, İSS'nizi ya da ev konumunuzu gösteriyorsa bir sızıntınız var demektir.

DNS sızıntı testi nasıl çalışır ve neye geçer denir?

Bir DNS sızıntı testi benzersiz ana bilgisayar adları yükler ve bunları hangi DNS sunucularının çözdüğünü bildirir. Çözücüler VPN sağlayıcınıza aitse ve kendi İSS'niz listelenmiyorsa geçersiniz. İSS'nizin çözücüsü görünüyorsa ya da başka bir yere bağlandığınız hâlde sunucular gerçek konumunuzdaysa kalırsınız.

Bir DNS sızıntısını nasıl düzeltirim?

Önce VPN uygulamanızda 'DNS sızıntı koruması' ya da 'yalnızca VPN DNS kullan' seçeneğini etkinleştirin. Windows'ta ayrıca akıllı çok-yuvalı ad çözümlemeyi devre dışı bırakın ve adaptörünüzden 8.8.8.8 gibi elle ayarlanmış her genel DNS'i kaldırın. VPN çalıştıran bir modemde, modemin DNS'ini VPN çözücüsüne yöneltin ve İSS tarafından atanan DNS'i devre dışı bırakın, sonra yeniden test edin.

WebRTC sızıntısı nedir ve VPN'im onu durdurur mu?

Bir WebRTC sızıntısı, VPN bağlı olsa bile tarayıcınızın gerçek zamanlı iletişim özelliğinin gerçek IP adresinizi bir web sayfasına keşfedip açık etmesidir. Çoğu VPN bunu durdurmaz çünkü bu bir ağ davranışı değil, bir tarayıcı davranışıdır. Firefox'ta about:config içinde media.peerconnection.enabled değerini false yaparak düzeltin. Chrome ve Edge'de WebRTC'yi devre dışı bırakacak yerleşik bir anahtar yoktur, bu yüzden özel bir WebRTC-denetim eklentisi kullanın ve yeniden test edin — uBlock Origin'in eski yerel-IP anahtarına güvenmeyin; o masaüstü eklentisinden kaldırıldı ve zaten hiçbir zaman genel-IP ifşasını engellemedi.

IPv6 sızıntısı nedir ve VPN'imde nasıl önlerim?

Bir IPv6 sızıntısı, yalnızca IPv4 taşıyan VPN tünelinizin IPv6 trafiğini yok sayıp onun İSS bağlantınız üzerinden gitmesine ve gerçek IPv6 adresinizi açık etmesine izin vermesiyle olur. Önlemek için VPN'inizde IPv6 sızıntı korumasını etkinleştirin ya da cihazınızda veya modeminizde IPv6'yı devre dışı bırakın. Ayarı değiştirdikten sonra ipleak.net üzerinde hiçbir İSS IPv6 adresinin görünmediğini doğrulayın.

Bir kill switch DNS ve WebRTC sızıntılarını önler mi?

Güvenilir biçimde önlemez. Bir kill switch yalnızca tünelin düştüğünü algıladığında trafiği engeller, bu yüzden tünel hâlâ ayaktayken oluşan DNS ya da WebRTC sızıntıları hakkında hiçbir şey yapmaz. Ayrı bir DNS sızıntı korumasına ve tarayıcı tarafında WebRTC sıkılaştırmasına ihtiyacınız vardır; kill switch ise yeniden bağlanmalar ve kopmalar için bir yedek olarak kalır.

Bir VPN sızıntı testini ne sıklıkla çalıştırmalıyım?

Her yapılandırma değişikliğinden sonra test edin ve her ağ değişikliği, uyku/uyanma döngüsü, VPN yeniden bağlanması, captive portal girişi ve büyük işletim sistemi veya uygulama güncellemesinden sonra yeniden test edin. Bu anların her biri bir sızıntıyı sessizce yeniden açabilir. DNS, WebRTC ve IPv6 bağımsız sorunlar olduğundan üç testi her zaman birlikte çalıştırın.