Bu test nasıl çalışır
WebRTC, eklentisiz görüntülü görüşme ve ekran paylaşımının arkasındaki tarayıcı özelliğidir. İki tarayıcı doğrudan konuşmadan önce her biri hangi adreslerden ulaşılabileceğini öğrenmelidir; bu adıma ICE aday toplama denir. Tarayıcı kendi ağ arabirimlerini listeler, sonra açık bir STUN sunucusuna internette hangi adresten geliyor göründüğünü sorar ve yanıtları aday olarak toplar. Herhangi bir web sayfasının bu süreci kısa bir betikle — kamera veya mikrofon izni gerekmeden — başlatmasına ve adayları geri okumasına izin verilir.
Bu sayfa tam olarak bunu tarayıcınızda yapar ve listeyi gösterir. Sunucunun tek rolü betiğe bağlantınızın hangi genel IP’den geldiğini söylemektir ki betik karşılaştırabilsin. Adımlar:
- Betik, açık bir STUN sunucusu yapılandırılmış bir eş bağlantı nesnesi oluşturur.
- Hiçbir medya cihazına dokunmadan aday toplamayı tetikleyen bir veri kanalı açar.
- Tarayıcının ürettiği her aday geldikçe tabloya yazılır: türü, adresi, taşıma protokolü ve portu.
- Toplama bitince her genel aday bağlantı IP’siyle karşılaştırılır. Her genel adres eşleşiyorsa durum geçti, bir genel adres farklıysa başarısız olur. Hiç genel aday görünmezse durum nedenini açıklar.
- STUN isteğinin kendisi dışında kimseye hiçbir şey gönderilmez; karşılaştırma sayfada yapılır. Anonimlik puanı sayfasında aynı sonuç, puanın WebRTC satırı güncellenebilsin diye sunucumuza da gönderilir.
Görebileceğiniz dört aday türü:
| Tür | Nedir | Nereden gelir |
|---|---|---|
| host | Cihazınızın kendi arabirimlerinden birinin adresi | İşletim sistemi; güncel tarayıcılarda .local adı olarak gösterilir |
| srflx | Sunucu yansımalı: STUN sunucusunun sizi gördüğü genel adres | STUN sunucusunun UDP üzerinden gelen yanıtı |
| prflx | Eş yansımalı: bağlantı denemesi sırasında keşfedilen adres | Bu testte nadir; eş yok |
| relay | Doğrudan bağlantı imkânsızken kullanılan aktarma sunucusundaki adres | Yalnızca TURN sunucusu yapılandırıldığında; bu test kullanmaz |
Sızdıran satır srflx’tir. UDP paketlerinizin ağınızdan çıkarken taşıdığı adrestir; proxy’niz yalnızca TCP taşıyorsa o adres gerçek adresinizdir.
Sonucunuzu nasıl okursunuz
| Tablo ne gösteriyor | Anlamı |
|---|---|
| host adayı olarak .local adı, bağlantı IP’sine eşit tek srflx adresi | Normal ve güvenli. Tüneliniz UDP taşıyor ve LAN adresiniz maskelenmiş. |
| Bağlantı IP’sinden farklı bir srflx adresi | Sızıntı. Gösterilen adrese tünelinizin dışından ulaşılabiliyor ve bir site onu okuyabilir. Anonimlik puanında 15 puana mal olur. |
| Bağlantı IP’si IPv4 iken IPv6 olan srflx adresi | Tarayıcı yalnızca IPv4 taşıyan tünelin dışında genel bir IPv6 rotası buldu. Sızıntı sayın; IPv6 testi aynı adresi gösterecektir. |
| 192.168.x.x gibi ham özel adresli host adayları | Eski bir tarayıcı veya gevşek bir ayar; LAN düzeninizi açığa çıkarır, genel adresinizi değil. Genel IP sızıntısı değildir. |
| Yalnızca host adayları, srflx yok | STUN sunucusuna UDP engelli ya da WebRTC yerel adreslerle sınırlı. Genel adres açığa çıkmıyor; bazı siteler yokluğu fark eder. |
| Hiç aday yok | WebRTC tarayıcıda veya bir eklentiyle kapalı. Hiçbir şey sızmıyor; tarayıcı WebRTC’si kapalı olarak tanınabilir. |
| relay adayı | Bir eklenti veya ilke TURN sunucusu yapılandırmış; sitelerin gördüğü onun adresidir. |
Genel adayı sayfanın üstündeki adresle karşılaştırın. Eşleşiyorsa tablodaki diğer satırlar teknik görünse de kurulumunuz bu testi geçer. Farklıysa farklı olan gerçek adresinizdir — ya da en azından gerçek ağınıza ulaşılabilen bir adres — ve bu düzeltilene kadar başka hiçbir kontrolün önemi yoktur.
Nasıl düzeltilir
Kullandığınız şeyin girdisini seçin. Sonra adayları yeniden toplamak için bu sayfadaki çalıştır düğmesine basın; yenilemek gerekmez ama zararı da yoktur.
VPN uygulamaları ve eklentileri
- VPN’in tarayıcı eklentisinde WebRTC koruma seçeneğini açın. Çoğu sağlayıcının eklentisi kurulu olduğu tarayıcıda WebRTC adaylarını engelleyebilir veya yeniden yazabilir.
- Masaüstü uygulamasında tünelin yalnızca tarayıcı proxy modu değil tam sistem VPN’i olduğundan emin olun; tam tünel UDP taşır, STUN yanıtı çıkış üzerinden gelir ve genel aday VPN’in adresi olur.
- Testi yeniden çalıştırın; srflx satırı artık bağlantı IP’sine eşit olmalıdır.
Chrome, Edge, Brave ve diğer Chromium tarayıcılar
- Brave’de yerleşik denetim vardır: Ayarlar, Gizlilik ve güvenlik, WebRTC IP işleme ilkesi. Adayları proxy’den geçirmeye ya da proxy yokken gizlemeye zorlamak için „Proxy’siz UDP’yi devre dışı bırak“ı seçin.
- Chrome ve Edge’de kullanıcıya açık anahtar yoktur. WebRTC Network Limiter eklentisini veya eşdeğerini kurup yalnızca varsayılan genel arabirimi kullanacak ya da proxy’siz UDP’yi kapatacak şekilde ayarlayın. Kurumsal ilkeler yönetilen makinelerde aynısını ayarlayabilir.
- Testi yeniden çalıştırıp bağlantı IP’si dışında genel adres görünmediğini doğrulayın.
Firefox
- Adres çubuğunda about:config açın ve uyarıyı kabul edin.
- WebRTC’nin varsayılan rota dışında adres açığa çıkarmasını durdurmak için media.peerconnection.ice.default_address_only değerini true ve media.peerconnection.ice.no_host değerini true yapın. WebRTC’yi tamamen kapatmak için media.peerconnection.enabled değerini false yapın.
- SOCKS5 proxy ile ayrıca media.peerconnection.ice.proxy_only değerini true yapın ki adaylar proxy üzerinden toplansın ya da hiç toplanmasın.
- Testi yeniden çalıştırın.
Safari
- Safari WebRTC’yi sistem ağ yığınından geçirir; sistem geneli VPN onu korur. Güncel sürümlerde aday toplama için kullanıcı anahtarı yoktur; Geliştirici menüsündeki WebRTC girdileri geliştirici seçenekleridir ve varsayılanda bırakılmalıdır.
- macOS’te sızıntı sürüyorsa çözüm VPN uygulamasındadır: tam tünel modunu ve kill switch’i açın.
Antidetect tarayıcılar
- Profilin WebRTC ayarını açın. Genel adresi proxy’nin adresiyle değiştiren veya bozan modu seçin; genellikle replace veya altered denir. Burada gösterilen adres artık proxy IP’sine eşit olmalıdır.
- Sıkı sitelere girişlerde disabled modundan kaçının; WebRTC’si hiç olmayan bir tarayıcı nadirdir ve bazı parmak izi betikleri bunu kaydeder.
- Proxy UDP desteği olmayan SOCKS5 ise eşleşen genel aday üreten tek mod replace’tir; real modu sızdırır.
Android ve iOS
- Mobil tarayıcılar WebRTC ayarlarını nadiren sunar. Tüm trafiği tünelleyen bir VPN uygulaması kullanın; genel aday VPN’in adresi olur.
- Android için Firefox bazı sürüm kanallarında masaüstüyle aynı about:config anahtarlarını destekler; mümkünse ve tarayıcıda görüşme kullanmıyorsanız media.peerconnection.enabled değerini false yapın.
- Mobilde proxy için UDP taşımayan yalnızca tarayıcı proxy ayarları yerine VPN tarzı tünel sağlayan uygulamaları tercih edin.
Yönlendiriciler ve güvenlik duvarları
- Güvenlik duvarında 3478 portuna ve yaygın STUN portlarına giden UDP’yi engellemek, arkasındaki her cihaz için srflx adaylarını kaldırır. Kaba bir araçtır; STUN’a dayanan görüşmeleri de bozar.
Bu testin sınırları
- Tek STUN sunucusu, tek an. Adaylar testi çalıştırdığınız anda tek bir açık STUN sunucusuna karşı toplanır. Kendi TURN sunucusunu veya farklı bir STUN sunucusunu kullanan bir site farklı bir relay adresi görebilir; genel srflx adresi aynı olur.
- Karşılaştırma, sunucumuzun gördüğü bağlantı IP’nize göredir. Bu sayfaya hedef sitenin kullandığından farklı bir yolla ulaştıysanız — örneğin yalnızca bazı alan adlarına uygulanan bir tarayıcı proxy’si — karşılaştırma o sitenin görünümünü yansıtmayabilir.
- IPv6 adayları yalnızca adrese göre karşılaştırılır. Bağlantınız IPv4 iken IPv6 srflx adayı tünel dışında bir rota olduğu için işaretlenir; bir sitenin onu başka verilerle birleştirip birleştirmeyeceği o siteye bağlıdır.
- Eklenti davranışı teste görünmez. Adayları yeniden yazan bir eklenti sızıntıyı tablodan kaldırır — amaç budur — ama test yeniden yazılmış adayı gerçeğinden ayıramaz. Giriş kontrolü için sorun değil; sonradan bir görüşme sorunu ayıklarken hatırlamaya değer.
- Medya cihazlarına dokunulmaz. Test adayları yalnızca veri kanalıyla toplar; kamera veya mikrofon listelemez; bunu yapan bir site cihazınız hakkında bu sayfanın gösterdiğinden fazlasını öğrenebilir.
- .local adları sayfa tarafından çözümlenemez ve tarayıcının bildirdiği gibi gösterilir. Bir site de onları LAN adresinize çeviremez.
WebRTC neden proxy arkasında sızar ama VPN arkasında daha seyrek
Tarayıcıda ayarlanan proxy, tarayıcının TCP üzerinden giden web isteklerini taşır. WebRTC’nin adres keşfi STUN sunucusuyla bir UDP alışverişidir ve tarayıcılar UDP’yi HTTP proxy’den göndermez; SOCKS5 ilke olarak UDP taşıyabilir ama tarayıcı desteği sınırlıdır ve varsayılan olarak kapalıdır. Dolayısıyla STUN isteği gerçek bağlantınızdan çıkar ve yanıt gerçek genel adresinizi söyler. VPN tarayıcının altında, ağ arabiriminde çalışır ve UDP dahil her paketi taşır; STUN yanıtı çıkış üzerinden döner ve genel aday VPN’in adresi olur. VPN’in bu testi varsayılan olarak geçip proxy’nin geçememesinin tek nedeni budur; antidetect tarayıcıların replace modu eklemesinin nedeni de: tam tünelin üreteceği sonucu taklit eder.
Yerel adresler ve mDNS
Eski tarayıcılar cihazınızın 192.168.1.20 gibi özel adresini host adayı olarak bildirirdi; siteler ev ağınızın parmak izini çıkarıp cihaz sayabilirdi. Güncel tarayıcılar onu mDNS’ten ödünç alınan bir teknikle .local altında rastgele bir adla değiştirir ve o adı yalnızca aynı ağdaki gerçek bir eş için çözümler. host satırında ham özel adres görüyorsanız tarayıcı eskidir ya da bir ayar maskelemeyi kapatmıştır. Bu sayfanın konusu olan genel IP sızıntısı değildir; ama dikkatli bir ziyaretçinin vermek istemeyeceği fazladan bir bilgidir.
WebRTC testini geçmek VPN’imin güvenli olduğu anlamına mı gelir?
WebRTC’nin adresinizi sızdıran kanal olmadığı anlamına gelir. İki başka kanal ayrı test edilir: DNS sızıntı testinin kapsadığı ad sorguları ve IPv6 testinin kapsadığı IPv6 yönlendirmesi. IP sızıntı testi üçünü IPv4 kontrolüyle birlikte çalıştırır; anonimlik puanı onları ağ ve tarayıcı tutarlılık kontrolleriyle birleştirir. WebRTC sızıntısı proxy’li kurulumlarda üçünün en yaygını ve doğrulanması en kolayıdır; bu yüzden ilk çalıştırılacak olandır, tek çalıştırılacak olan değil.