Apa itu kebocoran WebRTC
WebRTC adalah kemampuan komunikasi real-time bawaan browser, dipakai untuk konferensi video, panggilan suara, transfer file P2P, dan skenario serupa. Untuk membangun koneksi peer-to-peer, browser menemukan alamat publiknya sendiri lewat server STUN. Pemeriksaan ini biasanya memakai UDP, dan proxy HTTP / SOCKS biasa belum tentu mencegat UDP.
Jika permintaan STUN melewati proxy dan keluar langsung dari jaringan lokal, skrip web bisa mendapatkan IP publik asli Anda. Proses ini biasanya tidak membutuhkan izin kamera atau mikrofon dan tidak memunculkan konfirmasi tambahan, itulah sebabnya sering dipakai untuk memeriksa apakah proxy benar-benar mencakup trafik komunikasi real-time.
Cara alat ini mendeteksinya
Halaman ini mencoba probe WebRTC ke beberapa server STUN, mengumpulkan alamat publik yang dikembalikan, lalu membandingkannya dengan IP egress HTTP. Jika alamat yang dikembalikan sama dengan egress saat ini, jalur UDP kemungkinan besar ditangani proxy; jika yang muncul adalah alamat operator lokal, itu perlu diselidiki.
- Memastikan apakah UDP lewat egress proxy
- Mendeteksi apakah IPv4 / IPv6 masing-masing bocor secara independen
- Mengamati apakah target STUN yang berbeda terkena aturan routing yang berbeda
Peran STUN dan UDP
UDP adalah protokol transport tanpa koneksi yang umum dipakai untuk suara, video, game, dan komunikasi real-time. Tugas STUN sederhana: Anda mengirim paket UDP ke server, lalu server memberi tahu IP sumber yang dilihatnya. WebRTC bergantung pada hasil ini untuk bernegosiasi koneksi, sehingga alamat yang dilihat STUN adalah bukti kunci untuk menilai kebocoran.
Cara membaca hasil
Tidak ada kebocoranIP publik yang dikembalikan WebRTC sama dengan egress proxy Anda saat ini (untuk IPv6, /64 yang sama). Jika tidak ada IP publik yang kembali sama sekali, berarti tes tidak mendapat jawaban; itu bukan bukti aman.
Dicurigai bocorWebRTC mengembalikan IP publik yang berbeda, dan lokasi, operator, atau ASN-nya mengarah ke jaringan lokal asli Anda.
Pemisahan trafik yang normalBeberapa server STUN mengembalikan egress proxy yang berbeda, tetapi egress tersebut sesuai dengan routing atau aturan yang Anda konfigurasi.
Yang harus dilakukan setelah menemukan kebocoran
- Alihkan klien proxy Anda ke mode TUN agar UDP WebRTC juga lewat exit proxy.
- Chrome / Edge: atur kebijakan enterprise <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code>; Firefox: aktifkan <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> di <code>about:config</code>. Jangan menghapus WebRTC sepenuhnya, karena browser tanpa WebRTC justru mudah dikenali.
- Brave: atur kebijakan penanganan IP WebRTC ke "Disable non-proxied UDP".
- Jika Anda butuh konferensi atau panggilan suara, perbaiki dulu aturan routing UDP / STUN di klien proxy Anda.
Banyak IP egress belum tentu kebocoran
Jika Anda mengatur pemisahan trafik, server STUN yang berbeda bisa lewat node yang berbeda — misalnya STUN Google lewat egress Amerika Serikat, STUN Cloudflare lewat egress Hong Kong. Ini belum tentu berbahaya; yang penting adalah apakah sesuai dengan rancangan aturan Anda. Yang benar-benar perlu diwaspadai adalah ketika semua alamat WebRTC mengarah ke lokasi fisik atau ISP lokal Anda.
Kebocoran DNS sama pentingnya
Kebocoran WebRTC membuka "IP asli Anda"; kebocoran DNS membuka "domain apa saja yang Anda kueri". Jika permintaan DNS tidak lewat proxy, operator lokal atau resolver upstream Anda tetap bisa melihat situs mana yang Anda kunjungi.
Deteksi kebocoran DNS di halaman ini memakai probe sungguhan: CleanIP.io menjalankan masing-masing satu NS otoritatif di Utah, Amerika Serikat (ns1) dan Los Angeles, Amerika Serikat (ns2), yang melayani zona dp.cleanip.io. Setiap deteksi me-resolve 8 subdomain <uuid>.dp.cleanip.io yang independen; kueri ini melewati stub resolver sistem Anda -> ISP / VPN / resolver rekursif publik, dan akhirnya sampai di NS otoritatif kami, yang mencatat IP resolver penanya dan (jika ada) EDNS Client Subnet, lalu mengembalikannya kepada Anda untuk dibandingkan.
Perhatikan dua sinyal: ① Subnet ECS — jika resolver rekursif meneruskan subnet klien Anda (umum pada Google 8.8.8.8), subnet itu adalah bukti pasti identitas klien Anda; ② Negara resolver — anycast lintas negara untuk resolver rekursif publik (1.1.1.1 / 8.8.8.8) itu normal; yang penting adalah apakah, saat Anda mengira VPN sedang aktif, lokasi resolver cocok dengan negara egress HTTP Anda.
Mengapa mode proxy dan mode TUN memberi hasil berbeda
Proxy HTTP / SOCKS biasanya hanya menangani TCP, sehingga UDP yang dibutuhkan STUN bisa gagal terkirim, dan halaman mungkin menampilkan "tidak ada kebocoran". Itu tidak berarti UDP sudah diproksikan dengan aman — hanya berarti UDP tidak pernah sampai ke server STUN. Mode TUN mencegat TCP dan UDP di adaptor jaringan virtual, sehingga lebih mencerminkan jalur egress UDP yang sebenarnya.
ModeSTUN UDPArti hasil
Proxy HTTP / SOCKSBisa gagal terkirim"Tidak ada kebocoran" bisa jadi hanya karena UDP diblokir
TUN / adaptor virtualBenar-benar bisa terkirimLebih cocok untuk memverifikasi egress UDP dan aturan routing
Kami menyarankan tes ulang dengan mode jaringan yang benar-benar Anda pakai: jika biasanya memakai TUN, tes dengan TUN; jika mengandalkan proxy browser, pastikan juga UDP yang diblokir tidak salah dinilai sebagai aman. Saat menilai kebocoran WebRTC, fokuslah pada ASN, lokasi, dan apakah IP yang dikembalikan sesuai dengan pemisahan trafik yang Anda harapkan.