LEAK GUIDE

Sızıntı tespiti · Teknik notlar

Sızıntı testi web çıkışını, WebRTC'yi, DNS'i, IPv6'yı ve ortam tutarlılığını birlikte değerlendirir. Bu notlar, gerçek bir sızıntıyı normal kural tabanlı yönlendirmeden veya proxy modunun yol açtığı yanıltıcı sonuçlardan ayırt etmenize yardımcı olur.

Sızıntı testine dön

Technical Notes

WebRTC, UDP ve DNS sızıntısı hakkında

WebRTC sızıntısı nedir

WebRTC, tarayıcıların yerleşik gerçek zamanlı iletişim özelliğidir; görüntülü toplantılar, sesli aramalar, P2P dosya aktarımı ve benzeri senaryolarda kullanılır. Eşler arası bağlantı kurmak için tarayıcı, internet tarafından görülen kendi adresini bir STUN sunucusu aracılığıyla keşfeder. Bu yoklama genellikle UDP kullanır ve sıradan HTTP / SOCKS proxy'leri UDP'yi her zaman üstlenmez.

STUN isteği proxy'yi atlayıp doğrudan yerel ağdan çıkarsa bir web betiği gerçek genel IP'nizi elde edebilir. Bu süreç genellikle kamera veya mikrofon izni gerektirmez ve ek bir onay penceresi göstermez; bu yüzden bir proxy'nin gerçek zamanlı iletişim trafiğini gerçekten kapsayıp kapsamadığını kontrol etmek için sıkça kullanılır.

Bu araç nasıl tespit eder

Sayfa, birden çok STUN sunucusuna WebRTC yoklamaları gönderir, dönen genel adresleri toplar ve bunları HTTP çıkış IP'siyle karşılaştırır. Dönen adres mevcut çıkışla eşleşiyorsa UDP yolu büyük olasılıkla proxy tarafından üstleniliyordur; yerel operatörünüzün adresi dönüyorsa bu, incelenmesi gereken bir durumdur.

UDP'nin proxy çıkışından geçip geçmediğini doğrulama
IPv4 / IPv6'nın ayrı ayrı sızıntı yapıp yapmadığını tespit etme
Farklı STUN hedeflerinin farklı yönlendirme kurallarıyla eşleşip eşleşmediğini gözlemleme

STUN ve UDP'nin rolü

UDP; ses, görüntü, oyun ve gerçek zamanlı iletişim için yaygın olarak kullanılan bağlantısız bir aktarım protokolüdür. STUN'un görevi basittir: sunucuya bir UDP paketi gönderirsiniz, sunucu da gördüğü kaynak IP'yi size söyler. WebRTC bağlantıyı müzakere etmek için bu sonuca dayanır; bu nedenle STUN'un gördüğü adres, sızıntıyı değerlendirmede temel kanıttır.

Sonuçlar nasıl yorumlanır

Sızıntı tespit edilmediWebRTC'nin döndürdüğü genel IP, mevcut proxy çıkışınızla eşleşiyor (IPv6 için aynı /64). Hiç genel IP dönmüyorsa test yalnızca yanıt alamamıştır; bu, güvende olduğunuzun kanıtı değildir.

Şüpheli sızıntıWebRTC farklı bir genel IP döndürdü ve bu IP'nin konumu, operatörü veya ASN'si gerçek yerel ağınızı gösteriyor.

Normal kural tabanlı yönlendirmeBirden çok STUN sunucusu farklı proxy çıkışları döndürdü, ancak bu çıkışlar yapılandırdığınız hatlara veya yönlendirme kurallarına göre beklenen çıkışlardır.

Sızıntı bulduktan sonra ne yapmalı

Proxy istemcinizi TUN moduna geçirin; böylece WebRTC'nin UDP trafiği de proxy çıkışından geçer.
Chrome / Edge: kurumsal politika <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code> olarak ayarlayın; Firefox: <code>about:config</code> içinde <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> ayarını etkinleştirin. WebRTC'yi tamamen kaldırmayın; WebRTC'si olmayan bir tarayıcı başlı başına tanınabilir.
Brave: WebRTC IP işleme politikasını “Proxy kullanmayan UDP'yi devre dışı bırak” olarak ayarlayın.
Toplantı veya sesli arama yapmanız gerektiğinde önce proxy istemcinizdeki UDP / STUN yönlendirme kurallarını düzeltin.

