Tema

Popüler araçlar

WebRTC Sızıntı Testi

WebRTC, tarayıcınızın normalde göndermeyeceği adresleri, VPN'inizin arkasındaki adres de dahil, bir web sitesine verebilir. Bu test, Cloudflare ve Google'ın işlettiği üç STUN sunucusuna sorar, geri dönen her adresi ve her birinin ne olduğunu gösterir ve bunları bir web sitesinin zaten gördüğü adresle karşılaştırır. Bir şeyi test edemediğinde, size yeşil bir onay işareti göstermek yerine bunu söyler.

Tarayıcınızda, Cloudflare ve Google STUN sunucularıyla çalışır · hiçbir şey saklanmaz · aday türleri RFC 8445'e göre

Bir kez VPN kapalıyken, bir kez de açıkken çalıştırın. Aradaki fark cevabın kendisidir.

Tarayıcınız, Cloudflare ve Google'ın işlettiği üç STUN sunucusuna hangi adresi gördüklerini sorar. WebRTC'nin bulduğu hiçbir adres bize gönderilmez.

Bir web sitesinin zaten gördükleriIPv4IPv6Bağlantınız bulunuyor…
WebRTC'nin ürettiği tüm adresler

  1. WebRTC'nin ürettiği her adres, STUN sunucuları yanıt verdikçe burada ayrı bir satırda görünür.

WebRTC'nin bulduğu hiçbir adres bize gönderilmez. Tarayıcınız STUN sunucularına, her görüntülü aramada olduğu gibi kendisi sorar. Bir web sitesinin ne gördüğünü göstermek için sayfa, DNS Sızıntı Testi'nin yaptığı gibi, adreslerinizi ve bunların ağlarını ipify.org'a ve kendi sunucumuza sorar.

WebRTC sızıntısı nedir?

WebRTC, görüntülü aramaların arkasındaki tarayıcı özelliğidir. İki kişiyi doğrudan bağlamak için makinenize ulaşılabilecek her adresi toplar ve sayfaya sunar; tarayıcınızın sıradan bir istekte asla göndermeyeceği adresler de buna dahildir.

Bu toplama işlemine ICE aday toplama (ICE candidate gathering) denir ve RFC 8445 belgesinde tanımlanmıştır. Tarayıcınız kendi ağ arayüzlerindeki adresleri listeler, ardından bir STUN sunucusuna “beni hangi adresten geliyor görüyorsun?” diye sorar ve o adresi de ekler. İnternetteki herhangi bir sayfa bunu birkaç satır JavaScript ile başlatabilir ve her adayı geldiği anda okuyabilir; hiçbir izin istemi çıkmaz. Tasarım budur, çünkü bir aramanın izin istemi olmadan da çalışması gerekir.

Bu adreslerden biri sizin gizlediğiniz bir şey olduğunda sızıntıya dönüşür. VPN, tarayıcınızın isteklerinin izlediği yolu değiştirir, ama WebRTC işletim sistemine tüm arayüzleri sorabilir; bu yüzden fiziksel bağlantının hâlâ açık olduğu bir makinede gerçek adres, VPN'in adresinin yanında görünebilir. Hiçbir şey bozulmadı: özellik tam olarak tasarlandığı işi yapıyor.

Herhangi bir sayfanın başlatabileceği şeytek bir toplama, adım adım

CİHAZINIZİNTERNETModeminiz (NAT)Sayfanın betiğiTarayıcınızSTUN sunucusustun.cloudflare.comnew RTCPeerConnection()izin istemi yokher ağ arayüzünü listeler192.168.1.20 → 8b7f4e2a-….localbeni hangi adresten geliyor görüyorsun?192.168.1.20:54400203.0.113.7:54400203.0.113.7:54400gördüğü adresher adayı, geldiği andaonicecandidateCİHAZINIZİNTERNETSayfanın betiğiTarayıcınızSTUN sunucusunew RTCPeerConnection()izin istemi yokher ağ arayüzünü listeler192.168.1.20 → 8b7f4e2a-….localbeni hangi adresten geliyor görüyorsun?192.168.1.20203.0.113.7203.0.113.7:54400gördüğü adresher adayı, geldiği andaonicecandidateModeminiz (NAT)

Betiğin tamamı

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

Yazdırdığı çıktı

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

Her satır nedir

  • hostBu makinede8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localTarayıcınız tarafından maskelendi
  • srflxBir STUN sunucusunun gördüğü203.0.113.7İnternette yönlendirilebilir
Bir ev bağlantısında tek bir toplama, belgeleme adresleriyle. Özel adres tarayıcıdan asla kendi haliyle çıkmaz; STUN sunucusu makineyi değil, modemin internete bakan tarafını görür ve iki yanıt da hangi betik sorduysa ona gider.
WebRTC sızıntı testi sonucu: her ICE adayı, türü, her adresin ne olduğu ve testin vardığı kararWebRTC sızıntı testi sonucu: her ICE adayı, türü, her adresin ne olduğu ve testin vardığı kararKararSızıntı, sızıntı yok ya da, dürüstçe, test edilemedi; nedeniyle birlikte.Her adresAday türüyle birlikte, çünkü host adayı sunucu yansımalı adaydan farklı bir şey anlatır.NedirÖzel, operatör düzeyinde NAT, bir tünel veya yönlendirilebilir. Yalnızca yönlendirilebilir bir adres sızıntı olabilir.SunucularHer STUN sunucusu kendi satırında. Hiçbir şey söylemeyen bir sunucu, çalışmamış bir testtir.Web sitesinin gördüğüTarayıcınızın zaten gönderdiği adresler; WebRTC adresleri bunlarla karşılaştırılır.
Bir test çalıştırması: her STUN sunucusunun yanıtı, WebRTC'nin açığa çıkardığı her adres, adresin türü ve web sitesinin zaten gördüğü bir adres olup olmadığı. Her bölümün ne gösterdiğini görmek için bir numara seçin.

