Tema

Alat populer

Tes Kebocoran WebRTC

WebRTC bisa memberikan alamat yang biasanya tidak dikirim browser Anda ke situs web, termasuk alamat di balik VPN Anda. Cek WebRTC ini bertanya ke tiga server STUN milik Cloudflare dan Google, menampilkan setiap alamat yang kembali beserta jenisnya, lalu membandingkannya dengan alamat yang sudah dilihat situs web. Jika ada yang tidak bisa diuji, tes ini mengatakannya, alih-alih menampilkan centang hijau.

Berjalan di browser Anda dengan STUN Cloudflare dan Google · tidak ada yang disimpan · jenis kandidat dari RFC 8445

Jalankan sekali dengan VPN mati dan sekali dengan VPN menyala. Perbedaannya adalah jawabannya.

Browser Anda bertanya ke tiga server STUN milik Cloudflare dan Google alamat mana yang mereka lihat. Tidak ada alamat temuan WebRTC yang dikirim ke kami.

Yang tetap dilihat situs webIPv4IPv6Mencari koneksi Anda…
Setiap alamat yang dihasilkan WebRTC

  1. Setiap alamat yang dihasilkan WebRTC muncul di sini, satu baris untuk masing-masing, begitu server STUN menjawab.

Tidak ada alamat temuan WebRTC yang dikirim ke kami. Browser Anda sendiri yang bertanya ke server STUN, seperti yang dilakukan setiap panggilan video. Untuk menunjukkan apa yang dilihat situs web, halaman ini menanyakan alamat Anda beserta jaringannya ke ipify.org dan ke server kami sendiri, seperti yang dilakukan Tes Kebocoran DNS.

Apa itu kebocoran WebRTC?

WebRTC adalah fitur browser di balik panggilan video. Untuk menghubungkan dua orang secara langsung, WebRTC mengumpulkan setiap alamat tempat perangkat Anda bisa dijangkau dan menawarkannya ke halaman, termasuk alamat yang tidak akan pernah dikirim browser Anda dalam permintaan biasa.

Pengumpulan ini disebut ICE candidate gathering, yang ditetapkan dalam RFC 8445. Browser Anda mendaftar alamat di interface jaringan Anda sendiri, lalu bertanya ke server STUN “dari alamat mana Anda melihat saya datang?” dan menambahkan alamat itu juga. Halaman mana pun di internet bisa memulainya dengan beberapa baris JavaScript dan membaca setiap kandidat begitu tiba, tanpa permintaan izin — memang begitu rancangannya, karena panggilan harus bisa berjalan tanpa izin itu.

Ini menjadi kebocoran jika salah satu alamat itu adalah sesuatu yang Anda sembunyikan. VPN mengubah rute yang diambil permintaan browser Anda, tetapi WebRTC bisa bertanya ke sistem operasi tentang setiap interface, jadi di perangkat yang koneksi fisiknya masih aktif, alamat asli bisa muncul di samping alamat VPN. Tidak ada yang rusak: fitur ini bekerja persis seperti yang dirancang.

Yang bisa dimulai halaman mana punsatu pengumpulan, langkah demi langkah

PERANGKAT ANDAINTERNETRouter Anda (NAT)Script halamanBrowser AndaServer STUNstun.cloudflare.comnew RTCPeerConnection()tanpa permintaan izinmendaftar setiap interface jaringan192.168.1.20 → 8b7f4e2a-….localdari alamat mana Anda melihat saya?192.168.1.20:54400203.0.113.7:54400203.0.113.7:54400alamat yang dilihatnyasetiap kandidat, begitu tibaonicecandidatePERANGKAT ANDAINTERNETScript halamanBrowser AndaServer STUNnew RTCPeerConnection()tanpa permintaan izinmendaftar setiap interface jaringan192.168.1.20 → 8b7f4e2a-….localdari alamat mana Anda melihat saya?192.168.1.20203.0.113.7203.0.113.7:54400alamat yang dilihatnyasetiap kandidat, begitu tibaonicecandidateRouter Anda (NAT)

Script lengkap

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());

Yang dicetaknya

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

Arti setiap baris

  • hostDi perangkat ini8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localDisamarkan browser Anda
  • srflxDilihat server STUN203.0.113.7Bisa dirutekan di internet