Birden çok çıkış IP'si her zaman sızıntı anlamına gelmez

Kural tabanlı yönlendirme yapılandırdıysanız farklı STUN sunucuları farklı düğümler üzerinden gidebilir — örneğin Google'ın STUN sunucusu ABD çıkışından, Cloudflare'in STUN sunucusu ise Hong Kong çıkışından. Bu her zaman tehlikeli değildir; önemli olan kural tasarımınızla uyuşup uyuşmadığıdır. Asıl dikkat etmeniz gereken durum, tüm WebRTC adreslerinin fiziksel konumunuzu veya yerel İSS'nizi göstermesidir.

DNS sızıntısı da en az o kadar önemlidir

WebRTC sızıntısı “gerçek IP'nizi”, DNS sızıntısı ise “hangi alan adlarını sorguladığınızı” açığa çıkarır. DNS istekleri proxy üzerinden gitmiyorsa yerel operatörünüz veya üst sağlayıcı çözümleyiciniz hangi siteleri ziyaret ettiğinizi yine de görebilir.

Bu sayfadaki DNS sızıntısı tespiti gerçek bir yoklama kullanır: CleanIP.io, ABD'de Utah'ta (ns1) ve Los Angeles'ta (ns2) birer yetkili NS çalıştırır ve dp.cleanip.io bölgesine (zone) hizmet verir. Her tespitte 8 bağımsız <uuid>.dp.cleanip.io alt alan adı çözümlenir; bu sorgular sisteminizin stub çözümleyicisi -> İSS / VPN / genel özyinelemeli çözümleyici üzerinden geçerek sonunda yetkili NS'imize ulaşır. NS'imiz sorguyu yapan çözümleyicinin IP'sini ve (varsa) EDNS Client Subnet (istemci alt ağı) bilgisini kaydeder, ardından karşılaştırma için size döndürür.

İki sinyale odaklanın: ① ECS alt ağı — özyinelemeli çözümleyici istemci alt ağınızı iletmişse (Google 8.8.8.8 kullanıldığında yaygındır), bu alt ağ istemci kimliğinizin kesin kanıtıdır; ② çözümleyici ülkesi — genel özyinelemeli çözümleyicilerde (1.1.1.1 / 8.8.8.8) ülkeler arası anycast normaldir; önemli olan, VPN'inizin açık olduğunu düşündüğünüz sırada çözümleyicinin konumunun HTTP çıkışınızla aynı ülkede olup olmadığıdır.

Proxy modu ve TUN modu neden farklı sonuç verir

HTTP / SOCKS proxy'leri genellikle yalnızca TCP'yi işler; bu yüzden STUN'un ihtiyaç duyduğu UDP gönderilemeyebilir ve sayfa “sızıntı yok” gösterebilir. Bu, UDP'nin güvenli biçimde proxy'den geçirildiği anlamına gelmez — yalnızca UDP'nin STUN sunucusuna hiç ulaşmadığı anlamına gelir. TUN modu sanal ağ bağdaştırıcısında hem TCP'yi hem de UDP'yi yakalar; bu yüzden gerçek UDP çıkış yolunu daha iyi yansıtır.

ModSTUN UDPSonucun anlamı

HTTP / SOCKS proxy'siGönderilemeyebilir“Sızıntı yok” yalnızca UDP'nin engellendiği anlamına gelebilir

TUN / sanal bağdaştırıcıGerçekten gönderilebilirUDP çıkışını ve yönlendirme kurallarını doğrulamak için daha uygun

Gerçekte kullandığınız ağ modunda yeniden test etmenizi öneririz: Genellikle TUN kullanıyorsanız TUN ile test edin; tarayıcı proxy'sine güveniyorsanız engellenmiş UDP'nin yanlışlıkla güvenli sayılmadığından da emin olun. WebRTC sızıntısını değerlendirirken dönen IP'nin ASN'sine, konumuna ve yönlendirme beklentilerinize uyup uymadığına odaklanın.