WebRTC sızıntısı nasıl kontrol edilir

Yukarıdaki testi başlatın. Test üç STUN sunucusundan aday toplar, her adresin ne olduğunu belirler ve yönlendirilebilir olanları bir web sitesinin zaten gördüğü adresle karşılaştırır.

Üç sonuç mümkündür, iki değil. Sızıntı yok, WebRTC'nin ürettiği her yönlendirilebilir adresin sitenin zaten sahip olduğu bir adres olduğu anlamına gelir. Sızıntı, en az birinin öyle olmadığı ya da kendi makinenizdeki bir adresin doğrudan sunulduğu anlamına gelir. Test edilemedi ise WebRTC'nin kapalı ya da engellenmiş olduğu veya hiçbir STUN sunucusunun yanıt vermediği anlamına gelir; çoğu aracın sessizce başarılı sonuca çevirdiği durum budur.

VPN kullanıyorsanız testi iki kez çalıştırın: bir kez VPN kapalıyken, olağan adreslerinizi görmek için; bir kez de açıkken. Önemli olan ikinci çalıştırmadır ve ikisi arasındaki fark cevabın kendisidir. Sayfa ilk sonucu saklar, böylece hiçbir şey not almadan karşılaştırabilirsiniz.

İki değil, üç sonuçher biri ne anlama gelir

  1. Sızıntı yok

    WebRTC'nin ürettiği her yönlendirilebilir adres, bir web sitesinin zaten sahip olduğu bir adres.

    WebRTC'nin verdiği

    • 198.51.100.23Bir STUN sunucusunun gördüğüWeb siteleri zaten görüyor
    • 8b7f4e2a-….localBu makinedeTarayıcınız tarafından maskelendi

    Web sitesinin gördüğü

    198.51.100.23
  2. Sızıntı

    En az bir adres sitenin zaten sahip olduğu bir adres değil ya da kendi makinenizdeki bir adres doğrudan sunuldu.

    WebRTC'nin verdiği

    • 198.51.100.23Bir STUN sunucusunun gördüğüWeb siteleri zaten görüyor
    • 2001:db8:4a1f:7c00::1cBu makinedeWeb siteleri görmüyor

    Web sitesinin gördüğü

    198.51.100.23
  3. Test edilemedi

    WebRTC kapalı veya engellenmiş ya da hiçbir STUN sunucusu yanıt vermedi. Hiçbir şey ölçülmedi.

    stun.cloudflare.comYanıt yok

    stun.l.google.comYanıt yok

    Çoğu aracın burada gösterdiğiSızıntı yok

İki kez çalıştırın

VPN kapalı

WebRTC'nin verdiği203.0.113.7

Web sitesinin gördüğü203.0.113.7

Sızıntı yok

VPN açık

WebRTC'nin verdiği198.51.100.23203.0.113.7

Web sitesinin gördüğü198.51.100.23

VPN açıkken de orada

Sızıntı
Her sonuç, onu üreten bir çalıştırmayla. VPN kapalıyken WebRTC'nin adresi ile web sitesininki aynıdır; VPN açıkken ikisi de değişmelidir ve değişmeden kalan adres cevabın kendisidir.

VPN, WebRTC sızıntısını önler mi?

Tek başına önlemez. VPN trafiğinizin nereye gittiğini değiştirir; WebRTC ise işletim sisteminize hangi arayüzlerin olduğunu sorabilir ve fiziksel arayüz genellikle hâlâ oradadır.

IETF'nin kendi açıklaması nettir: “istemci fiziksel konumunu bir Sanal Özel Ağ (VPN) ile gizlemeye çalışırsa ve VPN ile yerel işletim sistemi birden fazla arayüz üzerinden yönlendirmeyi destekliyorsa, WebRTC yalnızca VPN'in genel adresini değil, VPN'in üzerinde çalıştığı ISP genel adresini de keşfedebilir”. İki adres de sunulur ve bakan bir sayfa ikisini de okuyabilir.

Bazı VPN istemcileri bu açığı, tüm trafiği işletim sistemi düzeyinde yönlendirerek ya da WebRTC'yi kısıtlayan bir tarayıcı uzantısıyla birlikte gelerek kapatır. İkisi de işe yarar ve ikisi de varsayılacak değil, kontrol edilecek şeylerdir; bu sayfa da tam bunun için var. Kendi sızıntı testi sayfası size korunduğunuzu söyleyen bir VPN, bağımsız bir kanıt değildir.

VPN açık, Wi-Fi hâlâ bağlıiki arayüz, iki yanıt