Satu pengumpulan di koneksi rumah, dengan alamat dokumentasi. Alamat privat tidak pernah keluar dari browser dalam bentuk aslinya; server STUN melihat sisi publik router, bukan perangkatnya, dan kedua jawaban sampai ke script mana pun yang memintanya.
Hasil tes kebocoran WebRTC: setiap kandidat ICE dengan jenisnya, jenis alamatnya, dan kesimpulannyaHasil tes kebocoran WebRTC: setiap kandidat ICE dengan jenisnya, jenis alamatnya, dan kesimpulannyaKesimpulanBocor, tidak bocor, atau — secara jujur — tidak bisa diuji, beserta alasannya.Setiap alamatDengan jenis kandidatnya, karena kandidat host berarti hal yang berbeda dari kandidat server-reflexive.JenisnyaPrivat, carrier-grade NAT, tunnel, atau bisa dirutekan. Hanya alamat yang bisa dirutekan yang bisa menjadi kebocoran.ServerSetiap server STUN di barisnya sendiri. Server yang diam berarti tes yang tidak berjalan.Yang dilihat situs webAlamat yang tetap dikirim browser Anda, yaitu pembanding alamat-alamat WebRTC.
Contoh tes: jawaban setiap server STUN, setiap alamat yang diungkap WebRTC, jenis alamatnya, dan apakah alamat itu sudah dilihat situs web. Pilih sebuah nomor untuk melihat arti setiap bagian.

Cara cek kebocoran WebRTC

Mulai tes di atas. Tes ini mengumpulkan kandidat dari tiga server STUN, mencari tahu jenis setiap alamat, dan membandingkan alamat yang bisa dirutekan dengan alamat yang sudah dilihat situs web.

Ada tiga hasil yang mungkin, bukan dua. Tidak bocor berarti setiap alamat yang bisa dirutekan dari WebRTC sudah dimiliki situs itu. Bocor berarti setidaknya satu belum dimiliki — atau alamat di perangkat Anda sendiri ditawarkan langsung. Tidak bisa diuji berarti WebRTC dimatikan, diblokir, atau tidak ada server STUN yang menjawab, dan inilah hasil yang diam-diam diubah menjadi lolos oleh kebanyakan alat.

Jalankan dua kali jika Anda memakai VPN: sekali dengan VPN mati untuk melihat alamat biasa Anda, sekali dengan VPN menyala. Tes kedua yang menentukan, dan perbedaan keduanya adalah jawabannya. Halaman ini menyimpan hasil pertama, jadi Anda bisa membandingkan tanpa mencatat apa pun.

Tiga hasil, bukan duaarti masing-masing

  1. Tidak bocor

    Setiap alamat yang bisa dirutekan dari WebRTC sudah dimiliki situs web.

    Dari WebRTC

    • 198.51.100.23Dilihat server STUNSudah dilihat situs web
    • 8b7f4e2a-….localDi perangkat iniDisamarkan browser Anda

    Dilihat situs web

    198.51.100.23
  2. Bocor

    Setidaknya satu alamat belum dimiliki situs itu, atau alamat di perangkat Anda sendiri ditawarkan langsung.

    Dari WebRTC

    • 198.51.100.23Dilihat server STUNSudah dilihat situs web
    • 2001:db8:4a1f:7c00::1cDi perangkat iniTidak dilihat situs web

    Dilihat situs web

    198.51.100.23
  3. Tidak bisa diuji

    WebRTC mati atau diblokir, atau tidak ada server STUN yang menjawab. Tidak ada yang diukur.

    stun.cloudflare.comTidak menjawab

    stun.l.google.comTidak menjawab

    Yang ditampilkan kebanyakan alat di siniTidak bocor

Jalankan dua kali

VPN mati

Dari WebRTC203.0.113.7

Dilihat situs web203.0.113.7

Tidak bocor

VPN menyala

Dari WebRTC198.51.100.23203.0.113.7

Dilihat situs web198.51.100.23

Masih ada saat VPN menyala

Bocor
Setiap hasil dengan tes yang menghasilkannya. Saat VPN mati, alamat WebRTC dan alamat yang dilihat situs web sama; saat VPN menyala, keduanya seharusnya berubah, dan alamat yang tetap ada adalah jawabannya.

Apakah VPN mencegah kebocoran WebRTC?

Tidak dengan sendirinya. VPN mengubah ke mana lalu lintas Anda pergi; WebRTC bisa bertanya ke sistem operasi interface apa saja yang ada, dan interface fisik biasanya masih ada.

Penjelasan IETF sendiri sangat tepat: “jika klien mencoba menyembunyikan lokasi fisiknya melalui Virtual Private Network (VPN), dan VPN serta OS lokal mendukung routing melalui beberapa interface, WebRTC dapat menemukan bukan hanya alamat publik VPN, tetapi juga alamat publik ISP tempat VPN itu berjalan”. Kedua alamat ditawarkan, dan halaman yang mencarinya bisa membaca keduanya.

Sebagian klien VPN menutup celah ini dengan merutekan semua lalu lintas di tingkat sistem operasi, atau dengan menyertakan ekstensi browser yang membatasi WebRTC. Keduanya berhasil, dan keduanya perlu dicek, bukan diasumsikan — untuk itulah halaman ini ada. Halaman leak test milik VPN sendiri yang menyatakan Anda terlindungi bukanlah bukti independen.

VPN menyala, Wi-Fi masih aktifdua interface, dua jawaban

