Apa yang harus dilakukan jika browser anti deteksi menunjukkan kebocoran WebRTC? Panduan deteksi dan perbaikan MostLogin

Ringkasan konten: Ketika pemeriksaan bisnis Anda menunjukkan WebRTC bocor, Anda harus segera menghentikan login atau pengoperasian akun penting, menutup lingkungan saat ini, kemudian memeriksa koneksi proxy, mode WebRTC, IPv6, dan aturan bypass proxy. Bagi pengguna MostLogin, penanganan umum adalah: pastikan deteksi proxy berhasil, atur WebRTC lingkungan ke Private (Privasi); jika bisnis tidak memerlukan audio/video web atau komunikasi peer-to-peer sama sekali, Anda juga dapat memilih Disabled (Nonaktif); sekaligus aktifkan aturan perlindungan untuk mencegah pembukaan lingkungan saat proxy gagal.

Perlu diperhatikan, munculnya beberapa alamat di halaman tes belum tentu berarti kebocoran. Kebocoran baru terjadi ketika halaman mengekspos IPv4 publik asli Anda, IPv6 publik asli Anda, atau muncul jalur keluar jaringan yang seharusnya tidak terkait dengan lingkungan tersebut — ini adalah masalah berisiko tinggi yang harus segera ditangani.

Apa itu WebRTC? Mengapa bisa melewati pengaturan proxy biasa?

WebRTC adalah singkatan dari Web Real-Time Communication, yaitu "komunikasi real-time web". Teknologi ini memungkinkan browser untuk melakukan panggilan suara, konferensi video, berbagi layar, dan transfer data peer-to-peer secara langsung. Banyak alat konferensi online, panggilan layanan pelanggan, dan kolaborasi yang menggunakannya.

Untuk menemukan jalur koneksi yang tersedia antara dua perangkat, WebRTC mengumpulkan beberapa "kandidat alamat" melalui ICE. Kandidat ini mungkin mencakup alamat antarmuka jaringan perangkat, alamat pemetaan publik yang ditemukan melalui server STUN, dan alamat yang direlai melalui server TURN. Penjelasan MDN tentang tipe kandidat ICE menunjukkan bahwa kandidat host mewakili alamat langsung perangkat, kandidat srflx dihasilkan oleh interaksi STUN/TURN, dan kandidat relay melalui relai TURN. Penjelasan konektivitas WebRTC MDN

Inilah akar penyebab kebocoran WebRTC: halaman web membuat koneksi WebRTC melalui JavaScript dan membaca kandidat ICE. Jika browser tidak membatasi alamat-alamat ini dengan benar, informasi jaringan yang dilihat halaman web bisa tidak konsisten dengan keluaran proxy. MDN juga menjelaskan dengan jelas bahwa alamat kandidat ICE dapat membocorkan informasi lokasi perangkat dan topologi jaringan melebihi yang diharapkan pengguna, dan dapat digunakan untuk identifikasi sidik jari browser. Catatan keamanan RTCIceCandidate MDN

Pemahaman sederhana: Permintaan halaman web biasa mungkin melalui proxy, tetapi WebRTC juga secara terpisah mencari jalur komunikasi real-time. Ketika dua jalur ini tidak dikendalikan secara terpadu, situs web bisa melihat "IP proxy" dan "sekumpulan alamat jaringan lain" secara bersamaan.

Apa yang dianggap sebagai kebocoran WebRTC?

Menilai kebocoran tidak hanya melihat apakah halaman tes menampilkan IP, melainkan membandingkan "apa yang ditampilkan halaman" dengan "apa yang seharusnya ditampilkan oleh lingkungan".

Browser modern mungkin menggunakan nama host mDNS sebagai pengganti IP LAN, sehingga hasil di halaman tes yang berupa string acak diakhiri .local tidak berarti mengekspos IP publik asli. Yang benar-benar perlu diperhatikan adalah: apakah muncul alamat ISP publik asli yang Anda temukan di luar lingkungan browser.

Apa konsekuensi kebocoran WebRTC?

1. Konflik antara identitas proxy dan identitas jaringan asli

Misalnya, lingkungan MostLogin dikonfigurasi dengan proxy New York, Amerika Serikat, dan permintaan halaman web juga menampilkan IP New York, tetapi WebRTC justru mengekspos IP publik jaringan lokal pengguna. Platform tidak melihat lingkungan browsing yang natural dan stabil, melainkan dua sinyal koneksi yang saling bertentangan dari lokasi geografis atau operator jaringan yang berbeda.