DizüstünüzVPN10.64.0.2Wi-Fi192.168.1.20VPN TÜNELİVPN sunucusu198.51.100.23Web sitesigezinmenizSTUN sunucusuModem (NAT)Sağlayıcınız203.0.113.7WebRTC ikisinden de sorarDizüstünüzVPN10.64.0.2Wi-Fi192.168.1.20VPN TÜNELİVPN sunucusu198.51.100.23Modem (NAT)Sağlayıcınız203.0.113.7gezinmenizWeb sitesiSTUN sunucusuWebRTC ikisinden de sorar

Sayfanın aldığı

  • 198.51.100.23srflxBir STUN sunucusunun gördüğüVPN üzerindenWeb siteleri zaten görüyor
  • 203.0.113.7srflxBir STUN sunucusunun gördüğüWi-Fi üzerinden, tünel dışındaWeb siteleri görmüyor

RFC 8828

Açığı kapatan şey

  • İşletim sistemi düzeyinde yönlendirmeTünelin dışından hiçbir şey çıkmaz, bu yüzden bir STUN sunucusu yalnızca VPN'in adresini görebilir.
  • VPN'in tarayıcı uzantısıWebRTC'yi tarayıcının içinde kısıtlar, bu yüzden diğer arayüze hiç sorulmaz.
  • Sonra varsaymayın, kontrol edinBu testi VPN açıkken çalıştırın. Bir VPN'in kendi sızıntı testi sayfası bağımsız bir kanıt değildir.
IETF'nin RFC 8828 belgesinde anlattığı durum: VPN ve işletim sistemi birden fazla arayüz üzerinden yönlendirir, bu yüzden WebRTC hem VPN'in genel adresini hem de onun altındaki sağlayıcı adresini bulur.

Host, sunucu yansımalı ve relay: hangi aday hangisi?

Host adayı kendi makinenizdeki bir adrestir. Sunucu yansımalı (server-reflexive) aday, bir STUN sunucusunun gördüğü adrestir: NAT'ınızın internete bakan tarafı. Relay adayı ise sizin değil, bir TURN sunucusunun adresidir.

Bu ayrım önemlidir ve çoğu sızıntı testi onu bir kenara atar. Genel IPv4 adresinizi taşıyan bir sunucu yansımalı aday genellikle yeni bir bilgi değildir: web sitesinin, zaten kurmakta olduğunuz bağlantıdan aldığı adresin aynısıdır. Yönlendirilebilir bir adres taşıyan bir host adayı ise başka bir şeydir: makinenin kendisindeki, sayfaya doğrudan sunulan bir adrestir. Yalnızca evinizin modemini değil, bu makineyi tanımlar ve ağ değişince o da değişir.

Sayfa her adresin yanında türünü, taşıma protokolünü, portu ve yansımalı bir adayın belirttiği ilişkili adresi gösterir. Relay adayı TURN sunucusunun kendi adresidir ve sizin hakkınızda hiçbir şey açığa çıkarmaz; bu test hiç TURN sunucusu kullanmaz, bu yüzden böyle bir aday görünürse onu sayfadaki başka bir şey yapılandırmış demektir.

Tek bir aday, alan alanbir sayfanın aldığı haliyle

  1. candidate:1467250027Temel
  2. 1Bileşen
  3. udpTaşıma
  4. 1686052607Öncelik
  5. 203.0.113.7Adres
  6. 54400Port
  7. typ srflxTür
  8. raddr 0.0.0.0 rport 9İlişkili adres
  9. generation 0Uzantı

Yerel adreslerin maskelendiği yerde 0.0.0.0, port 9 olarak boşaltılır

Dört tür

  • typ hostBu makinede

    Kendi ağ arayüzlerinizden birindeki bir adres.

    Özel olan maskelenir. Yönlendirilebilir olan cihazın kendisidir: en ciddi bulgu.

    Yönlendirilebilirse en ciddisi

  • typ srflxBir STUN sunucusunun gördüğü

    Modeminizin internete bakan tarafı, bir STUN sunucusunun gördüğü haliyle.

    Genellikle bir web sitesinin bağlantınızdan zaten aldığı adres.

    Genellikle yeni değil

  • typ prflxKarşı tarafın gördüğü

    Modeminizin internete bakan tarafı, bir aramanın karşı ucunun gördüğü haliyle.

    Yalnızca karşı tarafa bağlanırken bulunur, bu yüzden arama içermeyen bir test bunu hiç görmez.

    Yalnızca arama sırasında

  • typ relayBir relay sunucusunun kendi adresi

    Trafiğinizi sizin için aktaran bir TURN sunucusunun adresi.

    Sizin değil, sunucunun adresi. Bu test hiç TURN sunucusu kullanmaz, yani burada görünen bir tanesini başka bir şey yapılandırmıştır.

    Sizinle ilgili hiçbir şey

Adayın adresi bir web sitesinin gördüğüyle karşılaştırılır; türü ise bir farkın ne kadar ciddi olduğunu söyler. Tanımlar: RFC 8445, bölüm 4.

mDNS .local adresi nedir, beni korur mu?

Modern tarayıcılar, özel adreslerinizi bir sayfaya sunmadan önce .local ile biten rastgele bir adla değiştirir. Bu işe yarar, özel adresler için. Genel bir adresi gizlemek için hiç tasarlanmadı.