Laptop AndaVPN10.64.0.2Wi-Fi192.168.1.20TUNNEL VPNServer VPN198.51.100.23Situs webbrowsing AndaServer STUNRouter (NAT)Provider Anda203.0.113.7WebRTC bertanya lewat keduanyaLaptop AndaVPN10.64.0.2Wi-Fi192.168.1.20TUNNEL VPNServer VPN198.51.100.23Router (NAT)Provider Anda203.0.113.7browsing AndaSitus webServer STUNWebRTC bertanya lewat keduanya

Yang diterima halaman

  • 198.51.100.23srflxDilihat server STUNlewat VPNSudah dilihat situs web
  • 203.0.113.7srflxDilihat server STUNlewat Wi-Fi, di luar tunnelTidak dilihat situs web

RFC 8828

Yang menutup celah

  • Routing di tingkat sistem operasiTidak ada yang keluar di luar tunnel, jadi server STUN hanya bisa melihat alamat VPN.
  • Ekstensi browser milik VPNEkstensi ini membatasi WebRTC di dalam browser, jadi interface lain tidak pernah ditanyai.
  • Lalu cek, jangan berasumsiJalankan tes ini dengan VPN menyala. Halaman leak test milik VPN sendiri bukan bukti independen.
Kasus yang dijelaskan IETF dalam RFC 8828: VPN dan sistem operasi merutekan lewat lebih dari satu interface, jadi WebRTC menemukan alamat publik VPN dan alamat provider di bawahnya.

Host, server-reflexive, dan relay: kandidat mana yang mana?

Kandidat host adalah alamat di perangkat Anda sendiri. Kandidat server-reflexive adalah yang dilihat server STUN — sisi publik NAT Anda. Kandidat relay adalah alamat server TURN, bukan milik Anda.

Perbedaan ini penting, dan kebanyakan leak test membuangnya. Kandidat server-reflexive yang membawa IPv4 publik Anda biasanya bukan hal baru: itu alamat yang sama yang didapat situs web dari koneksi yang sedang Anda pakai. Kandidat host yang membawa alamat yang bisa dirutekan adalah hal lain — itu alamat di perangkat itu sendiri, ditawarkan langsung ke halaman. Alamat itu mengenali perangkat ini, bukan sekadar router rumah Anda, dan berubah saat jaringannya berubah.

Halaman ini menampilkan jenisnya di samping setiap alamat, beserta transpor, port, dan alamat terkait yang disebut kandidat server-reflexive. Kandidat relay adalah alamat server TURN itu sendiri dan tidak mengungkap apa pun tentang Anda; tes ini tidak memakai server TURN, jadi jika kandidat seperti itu muncul, berarti ada hal lain di halaman yang mengaturnya.

Satu kandidat, field demi fieldseperti yang diterima halaman

  1. candidate:1467250027Fondasi
  2. 1Komponen
  3. udpTranspor
  4. 1686052607Prioritas
  5. 203.0.113.7Alamat
  6. 54400Port
  7. typ srflxJenis
  8. raddr 0.0.0.0 rport 9Alamat terkait
  9. generation 0Ekstensi

Dikosongkan menjadi 0.0.0.0, port 9, jika alamat lokal disamarkan

Empat jenis

  • typ hostDi perangkat ini

    Alamat di salah satu interface jaringan Anda sendiri.

    Yang privat disamarkan. Yang bisa dirutekan adalah perangkat itu sendiri: temuan paling serius.

    Paling serius jika bisa dirutekan

  • typ srflxDilihat server STUN

    Sisi publik router Anda, seperti yang dilihat server STUN.

    Biasanya alamat yang sudah didapat situs web dari koneksi Anda.

    Biasanya bukan hal baru

  • typ prflxDilihat pihak lain

    Sisi publik router Anda, seperti yang dilihat pihak lain dalam panggilan.

    Hanya ditemukan saat tersambung ke pihak lain, jadi tes tanpa panggilan tidak pernah melihatnya.

    Hanya saat panggilan

  • typ relayAlamat server relay itu sendiri

    Alamat server TURN, yang meneruskan lalu lintas untuk Anda.

    Alamat server, bukan alamat Anda. Tes ini tidak memakai server TURN, jadi kandidat seperti ini diatur oleh hal lain.

    Tidak ada tentang Anda

Alamat kandidat dibandingkan dengan yang dilihat situs web; jenisnya menunjukkan seberapa serius perbedaannya. Definisi dari RFC 8445, bagian 4.

Apa itu alamat mDNS .local, dan apakah alamat itu melindungi saya?

Browser modern mengganti alamat privat Anda dengan nama acak berakhiran .local sebelum menawarkannya ke halaman. Cara ini berhasil — untuk alamat privat. Cara ini memang tidak pernah dimaksudkan untuk menyembunyikan alamat publik.