Ini tidak secara otomatis membuktikan siapa penggunanya, tetapi melemahkan efek isolasi proxy dan bisa menjadi salah satu sinyal untuk pengendalian risiko anomali, verifikasi tambahan, atau peninjauan sesi.

2. Berbagai lingkungan browser bisa dikaitkan oleh IP asli yang sama

Tim membuat beberapa lingkungan independen untuk proyek pengujian yang berbeda, masing-masing menggunakan proxy berbeda. Jika semua lingkungan ini mengekspos IP publik kantor yang sama melalui WebRTC, situs web bisa mendapatkan sinyal korelasi yang berulang lintas lingkungan. Meskipun Cookie, Canvas, dan WebGL masing-masing terisolasi, keluarnya jalur jaringan asli yang berulang tetap mengurangi independensi antar lingkungan.

3. Membocorkan perkiraan lokasi, operator jaringan, dan struktur jaringan

IP publik biasanya dapat digunakan untuk menentukan negara, wilayah tingkat kota, dan operator jaringan; alamat LAN, IPv6, atau antarmuka jaringan yang berbeda juga dapat mengungkapkan lebih banyak karakteristik topologi jaringan. IP biasanya tidak dapat secara tunggal menentukan alamat tempat tinggal yang tepat atau nama asli, tetapi dapat dikombinasikan dengan akun login, Cookie, sidik jari perangkat, dan data perilaku.

4. Konferensi video dan panggilan web mungkin menghadapi trade-off "privasi dan kegunaan"

Menonaktifkan WebRTC secara langsung memang dapat mengurangi permukaan paparan, tetapi konferensi video, panggilan suara layanan pelanggan, berbagi layar, atau transfer file langsung yang bergantung pada WebRTC mungkin tidak berfungsi normal. Oleh karena itu, pendekatan yang benar bukan menonaktifkan secara seragam di semua skenario, melainkan memilih antara Private dan Disabled sesuai kebutuhan bisnis.

Setelah browser anti deteksi menunjukkan kebocoran WebRTC, lakukan 6 langkah ini terlebih dahulu

Langkah 1: Hentikan operasi sensitif di lingkungan saat ini

Jika halaman deteksi sudah menampilkan IP publik asli, jangan melanjutkan login, pembayaran, penerbitan konten, atau pergantian akun penting. Catat hasil tes terlebih dahulu, termasuk:

• Alamat yang ditampilkan oleh deteksi IP biasa;
• IPv4 dan IPv6 yang ditampilkan oleh deteksi WebRTC;
• Alamat proxy dan negara/wilayah yang dikonfigurasi di MostLogin;
• Waktu tes, nama lingkungan, dan apakah VPN digunakan.

Mencatat informasi bertujuan untuk mengidentifikasi masalah. Tidak disarankan menyimpan screenshot yang mengandung kata sandi proxy, Cookie akun, atau kredensial lainnya.

Langkah 2: Buat perbandingan "IP asli — IP proxy — IP WebRTC"

Lakukan tiga kelompok pemeriksaan tanpa membuka akun bisnis:

1. Di browser biasa tanpa proxy, cari IPv4 dan IPv6 publik saat ini sebagai baseline jaringan asli.
2. Di tab Proxy MostLogin, klik pemeriksaan IP proxy dan catat keluaran yang diharapkan.
3. Buka lingkungan yang sesuai, baca alamat kandidat di halaman tes WebRTC.

Jika hasil WebRTC sama dengan kelompok baseline pertama, bukan sama dengan kelompok kedua keluaran proxy, pada dasarnya dapat dikonfirmasi ada kebocoran. Jika hasilnya konsisten dengan IP proxy, lebih mungkin merupakan tampilan kandidat WebRTC yang normal.

Langkah 3: Perbaiki proxy terlebih dahulu, baru atur WebRTC

Pengaturan WebRTC tidak dapat memperbaiki proxy yang sudah offline, gagal autentikasi, atau salah konfigurasi. Masuk ke halaman edit lingkungan target, buka tab Proxy, periksa protokol, host, port, akun, dan kata sandi, lalu jalankan pemeriksaan IP proxy. Panduan resmi MostLogin untuk membuat lingkungan menjelaskan bahwa saat ini dapat dikonfigurasi direct, http, https, dan socks5, serta dapat memverifikasi hasil koneksi melalui "Check proxy IP". MostLogin: Membuat lingkungan baru