Chrome bunu 76. sürümden beri varsayılan olarak yapıyor ve Firefox'ta media.peerconnection.ice.obfuscate_host_addresses true olarak ayarlı: sayfa 192.168.1.20 yerine 8b7f4e2a-….local gibi bir şey alır; bu da ağınızın dışındaki hiç kimse için bir anlam taşımaz. Safari ise daha da ileri gidiyor: bir siteye kamera veya mikrofon izni verilene kadar hiç host adayı sunmuyor. Yukarıdaki test bu .local adlarını tanır ve onları bir bulgu olarak değil, korumanın çalıştığının göstergesi olarak raporlar.

Bunu tanımlayan IETF taslağı, neyi yapmadığı konusunda açıktır: “internete zaten açık olan bir adresin mDNS ile korunmasına gerek yoktur, çünkü web sunucusu onu kolayca gözlemleyebilir”. Yani sunucu yansımalı bir aday hâlâ genel IPv4 adresinizi taşır ve, insanları şaşırtan kısım şu ki, yönlendirilebilir bir IPv6 adresi olan bir makine bu adresi hâlâ host adayı olarak sunabilir. Bilinmesi gereken bir açık daha var: Chrome, kamera veya mikrofon izni zaten verilmiş her sitede korumayı kapatır; yani daha önce kullandığınız bir görüntülü arama sitesi gerçek yerel adreslerinizi görür.

.local adının yerini aldığı şeyve olduğu gibi bıraktığı

Tarayıcınızdaki

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

Sayfanın aldığı

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

Her tarayıcının varsayılan olarak yaptığı

  • ChromeSürüm 76, Ağustos 2019
  • Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
  • SafariBir siteye kamera veya mikrofon izni verilene kadar host adayı yok

Mekanizma bir IETF taslağıdır; son revizyonu Aralık 2021 tarihlidir ve hiçbir zaman RFC olarak yayımlanmadı. draft-ietf-mmusic-mdns-ice-candidates-03

WebRTC'nin sunabileceği bir adresMaskeli mi?
192.168.1.20Özel IPv4 adresiniz, host adayı olarakMaskeliRastgele bir adla değiştirilir: sayfa ağınız hakkında hiçbir şey öğrenmez.
203.0.113.7Genel IPv4 adresiniz, STUN sunucusunun adayı olarakGörünürZaten genel, bu yüzden kalır. Yalnızca ilişkili adres boşaltılır.
2001:db8:4a1f:7c00::1cYönlendirilebilir bir IPv6, host adayı olarakGörünürO da genel, bu yüzden maskeleme onu kapsamak için hiç tasarlanmadı.
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Geçici bir IPv6 adresiGörünebilirTaslak, tarayıcının bunu tercihe bağlı olarak maskelemeden bırakmasına izin verir.
192.168.1.20Kamera veya mikrofon izni olan bir sitede herhangi bir yerel adresMaskeleme kapalıChrome orada maskelemeyi kapatır: site gerçek yerel adreslerinizi görür.
Maskeleme yalnızca kendi ağınızın bildiğini gizler. Bir web sitesinin zaten görebileceğini olduğu gibi bırakır: bu bir hata değil, tasarımın gereği.

IPv6 neden geriye kalan sızıntıdır

Global bir IPv6 adresi, NAT arkasındaki bir eve değil tek bir makineye aittir ve mDNS onu bilerek olduğu gibi bırakır. WebRTC'nin hâlâ verdiği en tanımlayıcı şey budur.

IPv4'te ev modeminizin NAT'ı her şeyi tek bir adresin arkasına koyar; bu yüzden sunucu yansımalı bir aday bir sayfaya, olağan bağlantınızın zaten söylediğini aşağı yukarı söyler. IPv6'da NAT yoktur: her cihazın kendi yönlendirilebilir adresi vardır ve bu adresi taşıyan bir host adayı hattı değil cihazı tanımlar. VPN'iniz yalnızca IPv4 taşıyorsa (birçoğu öyledir), bu IPv6 adresi ayrıca tamamen tünelin dışında kalır.

Gizlilik uzantıları yardımcı olur, çünkü geçici bir IPv6 adresi belirli aralıklarla değişir. Yine de adresi gizlemezler: mDNS taslağı bu tür adreslerin maskelenmeden bırakılabileceğini söyler. Yukarıdaki test, yönlendirilebilir bir IPv6 host adayını bulabileceği en ciddi şey olarak işaretler; IPv6 Testi de bağlantınızda IPv6 olup olmadığını size söyler.

Bir adres kimi tanımlaraynı üç cihaz, iki kez

ModemIPv4, NAT arkasındaIPv6, NAT yok
Dizüstü192.168.1.202001:db8:4a1f:7c00::1c
Telefon192.168.1.212001:db8:4a1f:7c00::2b
TV192.168.1.222001:db8:4a1f:7c00::3d
Modem203.0.113.7Tüm hat için tek adresHer cihaza bir adres

Global bir IPv6 adresi, iki yarıda