Chrome melakukannya secara default sejak versi 76 dan Firefox menyetel media.peerconnection.ice.obfuscate_host_addresses ke true: alih-alih 192.168.1.20, halaman mendapat sesuatu seperti 8b7f4e2a-….local, yang tidak berarti apa-apa bagi siapa pun di luar jaringan Anda. Safari melangkah lebih jauh: selama sebuah situs belum punya izin kamera atau mikrofon, Safari sama sekali tidak menawarkan kandidat host. Tes di atas mengenali nama-nama .local itu dan melaporkannya sebagai perlindungan yang bekerja, bukan sebagai temuan.

Draft IETF yang mendefinisikannya tegas soal apa yang tidak dilakukannya: “alamat yang sudah terekspos ke internet tidak perlu dilindungi oleh mDNS, karena alamat itu bisa dengan mudah diamati oleh server web”. Jadi kandidat server-reflexive tetap membawa IPv4 publik Anda, dan — bagian yang mengejutkan banyak orang — perangkat dengan alamat IPv6 yang bisa dirutekan tetap bisa menawarkan alamat itu sebagai kandidat host. Ada satu celah lagi yang perlu diketahui: Chrome mematikan perlindungan ini untuk situs mana pun yang sudah punya izin kamera atau mikrofon, jadi situs panggilan video yang pernah Anda pakai melihat alamat lokal asli Anda.

Yang digantikan nama .localdan yang dibiarkannya

Yang dimiliki browser Anda

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

Yang didapat halaman

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

Yang dilakukan setiap browser secara default

  • ChromeVersi 76, Agustus 2019
  • Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
  • SafariTanpa kandidat host sampai situs punya izin kamera atau mikrofon

Mekanisme ini adalah draft IETF, terakhir direvisi pada Desember 2021 dan tidak pernah diterbitkan sebagai RFC. draft-ietf-mmusic-mdns-ice-candidates-03

Alamat yang bisa ditawarkan WebRTCDisamarkan?
192.168.1.20IPv4 privat Anda, sebagai kandidat hostDisamarkanDiganti dengan nama acak: halaman tidak tahu apa pun tentang jaringan Anda.
203.0.113.7IPv4 publik Anda, sebagai kandidat dari server STUNDitampilkanSudah publik, jadi tetap ada. Hanya alamat terkaitnya yang dikosongkan.
2001:db8:4a1f:7c00::1cIPv6 yang bisa dirutekan, sebagai kandidat hostDitampilkanJuga publik, jadi penyamaran memang tidak pernah dimaksudkan untuk menutupinya.
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Alamat IPv6 sementaraBisa ditampilkanDraft-nya membolehkan browser membiarkannya tanpa penyamaran, atas pilihannya.
192.168.1.20Alamat lokal apa pun, di situs dengan izin kamera atau mikrofonPenyamaran matiChrome mematikan penyamaran di sana: situs itu melihat alamat lokal asli Anda.
Penyamaran menyembunyikan apa yang hanya diketahui jaringan Anda sendiri. Apa yang memang bisa dilihat situs web, dibiarkannya apa adanya: memang dirancang begitu, bukan kesalahan.

Mengapa IPv6 adalah kebocoran yang tersisa

Alamat IPv6 global milik satu perangkat, bukan milik satu rumah di balik NAT, dan mDNS sengaja membiarkannya. Inilah hal paling mengidentifikasi yang masih diberikan WebRTC.

Di IPv4, NAT router rumah Anda menempatkan semuanya di balik satu alamat, jadi kandidat server-reflexive memberi tahu halaman kurang lebih hal yang sudah diberitahukan koneksi biasa Anda. IPv6 tidak memakai NAT: setiap perangkat punya alamat sendiri yang bisa dirutekan, dan kandidat host yang membawanya menyebut perangkat itu, bukan jalurnya. Jika VPN Anda hanya membawa IPv4 — banyak yang begitu — alamat IPv6 itu juga sepenuhnya berada di luar tunnel.

Privacy extensions membantu, karena alamat IPv6 sementara berganti-ganti. Namun, fitur itu tidak menyembunyikannya: draft mDNS menyatakan alamat seperti itu boleh dibiarkan tanpa penyamaran. Tes di atas menandai kandidat host IPv6 yang bisa dirutekan sebagai temuan paling serius yang bisa ditemukannya, dan Tes IPv6 akan memberi tahu apakah koneksi Anda punya IPv6 sama sekali.

Siapa yang disebut sebuah alamattiga perangkat yang sama, dua kali

RouterIPv4, di balik NATIPv6, tanpa NAT
Laptop192.168.1.202001:db8:4a1f:7c00::1c
Ponsel192.168.1.212001:db8:4a1f:7c00::2b
TV192.168.1.222001:db8:4a1f:7c00::3d
Router203.0.113.7Satu alamat untuk seluruh jalurSatu alamat per perangkat

Alamat IPv6 global, dalam dua bagian

2001:db8:4a1f:7c00Prefiks jaringan: jalur Anda /64:8d3:5e2f:a41c:9b07Interface ID: perangkat ini

  • Stabil2001:db8:4a1f:7c00::1c
  • Sementara: berganti2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