Hanya setelah pemeriksaan proxy berhasil dan negara/kota yang ditampilkan sesuai harapan, lanjutkan ke langkah berikutnya.

Langkah 4: Pilih mode WebRTC yang sesuai di MostLogin

Jalur operasi biasanya:

Profiles (Daftar lingkungan) → Pilih lingkungan target → Edit → Fingerprint → WebRTC

Dokumentasi resmi MostLogin saat ini menampilkan pengaturan dropdown WebRTC, di mana Private digunakan untuk menyembunyikan IP asli saat mempertahankan fungsi WebRTC, dan mungkin juga menyediakan Public dan Disabled. MostLogin: Penjelasan pengaturan sidik jari WebRTC

Untuk lingkungan proxy biasa, disarankan menggunakan Private terlebih dahulu. Hanya jika bisnis tidak bergantung pada WebRTC, atau mode Private masih tidak memenuhi persyaratan isolasi, baru tes Disabled. Jangan hanya karena halaman tes menampilkan "WebRTC enabled" langsung menyimpulkan ada kebocoran; yang penting adalah alamat mana yang dikembalikan.

Langkah 5: Aktifkan perlindungan kegagalan proxy, dan periksa daftar bypass proxy

Masuk ke pengaturan global atau preferensi lingkungan MostLogin, aktifkan perlindungan berikut:

• Jangan buka lingkungan saat terjadi kesalahan jaringan proxy;
• Jangan buka lingkungan saat IP proxy berubah;
• Jangan buka lingkungan saat negara atau wilayah IP proxy berubah;
• Jangan buka lingkungan saat sinkronisasi lingkungan gagal.

MostLogin resmi menjelaskan pengaturan ini sebagai perlindungan sebelum memulai, di mana perlindungan kesalahan jaringan proxy dapat mencegah paparan tidak sengaja IP ISP asli saat proxy gagal. MostLogin: Preferensi profil

Selanjutnya periksa Settings → Proxy bypass. Domain yang ditambahkan ke daftar bypass akan menggunakan jaringan lokal secara langsung, bukan proxy lingkungan saat ini. Dokumentasi resmi MostLogin juga menjelaskan dengan jelas bahwa domain bypass diakses melalui koneksi lokal asli. MostLogin: Proxy bypass Jika situs tes, domain autentikasi, atau domain API/CDN-nya ada di sini, hapus pengecualian yang tidak perlu dan simpan.

Langkah 6: Tutup sepenuhnya dan buka ulang lingkungan, lakukan tes silang

Setelah menyimpan pengaturan, tutup seluruh lingkungan browser lalu mulai ulang, jangan hanya menyegarkan halaman deteksi. Gunakan setidaknya dua halaman deteksi independen untuk memeriksa:

• IP publik biasa yang ditampilkan browser ke dunia luar;
• IPv4 dalam kandidat WebRTC;
• IPv6 dalam kandidat WebRTC;
• Apakah DNS, zona waktu, bahasa, dan lokasi geografis konsisten dengan wilayah proxy.

Standar kelulusan tes ulang: halaman deteksi tidak lagi menampilkan IPv4/IPv6 publik ISP asli; alamat publik yang ditampilkan WebRTC harus konsisten dengan proxy, keluaran relai, atau perilaku produk yang diharapkan; hasil tetap stabil setelah lingkungan dimulai ulang.

Contoh penggunaan MostLogin: Lingkungan proxy New York terdeteksi memiliki IPv6 asli

Skenario

Tim QA situs web lintas wilayah membuat lingkungan MostLogin bernama US-NewYork-QA-01, pemeriksaan proxy HTTP menampilkan IPv4 New York, Amerika Serikat. Setelah membuka halaman tes, IP biasa tetap New York, tetapi area WebRTC menampilkan IPv6 publik dari operator lokal.

Diagnosis

Ini adalah kebocoran nyata, bukan kasus biasa "muncul beberapa IP". Penyebabnya adalah proxy HTTP mencakup permintaan web IPv4, tetapi jalur jaringan IPv6 host tidak ditangani secara setara, kandidat WebRTC masih dapat mengekspos alamat tersebut.

Penanganan