2001:db8:4a1f:7c00Ağ öneki: hattınız /64:8d3:5e2f:a41c:9b07Arayüz kimliği: bu cihaz

  • Kalıcı2001:db8:4a1f:7c00::1c
  • Geçici: değişir2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

Yalnızca IPv4 taşıyan bir VPN

  • IPv4198.51.100.23Tünelin içinde
  • IPv62001:db8:4a1f:7c00::1cTünelin dışında
IPv4 NAT arkasında bir ev tek bir adresi paylaşır; IPv6'da her cihazın kendi adresi vardır ve bir host adayı bunu doğrudan sunar. Test, yönlendirilebilir bir IPv6 host adayını en ciddi bulgu sayar.

Her tarayıcıda WebRTC sızıntısı nasıl durdurulur

Firefox'ta işe yarayan tercihler var. Edge'de kurumsal bir ilke var. Safari adayları zaten kısıtlıyor. İnsanların hâlâ önerdiği tarayıcı uzantıları ise artık hiçbir şey yapmıyor.

Firefox'ta about:config → media.peerconnection.ice.default_address_only tüm adresler yerine yalnızca bir adres gönderir; media.peerconnection.ice.relay_only ise toplamayı relay adaylarıyla sınırlar: bu, doğrudan aramaları bozar ama geri kalan her şeyi gizler. İkisi de varsayılan olarak kapalıdır; özel adreslerin mDNS maskelemesi (media.peerconnection.ice.obfuscate_host_addresses) zaten açıktır. Edge'de WebRtcLocalIpsAllowedUrls ilkesi hangi sitelerin yerel adresleri görebileceğini belirler; Microsoft'un kendi belgeleri bir site eklemenin “korumayı zayıflattığını” belirtir. Chrome'da sıradan bir kullanıcı için eşdeğer bir ayar yoktur. Safari siz istemeden en sıkı olanıdır: kamera veya mikrofon izni olmadan WebKit yalnızca sunucu yansımalı ve relay adaylarını sunar, hiç host adayı sunmaz.

Hâlâ sıkça önerilen iki şey artık işe yaramıyor. uBlock Origin'in “Prevent WebRTC from leaking local IP addresses” seçeneği 1.38 sürümünde kaldırıldı; notta bunun “Android için Firefox dışında, modern tarayıcılarda artık gerekli olmadığı” belirtildi. Google'ın mağazada hâlâ listelenen WebRTC Network Limiter uzantısı ise çalışamıyor: Manifest V2 uzantıları Temmuz 2025'teki Chrome 138'den beri tüm Chrome kullanıcıları için devre dışı. Bir sayfa size bunlardan birini kurmanızı söylüyorsa, o sayfa yıllardır güncellenmemiş demektir.

Her tarayıcının sunduğuher üreticinin belgeleriyle doğrulandı

  • Firefoxİşe yarayan tercihler

    about:config

    • media.peerconnection.ice.obfuscate_host_addressesVarsayılan trueÖzel adresleri maskeler. Zaten açık.
    • media.peerconnection.ice.default_address_onlyVarsayılan falseŞuna ayarlayın trueTüm adresler yerine tek bir adres gönderir.
    • media.peerconnection.ice.relay_onlyVarsayılan falseŞuna ayarlayın trueYalnızca relay adayları. En çok gizleyen budur ve doğrudan aramaları bozar.

  • EdgeKurumsal ilke

    WebRtcLocalIpsAllowedUrls

    Yerel adresleri görebilecek siteleri listeler.

    Yapılandırılmamış: yerel adresler maskeli kalır.

    Microsoft'un kendi notu: bir site eklemek korumayı zayıflatır.

    Windows ve macOS, sürüm 80 ve sonrası

  • ChromeAyar yok

    Sıradan bir kullanıcı için ayar yok.

    Özel adresler, sürüm 76 itibarıyla varsayılan olarak maskeli.

    Kamera veya mikrofon izni olan sitelerde değil.

  • SafariVarsayılan olarak sıkı

    Kamera veya mikrofon izni olmadan yalnızca STUN sunucusu ve relay adayları.

    Hiç host adayı yok.

Artık işe yaramayan tavsiyeler

  • Prevent WebRTC from leaking local IP addresses

    uBlock Origin

    Sürüm 1.38 ile kaldırıldı

    uBlock Origin'e göre Android için Firefox dışında modern tarayıcılarda artık gerekli değil.

  • WebRTC Network Limiter

    Google · Chrome Web Store

    Hâlâ listede, çalışamıyor

    Manifest V2 uzantıları, Chrome 138 sürümünden (Temmuz 2025) beri tüm Chrome kullanıcıları için devre dışı.

Her üreticinin kendi belgeleri, bu sayfanın kontrol edildiği gün okundu. Hâlâ son ikisinden birini kurmanızı söyleyen bir sayfa yıllardır güncellenmemiştir.

WebRTC sızıntısı, DNS sızıntısı ve IP sızıntısı: farkı ne?

Bunlar bir VPN'in atlatılabileceği üç farklı yoldur. WebRTC sızıntısı bir adresi gösterir; DNS sızıntısı sorgularınızı kimin yanıtladığını gösterir; IP sızıntısı ise trafiğinizin tünele hiç girmediği basit durumdur.