VPN yang hanya membawa IPv4

  • IPv4198.51.100.23Di dalam tunnel
  • IPv62001:db8:4a1f:7c00::1cDi luar tunnel
Di balik NAT IPv4, satu rumah berbagi satu alamat; di IPv6 setiap perangkat punya alamatnya sendiri, dan kandidat host menawarkannya langsung. Tes ini menganggap kandidat host IPv6 yang bisa dirutekan sebagai temuan paling serius.

Cara menghentikan kebocoran WebRTC di setiap browser

Firefox punya preferensi yang berfungsi. Edge punya kebijakan enterprise. Safari sudah membatasi kandidat. Ekstensi browser yang masih banyak direkomendasikan tidak lagi melakukan apa pun.

Di Firefox, about:config → media.peerconnection.ice.default_address_only hanya mengirim satu alamat, bukan semuanya, dan media.peerconnection.ice.relay_only membatasi pengumpulan pada kandidat relay, yang merusak panggilan langsung tetapi menyembunyikan semua yang lain. Keduanya mati secara default; penyamaran mDNS untuk alamat privat (media.peerconnection.ice.obfuscate_host_addresses) sudah aktif. Di Edge, kebijakan WebRtcLocalIpsAllowedUrls mengatur situs mana yang boleh melihat alamat lokal; dokumentasi Microsoft sendiri mencatat bahwa menambahkan situs “melemahkan perlindungan”. Chrome tidak punya setelan serupa untuk pengguna biasa. Safari yang paling ketat tanpa perlu diminta: tanpa izin kamera atau mikrofon, WebKit hanya menawarkan kandidat server-reflexive dan relay, sama sekali tanpa kandidat host.

Dua hal yang masih banyak direkomendasikan sudah mati. Opsi uBlock Origin “Cegah WebRTC membocorkan alamat IP lokal” dihapus di versi 1.38, dengan catatan bahwa opsi itu “tidak lagi diperlukan di browser modern, kecuali Firefox untuk Android”. Dan ekstensi WebRTC Network Limiter dari Google, yang masih ada di toko, tidak bisa berjalan: ekstensi Manifest V2 dinonaktifkan untuk semua pengguna Chrome sejak Chrome 138 pada Juli 2025. Jika sebuah halaman menyuruh Anda memasang salah satunya, halaman itu sudah bertahun-tahun tidak diperbarui.

Yang ditawarkan setiap browserdicek dengan dokumentasi masing-masing vendor

  • FirefoxPreferensi yang berfungsi

    about:config

    • media.peerconnection.ice.obfuscate_host_addressesBawaan trueMenyamarkan alamat privat. Sudah aktif.
    • media.peerconnection.ice.default_address_onlyBawaan falseSetel ke trueMengirim satu alamat, bukan semuanya.
    • media.peerconnection.ice.relay_onlyBawaan falseSetel ke trueHanya kandidat relay. Paling banyak menyembunyikan, dan merusak panggilan langsung.

  • EdgeKebijakan enterprise

    WebRtcLocalIpsAllowedUrls

    Mencantumkan situs yang boleh melihat alamat lokal.

    Tidak dikonfigurasi: alamat lokal tetap disamarkan.

    Catatan Microsoft sendiri: menambahkan situs melemahkan perlindungan.

    Windows dan macOS, versi 80 dan yang lebih baru

  • ChromeTanpa setelan

    Tidak ada setelan untuk pengguna biasa.

    Alamat privat disamarkan secara default sejak versi 76.

    Tidak di situs dengan izin kamera atau mikrofon.

  • SafariKetat secara default

    Tanpa izin kamera atau mikrofon, hanya kandidat server STUN dan relay.

    Sama sekali tanpa kandidat host.

Saran yang tidak lagi berfungsi

  • Prevent WebRTC from leaking local IP addresses

    uBlock Origin

    Dihapus di versi 1.38

    Tidak lagi diperlukan di browser modern, kata uBlock Origin, kecuali Firefox untuk Android.

  • WebRTC Network Limiter

    Google · Chrome Web Store

    Masih terdaftar, tidak bisa berjalan

    Ekstensi Manifest V2 dinonaktifkan untuk semua pengguna Chrome sejak Chrome 138, Juli 2025.

Dokumentasi masing-masing vendor, dibaca pada hari halaman ini dicek. Halaman yang masih menyuruh Anda memasang salah satu dari dua yang terakhir sudah bertahun-tahun tidak diperbarui.

Kebocoran WebRTC, kebocoran DNS, dan kebocoran IP: apa bedanya?

Ketiganya cara berbeda untuk melewati VPN. Kebocoran WebRTC menampilkan alamat; kebocoran DNS menampilkan siapa yang menjawab lookup Anda; kebocoran IP adalah kasus sederhana ketika lalu lintas Anda tidak pernah masuk ke tunnel.