1. Tutup lingkungan, hindari melanjutkan tes login.
2. Periksa apakah layanan proxy secara eksplisit mendukung IPv6; jika tidak, gunakan solusi proxy yang mencakup IPv4/IPv6 secara lengkap, atau nonaktifkan jalur IPv6 yang tidak terlindungi di lapisan jaringan sistem.
3. Edit lingkungan, pilih Private di Fingerprint → WebRTC.
4. Aktifkan "Jangan buka lingkungan saat terjadi kesalahan jaringan proxy".
5. Periksa daftar bypass proxy, hapus domain pengecualian yang terkait dengan situs tes.
6. Buka ulang lingkungan untuk tes ulang, pastikan IPv6 asli tidak lagi muncul.

Dalam skenario ini, hanya mengganti mode WebRTC mungkin sementara menghilangkan hasil deteksi, tetapi cakupan proxy terhadap IPv6 tetap merupakan masalah mendasar, jadi keduanya harus diperiksa.

Contoh penggunaan MostLogin: Halaman tes menampilkan .local, tetapi IP publik konsisten dengan proxy

Skenario

Pengguna menggunakan proxy Inggris, IP biasa dan alamat publik WebRTC keduanya menampilkan Inggris; halaman tes juga mencantumkan string acak diakhiri .local, sehingga salah mengira terjadi kebocoran.

Penilaian

.local biasanya merupakan manifestasi browser menggunakan nama mDNS untuk menyembunyikan alamat jaringan lokal. Selama tidak muncul IPv4/IPv6 publik ISP asli, dan kandidat publik konsisten dengan proxy Inggris, tidak bisa hanya berdasarkan .local menyimpulkan ada kebocoran IP asli.

Penanganan

Pertahankan pengaturan Private saat ini, catat hasil dan lakukan verifikasi silang dengan halaman tes lain. Pada saat ini, sering mengganti proxy, mengacak sidik jari, atau membangun ulang lingkungan justru dapat menyebabkan lebih banyak variasi pada lingkungan tes yang seharusnya stabil.

Contoh penggunaan MostLogin: Konferensi video tidak dapat terhubung setelah WebRTC dinonaktifkan

Skenario

Tim dukungan remote mengatur WebRTC ke Disabled, setelah itu panggilan layanan pelanggan web dan berbagi layar tidak dapat membangun koneksi.

Penanganan

Ubah lingkungan ke Private, pastikan proxy terhubung normal, lalu tes ulang alamat WebRTC. Jika IP asli tidak lagi muncul dan audio/video pulih, fungsi dan isolasi jaringan dapat berjalan bersamaan. Jika masih bocor dalam mode Private, periksa protokol proxy, IPv6, pemisahan VPN, dan domain bypass, bukan langsung memilih Public untuk memulihkan panggilan.

Setelah perbaikan masih bocor, di mana masalahnya?

Jika MostLogin sudah diatur ke Private, tetapi tes masih menampilkan IP publik asli, lanjutkan pemeriksaan sesuai urutan berikut:

1. Proxy sebenarnya tidak terhubung. Ketika kredensial salah, node kedaluwarsa, atau server proxy offline, browser mungkin tidak mendapatkan keluaran yang diharapkan.
2. IPv6 tidak tercakup. Proxy hanya menangani IPv4, host masih dapat mengakses jaringan melalui IPv6 asli.
3. Aturan bypass proxy. Situs tes atau subdomain terkait diatur untuk koneksi langsung.
4. Pemisahan VPN atau konflik rute sistem. Menggunakan VPN, proxy sistem, dan proxy lingkungan secara bersamaan dapat menghasilkan jalur jaringan yang berbeda.
5. Proses lingkungan lama masih berjalan. Setelah menyimpan pengaturan, lingkungan tidak ditutup sepenuhnya, proses lama masih menggunakan konfigurasi asli.
6. Ekstensi browser mengubah perilaku jaringan. Ekstensi VPN, proxy, privasi, atau WebRTC dapat konflik dengan pengaturan lingkungan.
7. Halaman deteksi salah menilai atau cache. Gunakan halaman tes kedua dan mulai ulang lingkungan untuk verifikasi, jangan mengambil kesimpulan berdasarkan hasil tunggal.

Jika dua halaman tes independen secara stabil menampilkan alamat publik asli yang sama, simpan screenshot tanpa kredensial sensitif, nomor versi MostLogin, sistem operasi, protokol proxy, dan langkah reproduksi, lalu hubungi dukungan MostLogin atau penyedia layanan proxy.