WebRTC sızıntısı, tarayıcınızın tam da adres vermek için tasarlanmış bir özellik aracılığıyla kendiliğinden verdiği adreslerle ilgilidir. DNS sızıntısı ise sorgularınızı hangi çözümleyicinin yanıtladığıyla ilgilidir: trafiğiniz VPN'den geçerken sorgularınız hâlâ sağlayıcınızın çözümleyicisine gidebilir ve bu, o sağlayıcıya ziyaret ettiğiniz her siteyi söyler. DNS Sızıntı Testi aracımız bunu kendi ad sunucumuzla kontrol eder, böylece hangi çözümleyicilerin sorduğunu tam olarak görebilir.

Genel anlamda IP sızıntısı, bir web sitesinin doğrudan gördüğü adrestir; bunu IP Adresim Nedir veya ISP'im Nedir sayfasında kontrol edebilirsiniz. Herhangi bir VPN değişikliğinden sonra üçünü birlikte çalıştırın: birbirlerinden bağımsız olarak başarısız olurlar ve birindeki temiz sonuç diğerleri hakkında hiçbir şey söylemez.

Bir VPN'i atlatmanın üç yoluher biri ayrı ayrı başarısız olur

SizVPN TÜNELİTünelden geçerIP sızıntısı · trafiğinizWeb sitesi203.0.113.7DNS sızıntısı · sorgularınızSağlayıcınızın çözümleyicisi203.0.113.53WebRTC sızıntısı · adreslerinizSayfanın betiği203.0.113.7SizVPN TÜNELİTünelden geçerIP sızıntısıtrafiğinizWeb sitesi203.0.113.7DNS sızıntısısorgularınızSağlayıcınızın çözümleyicisi203.0.113.53WebRTC sızıntısıadreslerinizSayfanın betiği203.0.113.7

  • IP sızıntısı

    Ne sızarHer isteğin taşıdığı adres

    Kim öğrenirZiyaret ettiğiniz her site

    Şununla kontrol edinIP Adresim NedirISP'im Nedir

  • DNS sızıntısı

    Ne sızarSorgularınızı hangi çözümleyicinin yanıtladığı

    Kim öğrenirSorguladığınız her site için sağlayıcınız

    Şununla kontrol edinDNS Sızıntı Testi

  • WebRTC sızıntısı

    Ne sızarTarayıcınızın bir sayfaya sunduğu adresler

    Kim öğrenirSoran her sayfa, izin istemi olmadan

    Şununla kontrol edinWebRTC Sızıntı Testi

Birbirlerinden bağımsız olarak başarısız olurlar: birindeki temiz sonuç diğer ikisi hakkında hiçbir şey söylemez. VPN'inizde yapılan her değişiklikten sonra üçünü de çalıştırın.

Bu test neden birden fazla STUN sunucusuna sorar

Çünkü “hiçbir adres dönmedi” ile “hiçbir adres yok” aynı görünür ve yalnızca biri iyi haberdir.

Bir kurumsal güvenlik duvarı, kısıtlayıcı bir VPN veya UDP'yi engelleyen bir ağ, bir STUN sunucusunun yanıt vermesini engelleyebilir. Tek bir sağlayıcıya sorup hiçbir şey görmeyen bir test hiçbir şey öğrenmemiştir; yine de olağan tepki yeşil bir onay işareti göstermektir. Bu test Cloudflare'in belgelenmiş STUN uç noktasına ve Google'ınkine sorar, her birini ayrı raporlar ve hiçbiri yanıt vermediğinde test edilemediğini söyler.

Sunucu seçimi bilinçlidir. Cloudflare, stun.cloudflare.com:3478 adresini bir ürünün parçası olarak yayımlar, yani okunacak koşullar vardır. Google'ın stun.l.google.com:19302 adresi yalnızca Google'ın kendi WebRTC doğrulayıcısının varsayılanı olarak belgelenmiştir ve yayımlanmış koşulları yoktur; bu yüzden tek kaynak olarak değil, ikinci görüş olarak kullanılır. Twilio'nunki kimlik bilgisi ister; Mozilla ise, sık sık bir tanesi anılsa da, hiçbir genel STUN sunucusu belgelemez.

Genel STUN sunucularıve bu testin hangilerine sorduğu

  • CloudflareSoruluyor

    stun.cloudflare.com:3478

    Belgelenmiş bir uç nokta; bir ürünün parçası, okunacak koşulları var.

  • GoogleSoruluyor, ikinci görüş olarak

    stun.l.google.com:19302

    Yalnızca Google'ın kendi WebRTC doğrulayıcısının varsayılanı olarak belgelenmiş. Yayımlanmış koşulu yok.

  • TwilioSorulmuyor

    global.stun.twilio.com:3478

    Twilio'nun API'sinden kimlik bilgisi ister: her sayfaya açık değil.

  • MozillaSorulmuyor

    Genel sunucu yok

    Genel bir STUN sunucusu belgelemiyor. Firefox hiçbir varsayılan ICE sunucusuyla gelmez.

Bir sunucu hiçbir şey söylemediğinde