Kebocoran WebRTC menyangkut alamat yang diberikan browser Anda secara sukarela lewat fitur yang memang dirancang untuk itu. Kebocoran DNS menyangkut resolver mana yang menjawab lookup Anda: lalu lintas Anda bisa melewati VPN sementara lookup Anda tetap pergi ke resolver provider Anda, yang memberi tahu provider itu setiap situs yang Anda kunjungi. Tes Kebocoran DNS kami mengeceknya dengan nameserver kami sendiri, jadi tes itu bisa melihat persis resolver mana yang bertanya.

Kebocoran IP dalam arti umum adalah alamat yang langsung dilihat situs web, yang bisa Anda cek di IP Saya Apa atau ISP Saya Apa. Jalankan ketiganya bersama setelah setiap perubahan VPN: ketiganya bisa gagal secara terpisah, dan hasil bersih di satu tes tidak mengatakan apa pun tentang yang lain.

Tiga jalan memutari VPNmasing-masing gagal sendiri-sendiri

AndaTUNNEL VPNLewat tunnelKebocoran IP · lalu lintas AndaSitus web203.0.113.7Kebocoran DNS · lookup AndaResolver provider Anda203.0.113.53Kebocoran WebRTC · alamat AndaScript halaman203.0.113.7AndaTUNNEL VPNLewat tunnelKebocoran IPlalu lintas AndaSitus web203.0.113.7Kebocoran DNSlookup AndaResolver provider Anda203.0.113.53Kebocoran WebRTCalamat AndaScript halaman203.0.113.7

  • Kebocoran IP

    Yang bocorAlamat yang dibawa setiap permintaan

    Siapa yang mengetahuinyaSetiap situs yang Anda kunjungi

    Cek denganIP Saya ApaISP Saya Apa

  • Kebocoran DNS

    Yang bocorResolver mana yang menjawab lookup Anda

    Siapa yang mengetahuinyaProvider Anda, untuk setiap situs yang Anda cari

    Cek denganTes Kebocoran DNS

  • Kebocoran WebRTC

    Yang bocorAlamat yang ditawarkan browser Anda ke halaman

    Siapa yang mengetahuinyaHalaman mana pun yang bertanya, tanpa permintaan izin

    Cek denganTes Kebocoran WebRTC

Ketiganya gagal secara terpisah: hasil bersih di satu tes tidak mengatakan apa pun tentang dua lainnya. Jalankan ketiganya setelah setiap perubahan pada VPN Anda.

Mengapa tes ini bertanya ke lebih dari satu server STUN

Karena “tidak ada alamat yang kembali” dan “tidak ada alamat” terlihat sama, dan hanya salah satunya kabar baik.

Firewall kantor, VPN yang membatasi, atau jaringan yang memblokir UDP bisa membuat server STUN tidak menjawab. Tes yang bertanya ke satu vendor dan tidak melihat apa pun tidak mengetahui apa pun — tetapi biasanya yang ditampilkan justru centang hijau. Tes ini bertanya ke endpoint STUN Cloudflare yang terdokumentasi dan ke server Google, melaporkan masing-masing secara terpisah, dan menyatakan tidak bisa diuji jika tidak ada satu pun yang menjawab.

Pilihan servernya disengaja. Cloudflare memublikasikan stun.cloudflare.com:3478 sebagai bagian dari sebuah produk, jadi ada ketentuan yang bisa dibaca. stun.l.google.com:19302 milik Google hanya didokumentasikan sebagai default validator WebRTC milik Google sendiri, tanpa ketentuan yang dipublikasikan, jadi server itu dipakai sebagai pendapat kedua, bukan satu-satunya sumber. Server Twilio membutuhkan kredensial, dan Mozilla tidak mendokumentasikan server STUN publik apa pun, meski sering disebut-sebut.

Server STUN publikdan mana yang ditanyai tes ini

  • CloudflareDitanyai

    stun.cloudflare.com:3478

    Endpoint yang terdokumentasi, bagian dari sebuah produk, dengan ketentuan yang bisa dibaca.

  • GoogleDitanyai, sebagai pendapat kedua

    stun.l.google.com:19302

    Hanya didokumentasikan sebagai default validator WebRTC milik Google sendiri. Tanpa ketentuan yang dipublikasikan.

  • TwilioTidak ditanyai

    global.stun.twilio.com:3478

    Membutuhkan kredensial dari API Twilio: tidak terbuka untuk setiap halaman.

  • MozillaTidak ditanyai

    Tidak ada server publik

    Tidak mendokumentasikan server STUN publik apa pun. Firefox sama sekali tidak menyertakan server ICE default.

Saat sebuah server diam

CloudflareGoogle
MenjawabMenjawabHasilnya tetap berlaku
MenjawabDiamHasilnya tetap berlaku; server yang diam disebutkan
DiamMenjawabHasilnya tetap berlaku; server yang diam disebutkan
DiamDiamTidak bisa diuji
Dua operator, ditanyai secara terpisah. Satu server yang diam disebutkan dan hasilnya tetap berlaku; jika tidak ada satu pun yang menjawab, tidak ada yang diukur, dan tes ini menyatakannya alih-alih menampilkan lolos.