Daftar periksa pencegahan kebocoran WebRTC

Setelah penggunaan pertama setiap lingkungan baru, penggantian proxy, pembaruan klien, atau peralihan jaringan, lakukan pemeriksaan berikut:

•  Pemeriksaan IP proxy MostLogin berhasil;
•  WebRTC diatur ke Private, atau Disabled jika tidak memerlukan komunikasi real-time;
•  IP publik biasa konsisten dengan keluaran proxy yang diharapkan;
•  WebRTC tidak menampilkan IPv4 publik ISP asli;
•  WebRTC tidak menampilkan IPv6 publik ISP asli;
•  DNS, zona waktu, bahasa tidak memiliki konflik yang jelas dengan lokasi proxy;
•  Perlindungan kesalahan proxy dan perubahan IP sudah diaktifkan;
•  Tidak ada domain koneksi langsung yang tidak perlu di Proxy bypass;
•  Hasil deteksi tetap konsisten setelah memulai ulang lingkungan.

Pertanyaan yang sering diajukan

Apakah WebRTC tes menampilkan beberapa IP pasti berarti bocor?

Belum tentu. Beberapa hasil mungkin berasal dari IPv4, IPv6, antarmuka LAN, pemetaan STUN, relai TURN, atau mDNS. Kebocoran berisiko tinggi hanya jika muncul IP publik ISP asli, keluaran jaringan yang tidak terkait, atau alamat publik yang jelas bertentangan dengan lokasi proxy.

Setelah menggunakan proxy, IP apa yang seharusnya ditampilkan WebRTC?

Dalam kondisi ideal, halaman web tidak seharusnya melihat IP publik ISP asli Anda. Tergantung pada browser dan kebijakan produk, halaman tes mungkin menampilkan alamat proxy, alamat relai, kandidat lokal yang disembunyikan, atau tidak menampilkan alamat yang tersedia. Standar penilaiannya bukan "hanya boleh muncul satu IP", melainkan "tidak boleh muncul keluaran publik asli yang perlu diisolasi".

MostLogin harus memilih Private atau Disabled?

Jika memerlukan audio/video web, panggilan layanan pelanggan, atau berbagi layar, prioritaskan Private dan tes ulang; jika sama sekali tidak menggunakan fungsi WebRTC, dapat memilih Disabled. Disabled mungkin memengaruhi fungsi situs web, jadi bukan solusi default optimal untuk semua lingkungan.

Bisakah kebocoran WebRTC mengekspos nama asli dan alamat tempat tinggal yang tepat?

Biasanya tidak bisa langsung mendapatkan nama asli atau alamat rumah yang tepat hanya dari IP, tetapi IP publik dapat mengungkapkan perkiraan wilayah dan operator, juga dapat dikombinasikan dengan akun, Cookie, sidik jari browser, dan catatan perilaku untuk membentuk petunjuk korelasi yang lebih kuat.

Sudah pernah terjadi kebocoran, apakah cukup memperbaiki pengaturan saja?

Perbaikan hanya dapat menghentikan paparan selanjutnya, tidak dapat menarik kembali data yang sudah diterima situs web. Untuk bisnis penting, periksa rentang waktu kebocoran terjadi, lingkungan yang terpengaruh, dan catatan login; jika perlu, akhiri sesi lama, perbarui kredensial, dan amati apakah platform menampilkan verifikasi anomali.

Kesimpulan

Inti kebocoran WebRTC bukan "apakah WebRTC aktif", melainkan apakah ia mengekspos alamat publik asli yang tidak konsisten dengan lingkungan proxy saat ini. Setelah menemukan anomali, hentikan dulu operasi sensitif, lalu selesaikan perbandingan menggunakan tiga kelompok data: IP asli, IP proxy, dan IP WebRTC. Pengguna MostLogin biasanya dapat menyelesaikan masalah dengan memeriksa koneksi proxy, memilih WebRTC Private, mengaktifkan perlindungan kegagalan proxy, membersihkan aturan bypass proxy yang tidak perlu, dan memverifikasi jalur IPv6.

Memasukkan pemeriksaan WebRTC ke dalam proses tetap sebelum lingkungan baru diluncurkan lebih andal daripada memperbaiki setelah muncul anomali akun. Tes ulang setelah setiap penggantian proxy, jaringan, atau versi klien untuk memastikan keluaran jaringan dan sidik jari browser tetap konsisten dalam jangka panjang.