CloudflareGoogle
Yanıt verdiYanıt verdiSonuç geçerli
Yanıt verdiSessizSonuç geçerli; sessiz sunucunun adı verilir
SessizYanıt verdiSonuç geçerli; sessiz sunucunun adı verilir
SessizSessizTest edilemedi
İki operatör, ayrı ayrı soruluyor. Sessiz kalan tek sunucunun adı verilir ve sonuç geçerli kalır; hiçbiri yanıt vermediğinde hiçbir şey ölçülmemiştir ve test, başarılı bir sonuç göstermek yerine bunu söyler.

IP adresim kişisel veri mi?

AB'de dinamik bir IP adresi, sağlayıcının elindeki bilgilerle sizi tanımlayabilecek bir web sitesi işletmecisi için kişisel veridir. Adalet Divanı bunu 2016'da karara bağladı.

Dava Breyer, C-582/14; 19 Ekim 2016'da karara bağlandı ve Adalet Divanı'nın basın bülteni kararı şöyle özetliyor: “bir ziyaretçinin dinamik internet protokolü adresi, web sitesinin işletmecisi bakımından, söz konusu işletmecinin ilgili ziyaretçiyi internet erişim sağlayıcısının elindeki ek bilgilerle tanımlamasına imkân veren hukuki araçlara sahip olması halinde kişisel veri teşkil eder”. Aynı basın bülteni, bir sitenin kendini saldırılara karşı savunmak için bu verilerin bir kısmını saklamakta meşru bir menfaati olabileceğini de belirtiyor.

Bu sayfanın işini tarayıcınızda yapmasının tüm nedeni budur. ICE adayları tarayıcınız tarafından toplanır, tarayıcınızda karşılaştırılır ve size gösterilir; WebRTC'nin bulduğu hiçbir adres bize gönderilmez, dolayısıyla bizim saklayacağımız, teslim edeceğimiz ya da kaybedeceğimiz bir şey yoktur. Test çalışırken ağ panelini izleyebilirsiniz.

Breyer kararıAvrupa Birliği Adalet Divanı

C-582/14Breyer v Bundesrepublik Deutschland19 Ekim 2016

  1. Web sitesi işletmecisikayıtlarından bir adres ve bir zaman203.0.113.7 · 14:02:37
  2. bunu elde etmek için hukuki araçlar
  3. İnternet erişim sağlayıcısıo adresi o anda kimin kullandığı203.0.113.7 · 14:02:37 →
  4. O işletmeci için kişisel veri

Adalet Divanı'nın basın bülteni: bir site, kendini saldırılara karşı savunmak için bu verilerin bir kısmını saklamakta meşru bir menfaate sahip olabilir.

Bu sayfada

Tarayıcınız

  1. Toplar
  2. Sınıflandırır
  3. Karşılaştırır
  4. Gösterir
  • Her aramada olduğu gibi genel adresinizi görür
  • dnsrobot.netHiçbir aday gönderilmez
Dava C-582/14, Breyer. Dinamik bir IP adresi, sağlayıcının kayıtlarıyla sizi tanımlamak için hukuki araçlara sahip bir web sitesi işletmecisi için kişisel veridir. Bu sayfa adayları tarayıcınızda tutar.

WebRTC sızıntı testi: sorular ve cevaplar

WebRTC sızıntısı nedir?

WebRTC, görüntülü aramaların arkasındaki tarayıcı özelliğidir. İki kişiyi doğrudan bağlamak için makinenize ulaşılabilecek her adresi toplar ve hiçbir izin istemi göstermeden sayfaya sunar. Bu adreslerden biri gizlediğiniz bir adres olduğunda sızıntıya dönüşür: genellikle VPN açıkken gerçek adresiniz, çünkü WebRTC yalnızca gezinmenizin kullandığı arayüzü değil, tüm ağ arayüzlerini sorabilir.

WebRTC sızıntısını nasıl test ederim?

Bu sayfadaki testi başlatın. Test iki operatörün üç STUN sunucusuna sorar, WebRTC'nin ürettiği her adresi ne tür bir adres olduğuyla birlikte listeler ve yönlendirilebilir olanları bir web sitesinin zaten gördüğü adresle karşılaştırır. VPN kullanıyorsanız bir kez VPN kapalıyken, bir kez de açıkken çalıştırın: iki çalıştırma arasındaki fark cevabın kendisidir.

VPN, WebRTC sızıntısını önler mi?

Tek başına önlemez. VPN trafiğinizin nereye gittiğini değiştirir, ama WebRTC işletim sistemine hangi arayüzlerin olduğunu sorabilir ve fiziksel bağlantı genellikle bunlardan biri olmaya devam eder. IETF'nin kendi metni, WebRTC'nin “yalnızca VPN'in genel adresini değil, VPN'in üzerinde çalıştığı ISP genel adresini de” keşfedebileceğini söyler. Bazı VPN istemcileri bu açığı kapatır; bu test sizinkinin kapatıp kapatmadığını söyler.

Sonuçlardaki .local adresi ne anlama geliyor?

Bu mDNS'tir ve iyi bir haberdir. Modern tarayıcılar, özel adreslerinizi bir sayfaya sunmadan önce .local ile biten rastgele bir adla değiştirir; böylece site bu adlardan ev ağınız hakkında hiçbir şey öğrenmez. Chrome bunu 76. sürümden beri yapıyor, Firefox da aynısını yapıyor; Safari ise daha da ileri gidiyor ve bir siteye kamera veya mikrofon izni verilene kadar hiç host adayı sunmuyor. Test bu adları bir bulgu olarak değil, korumanın çalıştığının göstergesi olarak işaretler.