Apakah alamat IP saya termasuk data pribadi?

Di Uni Eropa, alamat IP dinamis adalah data pribadi bagi operator situs web yang bisa mengidentifikasi Anda dengan informasi yang dipegang provider. Pengadilan Kehakiman Uni Eropa memutuskannya pada 2016.

Perkaranya adalah Breyer, C-582/14, yang diputus pada 19 Oktober 2016, dan siaran pers Pengadilan merangkumnya: “alamat protokol internet dinamis milik pengunjung merupakan data pribadi bagi operator situs web, jika operator itu memiliki sarana hukum yang memungkinkannya mengidentifikasi pengunjung tersebut dengan informasi tambahan tentang dirinya yang dipegang oleh penyedia akses internet”. Siaran pers yang sama mencatat bahwa sebuah situs bisa memiliki kepentingan yang sah untuk menyimpan sebagian data itu demi melindungi diri dari serangan.

Itulah alasan utama halaman ini bekerja di browser Anda. Kandidat ICE dikumpulkan oleh browser Anda, dibandingkan di browser Anda, dan ditampilkan kepada Anda; tidak ada alamat temuan WebRTC yang dikirim ke kami, jadi tidak ada yang bisa kami simpan, serahkan, atau hilangkan. Anda bisa memantau tab Network di developer tools selama tes berjalan.

Putusan BreyerPengadilan Kehakiman Uni Eropa

C-582/14Breyer v Bundesrepublik Deutschland19 Oktober 2016

  1. Operator situs websebuah alamat dan waktu, dari log-nya203.0.113.7 · 14:02:37
  2. sarana hukum untuk mendapatkannya
  3. Penyedia akses internetsiapa yang memakai alamat itu pada waktu itu203.0.113.7 · 14:02:37 →
  4. Data pribadi, bagi operator itu

Siaran pers Pengadilan: sebuah situs bisa memiliki kepentingan yang sah untuk menyimpan sebagian data itu demi melindungi diri dari serangan.

Di halaman ini

Browser Anda

  1. Mengumpulkan
  2. Mengelompokkan
  3. Membandingkan
  4. Menampilkan
  • Melihat alamat publik Anda, seperti di setiap panggilan
  • dnsrobot.netTidak ada kandidat yang dikirim
Perkara C-582/14, Breyer. Alamat IP dinamis adalah data pribadi bagi operator situs web yang memiliki sarana hukum untuk mengidentifikasi Anda dengan catatan provider. Halaman ini menyimpan kandidat di browser Anda.

Tes kebocoran WebRTC: tanya jawab

Apa itu kebocoran WebRTC?

WebRTC adalah fitur browser di balik panggilan video. Untuk menghubungkan dua orang secara langsung, WebRTC mengumpulkan setiap alamat tempat perangkat Anda bisa dijangkau dan menawarkannya ke halaman, tanpa permintaan izin. Ini menjadi kebocoran jika salah satu alamat itu adalah alamat yang Anda sembunyikan — biasanya alamat asli Anda saat VPN menyala, karena WebRTC bisa bertanya tentang setiap interface jaringan, bukan hanya interface yang dipakai untuk menjelajah.

Bagaimana cara cek kebocoran WebRTC?

Mulai tes di halaman ini. Tes ini bertanya ke tiga server STUN dari dua operator, mencantumkan setiap alamat yang dihasilkan WebRTC beserta jenisnya, dan membandingkan alamat yang bisa dirutekan dengan alamat yang sudah dilihat situs web. Jika Anda memakai VPN, jalankan sekali dengan VPN mati dan sekali dengan VPN menyala: perbedaan kedua tes itulah jawabannya.

Apakah VPN mencegah kebocoran WebRTC?

Tidak dengan sendirinya. VPN mengubah ke mana lalu lintas Anda pergi, tetapi WebRTC bisa bertanya ke sistem operasi interface apa saja yang ada, dan koneksi fisik biasanya masih salah satunya. Teks IETF sendiri menyatakan WebRTC dapat menemukan “bukan hanya alamat publik VPN, tetapi juga alamat publik ISP tempat VPN itu berjalan”. Sebagian klien VPN menutup celah ini; tes ini memberi tahu apakah VPN Anda melakukannya.

Apa arti alamat .local di hasil tes?

Itu mDNS, dan itu kabar baik. Browser modern mengganti alamat privat Anda dengan nama acak berakhiran .local sebelum menawarkannya ke halaman, jadi situs web tidak mengetahui apa pun tentang jaringan rumah Anda dari alamat-alamat itu. Chrome melakukannya sejak versi 76 dan Firefox melakukan hal yang sama; Safari melangkah lebih jauh dan sama sekali tidak menawarkan kandidat host sampai sebuah situs punya izin kamera atau mikrofon. Tes ini menandainya sebagai perlindungan yang bekerja, bukan sebagai temuan.

Jika mDNS menyembunyikan IP lokal saya, apakah saya aman?

Sebagian. mDNS dirancang untuk menyembunyikan alamat privat dan secara tegas tidak untuk menyembunyikan alamat yang sudah publik — draft IETF yang mendefinisikannya menyatakan begitu. IPv4 publik Anda tetap muncul sebagai kandidat server-reflexive, dan perangkat dengan alamat IPv6 yang bisa dirutekan tetap bisa menawarkan alamat itu secara langsung. Chrome juga mematikan perlindungan ini untuk situs mana pun yang sudah memegang izin kamera atau mikrofon.

Mengapa tes kadang menyatakan tidak bisa diuji?

Karena itulah kenyataannya. Jika WebRTC dimatikan, diblokir oleh ekstensi atau kebijakan, atau tidak ada server STUN yang menjawab — karena firewall, VPN yang membatasi, atau jaringan yang memblokir UDP — maka tidak ada yang diukur. Kebanyakan alat menampilkan centang hijau dalam situasi itu, hal paling menyesatkan yang bisa dilakukan sebuah leak test. Tes ini menyatakan apa yang terjadi dan menyebut server mana yang diam.

Bagaimana cara menonaktifkan WebRTC di Firefox?

Preferensi Firefox yang terdokumentasi membatasi WebRTC, bukan mematikannya. Di about:config, media.peerconnection.ice.default_address_only mengirim satu alamat, bukan semuanya, dan media.peerconnection.ice.relay_only membatasi pengumpulan pada kandidat relay: itu menyembunyikan paling banyak, tetapi merusak panggilan langsung. Penyamaran alamat privat, media.peerconnection.ice.obfuscate_host_addresses, sudah aktif secara default. Jalankan tes lagi setelah setiap perubahan untuk melihat apa yang Anda dapatkan.

Bagaimana cara menghentikan kebocoran WebRTC di Chrome?

Chrome tidak memberi pengguna biasa setelan untuk itu; penyamaran mDNS untuk alamat privat aktif secara default, dan itulah perlindungan yang Anda dapat. Edge, yang memakai mesin yang sama dengan Chrome, punya kebijakan enterprise WebRtcLocalIpsAllowedUrls. Ekstensi yang masih banyak direkomendasikan tidak berfungsi: uBlock Origin menghapus opsi WebRTC-nya di versi 1.38, dan WebRTC Network Limiter dari Google tidak bisa berjalan sejak Manifest V2 dinonaktifkan di Chrome 138.

Apa bedanya kandidat host dan kandidat server-reflexive?

Kandidat host adalah alamat di perangkat Anda sendiri. Kandidat server-reflexive adalah yang dilihat server STUN — sisi publik NAT Anda, yang biasanya adalah alamat yang sudah didapat situs web dari koneksi Anda. Kandidat host yang bisa dirutekan adalah temuan yang lebih serius, karena itu alamat di perangkat itu sendiri, dan di IPv6 alamat itu mengidentifikasi perangkat, bukan satu rumah.

Apakah kebocoran WebRTC sama dengan kebocoran DNS?

Tidak. Kebocoran WebRTC mengungkap sebuah alamat; kebocoran DNS mengungkap resolver mana yang menjawab lookup Anda, yang memberi tahu provider Anda setiap situs yang Anda kunjungi meski lalu lintasnya sendiri melewati VPN. Keduanya gagal secara terpisah, jadi hasil bersih di satu tes tidak mengatakan apa pun tentang yang lain. Jalankan juga Tes Kebocoran DNS kami setelah setiap perubahan VPN.

Apakah tes ini mengirim alamat IP saya ke mana pun?

Hanya sebagaimana situs web mana pun melihatnya. Browser Anda menghubungi server STUN, seperti yang dilakukan setiap panggilan video: itulah tesnya. Untuk mengetahui apa yang dilihat situs web, halaman ini menanyakan alamat Anda beserta jaringannya ke ipify.org dan ke server kami sendiri, seperti yang dilakukan Tes Kebocoran DNS. Alamat yang ditemukan WebRTC tetap berada di browser Anda: tidak ada satu pun yang dikirim ke kami. Pantau tab Network di developer tools selama tes berjalan.

Apakah alamat IP saya termasuk data pribadi menurut hukum Uni Eropa?

Bagi operator situs web di Uni Eropa, alamat IP dinamis adalah data pribadi jika operator itu memiliki sarana yang sah untuk mengidentifikasi Anda dengan informasi yang dipegang provider internet. Itulah putusan Pengadilan Kehakiman Uni Eropa dalam perkara Breyer, C-582/14, pada Oktober 2016. Ini salah satu alasan halaman ini menjalankan bagian WebRTC dari tes ini di browser Anda, bukan di server kami.

Ada yang kurang?Usulkan fitur atau alat baru

Alat terkait