mDNS yerel IP'mi gizliyorsa güvende miyim?

Kısmen. mDNS özel adresleri gizlemek için tasarlandı ve açıkça, zaten genel olan bir adresi gizlemek için tasarlanmadı: onu tanımlayan IETF taslağı bunu söyler. Genel IPv4 adresiniz hâlâ sunucu yansımalı aday olarak görünür ve yönlendirilebilir bir IPv6 adresi olan bir makine bu adresi hâlâ doğrudan sunabilir. Chrome ayrıca kamera veya mikrofon izni zaten verilmiş her sitede korumayı kapatır.

Test neden bazen “test edilemedi” diyor?

Çünkü gerçek bu. WebRTC kapalıysa, bir uzantı veya ilke tarafından engellenmişse ya da hiçbir STUN sunucusu yanıt vermediyse (bir güvenlik duvarı, kısıtlayıcı bir VPN, UDP'yi engelleyen bir ağ), hiçbir şey ölçülmemiştir. Çoğu araç bu durumda yeşil bir onay işareti gösterir; bu, bir sızıntı testinin yapabileceği en yanıltıcı şeydir. Bu test ne olduğunu söyler ve hangi sunucuların sessiz kaldığını belirtir.

Firefox'ta WebRTC'yi nasıl devre dışı bırakırım?

Firefox'un belgelenmiş tercihleri WebRTC'yi kapatmaz, kısıtlar. about:config içinde media.peerconnection.ice.default_address_only tüm adresler yerine tek bir adres gönderir, media.peerconnection.ice.relay_only ise toplamayı relay adaylarıyla sınırlar: en çok gizleyen budur ama doğrudan aramaları bozar. Özel adreslerin maskelenmesi, media.peerconnection.ice.obfuscate_host_addresses, varsayılan olarak zaten açıktır. Size ne kazandırdığını görmek için her değişiklikten sonra testi yeniden çalıştırın.

Chrome'da WebRTC sızıntılarını nasıl durdururum?

Chrome sıradan bir kullanıcıya bunun için hiçbir ayar sunmaz; özel adreslerin mDNS maskelemesi varsayılan olarak açıktır ve elinizdeki koruma budur. Chrome ile aynı motoru kullanan Edge'de WebRtcLocalIpsAllowedUrls kurumsal ilkesi vardır. Hâlâ sıkça önerilen uzantılar çalışmaz: uBlock Origin WebRTC seçeneğini 1.38 sürümünde kaldırdı ve Google'ın WebRTC Network Limiter uzantısı, Manifest V2 Chrome 138'de devre dışı bırakıldığından beri çalışamıyor.

Host adayı ile sunucu yansımalı aday arasındaki fark nedir?

Host adayı kendi makinenizdeki bir adrestir. Sunucu yansımalı aday, bir STUN sunucusunun gördüğü adrestir: NAT'ınızın internete bakan tarafı; bu genellikle web sitesinin bağlantınızdan zaten aldığı adrestir. Yönlendirilebilir bir host adayı daha ciddi bir bulgudur, çünkü cihazın kendisindeki bir adrestir ve IPv6'da evi değil cihazı tanımlar.

WebRTC sızıntısı ile DNS sızıntısı aynı şey mi?

Hayır. WebRTC sızıntısı bir adresi açığa çıkarır; DNS sızıntısı ise sorgularınızı hangi çözümleyicinin yanıtladığını açığa çıkarır ve trafiğin kendisi VPN'den geçse bile sağlayıcınıza ziyaret ettiğiniz her siteyi söyler. Birbirlerinden bağımsız olarak başarısız olurlar, yani birindeki temiz sonuç diğeri hakkında hiçbir şey söylemez. Herhangi bir VPN değişikliğinden sonra DNS Sızıntı Testi aracımızı da çalıştırın.

Bu test IP adresimi bir yere gönderiyor mu?

Yalnızca herhangi bir web sitesinin de göreceği yerlere. Tarayıcınız, her görüntülü aramada olduğu gibi STUN sunucularıyla iletişim kurar: test budur. Bir web sitesinin ne gördüğünü öğrenmek için sayfa, DNS Sızıntı Testi'nin yaptığı gibi, adreslerinizi ve bunların ağlarını ipify.org'a ve kendi sunucumuza sorar. WebRTC'nin bulduğu adresler tarayıcınızda kalır: hiçbiri bize gönderilmez. Test çalışırken ağ panelinizi izleyin.

IP adresim AB hukukuna göre kişisel veri mi?

AB'deki bir web sitesi işletmecisi için dinamik bir IP adresi, işletmeci internet sağlayıcısının elindeki bilgilerle sizi tanımlamak için hukuki araçlara sahipse kişisel veridir. Bu, Adalet Divanı'nın Ekim 2016 tarihli Breyer, C-582/14 kararıdır. Bu sayfanın testin WebRTC bölümünü bizim bir sunucumuzda değil, tarayıcınızda tutmasının nedenlerinden biri de budur.

Eksik bir şey mi var?Bir özellik ya da yeni bir araç önerin

İlgili araçlar