Jika Anda melihat salah satu gejala di bawah ini bahkan setelah mengaktifkan VPN, curigai ada kebocoran DNS atau kebocoran WebRTC. Kebocoran terjadi ketika informasi yang seharusnya melalui jalur VPN meninggalkan jalur tersebut (disebut juga eksfiltrasi).
- IP server VPN ditampilkan pada halaman verifikasi IP, tetapi server DNS perusahaan telekomunikasi atau router ditampilkan dalam pengujian DNS.
- Alamat IPv4 sudah berubah, namun alamat IPv6 sama seperti sebelum mematikan VPN.
- Pada halaman pengujian WebRTC, IP publik muncul seperti sebelum VPN dimatikan.
- IP asli hanya terlihat segera setelah beralih dari Wi-Fi ke data seluler atau bangun dari mode tidur.
- Saya mengaktifkan StageVPN untuk Chrome, namun browser dan program PC lain terhubung menggunakan IP asli.
- Meskipun VPN diaktifkan, situs menampilkan bahasa dan konten berdasarkan wilayah aslinya (ini mungkin disebabkan oleh pengaturan akun/cookie).
Kebocoran DNS adalah fenomena di mana komunikasi web melewati terowongan ketika VPN dihidupkan, tetapi hanya permintaan DNS yang keluar dari terowongan, dan nama domain terlihat oleh server DNS perusahaan telekomunikasi atau Wi-Fi. Kebocoran WebRTC adalah fenomena di mana WebRTC browser mengirimkan permintaan STUN langsung dari VPN/proxy, sehingga halaman web dapat menemukan IP publik sebenarnya. Fenomena ini tidak berarti konten halaman bocor. Namun, ini mengungkapkan 'siapa yang mengakses di mana'. Artikel ini dimulai dengan gejala dan dilanjutkan melalui enam tahap diagnosis, penyelesaian berdasarkan penyebab, dan pemeriksaan ulang.
Diagnosis: Cara Memeriksa Kebocoran dalam 6 Langkah
Prinsip pemeriksaan kebocoran adalah membandingkan nilai dengan VPN yang dimatikan dan dihidupkan. Bandingkan IP yang ditampilkan di situs, server yang menerima permintaan DNS, dan alamat kandidat WebRTC. Jika nilai aslinya tetap terlihat bahkan setelah VPN diaktifkan, itu adalah kebocoran. Pengujian hanya bermakna pada perangkat dan browser yang benar-benar Anda gunakan. Meskipun Anda tidak memiliki situs pengujian khusus, Anda dapat memeriksa sebagian besar hal hanya dengan menggunakan browser. Halaman verifikasi IP adalah halaman web yang menampilkan alamat IP publik orang yang terhubung di layar. Anda dapat menemukannya di mesin pencari sebagai 'Periksa IP'. Temukan halaman pengujian kebocoran DNS dan halaman pengujian WebRTC dengan cara yang sama. Prinsipnya sama tidak peduli halaman mana yang Anda gunakan, jadi Anda tidak harus bergantung pada situs tertentu.
- Matikan VPN dan catat IP Anda. Buka halaman verifikasi IP dan tuliskan alamat IPv4 publik dan, jika ada, alamat IPv6. Nilai ini menjadi dasar untuk semua perbandingan selanjutnya.
- Nyalakan VPN Anda dan bandingkan IP. Setelah memeriksa indikator penyelesaian koneksi pada aplikasi StageVPN atau indikator ON hijau pada ikon StageVPN untuk Chrome, buka kembali halaman yang sama. IPv4 harus diganti dengan alamat server VPN Anda.
- Periksa server DNS Anda. Buka halaman Pengujian Kebocoran DNS. Halaman ini menanyakan subdomain acak dan kemudian menampilkan server DNS yang mengirimkan kueri. Jika Anda dapat melihat server operator atau router Anda, itu adalah kebocoran DNS.
- Buka chrome://webrtc-internals. Memasukkan alamat ini di bilah alamat Chrome akan menampilkan koneksi WebRTC yang sedang berlangsung dan alamat kandidat. Item akan muncul jika Anda membuka halaman pengujian WebRTC atau halaman panggilan video di tab lain.
- Periksa IP kandidat. Jika alamat kandidat srflx (refleksi server) sama dengan IP publik asli dari langkah 1, maka itu adalah kebocoran WebRTC. Jika itu adalah IP server VPN atau hanya nama .local dan IP pribadi yang terlihat, maka IP publik tidak akan terekspos.
- Periksa IPv6. Jika Anda memiliki alamat IPv6 pada langkah 1, aktifkan VPN dan lihat apakah alamat tersebut telah hilang atau berubah. Jika hal ini terjadi, IPv6 akan meninggalkan terowongan. Beralih antara Wi-Fi dan data seluler, dan ulangi untuk melihat apakah hasilnya sama setelah memulai ulang browser.
| Hasil observasi | arti | Penyebab selanjutnya |
|---|---|---|
| IP server VPN terlihat di situs | Komunikasi web melalui jalur VPN | Biasa, langkah selanjutnya |
| IPv4 telah berubah, tetapi IPv6 adalah alamat aslinya | IPv6 meninggalkan terowongan | Penyebab 2 |
| Server DNS berasal dari perusahaan telekomunikasi atau router. | Kebocoran DNS | Penyebab 1, 3, 4, 5 |
| Server DNS adalah penyedia DNS publik | DNS dalam konfigurasi VPN Anda atau DNS aman yang Anda tentukan sendiri. | Jangan berasumsi bocoran hanya berdasarkan nama bisnisnya, cek penyebab 4 |
| IP publik asli terlihat di WebRTC | Kebocoran WebRTC | Penyebab 6 dan 7 |
| Hanya nama .lokal atau IP pribadi yang terlihat di WebRTC | IP publik tidak diekspos | umumnya normal |
| IP asli hanya segera setelah peralihan jaringan | kesenjangan pada saat transisi | Penyebab 8 |
Hasil mungkin berbeda tergantung situs pengujian. Ada tempat yang hanya melihat IPv4 dan ada tempat yang melihat IPv6, dan metode untuk menemukan server DNS juga berbeda. Bandingkan di lebih dari satu tempat dan dengan beralih ke beberapa jaringan.
Apa yang diungkapkan oleh kueri DNS?
Kueri DNS berisi nama domain. Konten halaman atau nilai yang dimasukkan tidak disertakan. DNS adalah sistem buku alamat Internet yang mengubah nama domain yang dibaca manusia menjadi alamat IP yang digunakan oleh komputer. Setiap kali Anda mengetikkan alamat ke browser atau aplikasi menghubungi server, perangkat Anda terlebih dahulu menanyakan server DNS 'apa alamat nama ini?' Jadi, hanya dengan melihat riwayat kueri, Anda dapat mengetahui banyak hal tentang kapan dan layanan mana yang Anda coba akses.
- perangkat sayaAplikasi/Peramban
- Kueri DNS teks biasa
- Wi-Fi publikrouter kafe
- Kueri DNS teks biasa
- DNS operatorserver yang ada
- Area yang mungkin terpapar
- perangkat sayaAplikasi/Peramban
- DNS di terowongan
- Wi-Fi publikrouter kafe
- DNS di terowongan
- server VPNStageVPN
- Kueri berdasarkan IP server VPN
- server DNSTentukan dalam konfigurasi VPN
- Enkripsi VPN
Kueri DNS tradisional masuk ke port UDP 53 tanpa terenkripsi. Untuk mengimbangi hal ini, DoH (RFC 8484), yang menggabungkan kueri dalam HTTPS, dan DoT (RFC 7858), yang menggabungkan kueri dalam TLS, telah dibuat. Namun, meskipun Anda menggunakan DNS terenkripsi, nama server (SNI) yang dikirim saat menyambung ke situs melalui HTTPS mungkin terlihat di jaringan jika situs dan browser tidak mendukung ECH (Encrypted Client Hello).
| metode pengiriman | Pengamat di Wi-Fi yang sama | Operator Wi-Fi/perusahaan komunikasi | Server DNS menerima permintaan |
|---|---|---|---|
| DNS biasa (teks jelas) | bisa melihat | bisa melihat | Terlihat, dengan IP publik saya |
| DoH/DoT (DNS Terenkripsi) | tidak bisa melihat | Tidak terlihat, alamat server DNS terlihat | Terlihat, dengan IP publik saya |
| DNS di dalam terowongan VPN | tidak bisa melihat | Tidak terlihat, hanya terlihat sedang berkomunikasi dengan server VPN | Terlihat, dengan IP server VPN |
| Status kebocoran DNS | Jika itu teks biasa, Anda dapat melihatnya. | bisa melihat | Terlihat, dengan IP publik saya |
DNS Aman (DoH) dan VPN memiliki tujuan berbeda. DoH hanya mengenkripsi permintaan DNS; akses situs itu sendiri dan IP yang dilihat situs tetap sama. VPN mengenkripsi seluruh komunikasi antara perangkat atau browser Anda dan server VPN dan mengubah IP yang dilihat situs. Mode penyamaran juga tidak menghentikan kebocoran. Mode penyamaran adalah fungsi yang tidak meninggalkan riwayat atau cookie di perangkat, dan tidak mengubah kueri DNS atau rute WebRTC.
Bagaimana WebRTC menentukan alamat IP?
WebRTC menemukan alamatnya sendiri dalam beberapa cara untuk menghubungkan dua perangkat melalui jalur terpendek dan meneruskan hasilnya ke skrip di halaman web. WebRTC adalah teknologi standar web yang memungkinkan Anda melakukan panggilan video, panggilan suara, dan transfer file tanpa plugin di browser Anda. Proses pengumpulan alamat disebut ICE (RFC 8445). Bahkan halaman yang tidak melakukan panggilan video dapat memulai proses ini dengan skrip.
- Buat objek koneksiSkrip halaman web membuat RTCPeerConnection
- Kumpulkan kandidat lokalBrowser Anda mengumpulkan alamat perangkat jaringan perangkat Anda
- permintaan STUNTanyakan pada server STUN 'seperti apa alamat saya' dengan UDP
- Pengiriman kandidatDaftar kandidat termasuk alamat publik yang disediakan oleh server STUN dikirimkan ke halaman.
| Tipe kandidat | sesuatu | Informasi yang mungkin terungkap | Perlindungan browser terbaru |
|---|---|---|---|
| tuan rumah | Alamat perangkat jaringan mesin | IP Pribadi (192.168.x, dll.) | Disamarkan dengan nama .local acak (mDNS), namun dapat dilihat di situs yang telah memberikan izin kamera dan mikrofon. |
| srflx (refleksi server) | Alamat publik saya seperti yang dilihat oleh server STUN | IP Publik, IP asli jika Anda melewati proxy | Dapat dibatasi oleh kebijakan pemrosesan IP WebRTC |
| menyampaikan | MENGHIDUPKAN Alamat server relai | IP server relai | Jika Anda menggunakan relay, pihak lain akan melihat alamat server, bukan IP Anda. |
Masalahnya adalah kueri STUN pada langkah 3. Proksi browser meneruskan permintaan web, tetapi komunikasi UDP WebRTC tidak melalui proksi dalam pengaturan default browser. Jadi alamat yang diberikan oleh server STUN bukanlah server proxy, melainkan IP publik asli saya. Hal-hal berbeda terjadi pada VPN yang mencakup seluruh perangkat. Karena semua komunikasi UDP, termasuk permintaan STUN, masuk ke terowongan, alamat yang dilihat oleh server STUN juga merupakan IP server VPN.
Proksi browser dan kebijakan default
- Permintaan web melalui proxy
- Permintaan STUN langsung menuju ke UDP
- Halaman dapat melihat IP publik sebenarnya
Proksi peramban dan nonaktifkan_non_proxied_udp
- Cegah UDP melalui proxy
- WebRTC hanya menggunakan jalur proxy
- Beberapa panggilan memiliki metode atau kualitas koneksi yang berbeda
VPN di seluruh perangkat
- Permintaan STUN juga melalui terowongan.
- Kandidat alamat publik adalah IP server VPN
- Pemutusan sambungan dan penanganan IPv6 memerlukan konfirmasi
Chrome memiliki 'kebijakan penanganan IP WebRTC' yang menentukan alamat mana yang akan digunakan WebRTC, dan ekstensi dapat mengubah nilai ini. Setiap nilai sesuai dengan empat metode yang diuraikan dalam Rekomendasi Penanganan Alamat IP WebRTC IETF (RFC 8828).
| nilai kebijakan | pergerakan | rentang paparan |
|---|---|---|
| bawaan | Kumpulkan kandidat dari semua perangkat jaringan | Terluas (alamat lokal ditutupi oleh mDNS) |
| default_public_and_private_interfaces | Hanya gunakan perangkat pada rute default, gunakan alamat publik dan pribadi | Tidak memaparkan alamat perangkat lain |
| default_public_interface_only | Hanya gunakan alamat publik dari rute default | Alamat pribadi tidak diekspos |
| nonaktifkan_non_proxied_udp | Tidak ada UDP melalui proxy, gunakan TCP melalui proxy jika proxy tidak mendukung UDP | Jangan memaparkan alamat rute di luar proxy |
Solusi: Cara memeriksa dan memperbaikinya berdasarkan penyebabnya
Kebanyakan kebocoran mempunyai satu dari delapan penyebab: Hal ini biasanya disebabkan oleh pengaturan yang tumpang tindih. Mulailah dengan memeriksa nomor penyebab yang ditunjukkan dalam tabel diagnosis, dan setiap kali Anda memperbaikinya, ulangi langkah 6 pada gambar di atas untuk melihat apakah hasilnya berubah. Jika Anda mengubah beberapa pengaturan sekaligus, Anda tidak akan tahu mana yang berhasil.
Penyebab 1 · Tidak ada server DNS dalam konfigurasi VPN atau perangkat menggunakan DNS yang berbeda.
memeriksa Saat VPN diaktifkan, tes DNS menunjukkan router Wi-Fi atau server DNS operator. Anda sering kali memiliki DNS manual di pengaturan Wi-Fi perangkat Anda.
menyelesaikan Aplikasi StageVPN menyertakan server DNS dalam konfigurasi VPN dan mengirimkan pertanyaan ke dalam terowongan. Kembalikan DNS Manual ke otomatis di pengaturan jaringan perangkat Anda, lalu putuskan sambungan dan sambungkan kembali ke VPN. Jika masalahnya masih sama, periksa penyebab 3 dan 5.
Penyebab 2 IPv6 keluar dari terowongan
memeriksa IPv4 telah diubah menjadi alamat server VPN, namun IPv6 tetap sama dengan nilai yang ditulis pada langkah 1. Jika VPN hanya menyalurkan IPv4, kueri dan komunikasi IPv6 akan keluar dari rute aslinya.
menyelesaikan Aplikasi StageVPN dikonfigurasi untuk mengirim komunikasi IPv6 ke terowongan juga (AllowedIPs 0.0.0.0/0, ::/0), jadi biasanya tidak perlu mematikannya. Jika IPv6 masih muncul sebagaimana mestinya, periksa dulu apakah aplikasi VPN atau pengaturan perangkat lain mengubah rute. Beberapa situs pengujian tidak mendukung IPv6, jadi bandingkan di lebih dari satu situs.
Penyebab 3 · Sistem operasi menanyakan DNS beberapa perangkat jaringan secara bersamaan.
memeriksa Khususnya saat koneksi VPN di PC Windows, tes DNS menunjukkan DNS VPN dan DNS operator Anda. Hal ini disebabkan oleh fitur yang menanyakan semua perangkat jaringan secara bersamaan, seperti Resolusi Nama Multi-Rumah Cerdas Windows.
menyelesaikan Selalu perbarui sistem operasi dan perangkat lunak VPN Anda dan ulangi pengujian. Fenomena ini terutama dilaporkan pada VPN seluruh perangkat di PC, dan tidak terjadi dengan cara yang sama pada aplikasi StageVPN di ponsel cerdas dan StageVPN untuk Chrome di Chrome karena strukturnya yang berbeda.
Penyebab 4 · Secure DNS (DoH) ditentukan secara terpisah di browser atau perangkat
memeriksa Tes DNS menunjukkan server dari penyedia DNS publik. Dalam hal ini, mungkin bukan kebocoran melainkan pengaturan yang Anda tentukan sendiri. Jika Anda memiliki VPN di seluruh perangkat, kueri ini juga akan melewati terowongan, namun akan diterima oleh penyedia yang ditentukan, bukan oleh DNS dalam konfigurasi VPN Anda.
menyelesaikan Jika ini adalah pengaturan yang diinginkan, Anda dapat membiarkannya apa adanya. Jika Anda ingin menggunakan DNS untuk konfigurasi VPN Anda, maka secara otomatis akan mengubah pengaturan DNS aman di browser dan perangkat Anda. Penting untuk tidak berasumsi bahwa ini adalah kebocoran hanya dengan melihat nama bisnisnya.
Penyebab 5 · Aplikasi VPN, proxy, dan keamanan lainnya juga diaktifkan
memeriksa Fitur jaringan aplikasi VPN lain, ekstensi proxy, filter iklan, atau program keamanan diaktifkan secara bersamaan. Pengaturan rute saling menimpa, menyebabkan beberapa kueri menuju ke rute asli.
menyelesaikan Nyalakan hanya satu per satu. Matikan aplikasi dan ekstensi lain, putuskan sambungan dan sambungkan kembali StageVPN, lalu ulangi langkah 6. Setelan proksi Chrome hanya dapat mengontrol satu ekstensi dalam satu waktu, jadi jika ekstensi lain menggunakan proksi, StageVPN untuk Chrome tidak akan tersambung dan akan memberi tahu Anda alasannya.
Penyebab 6 · Hanya proxy browser yang digunakan, tetapi komunikasi di luar browser diharapkan
memeriksa Saya mengaktifkan StageVPN untuk Chrome, tetapi browser lain, pengirim pesan PC, dan program email terhubung menggunakan IP asli dan DNS asli. Ini bukan bocoran, ini adalah kisaran yang dirancang. Ekstensi ini hanya mencakup komunikasi di Chrome.
menyelesaikan Jika Anda perlu melindungi program di luar Chrome, gunakan VPN yang berlaku untuk seluruh perangkat. Di ponsel pintar, aplikasi StageVPN melakukan hal itu. Perbedaan cakupan antara kedua metode tersebut adalah VPN Peramban vs VPN AplikasiSaya mengaturnya dalam .
Penyebab 7 Kebijakan WebRTC tidak diterapkan
memeriksa Saya mengaktifkan StageVPN untuk Chrome dan saya dapat melihat IP publik asli di pengujian WebRTC atau di kandidat srflx di chrome://webrtc-internals. Jika ekstensi lain atau kebijakan manajemen perusahaan/organisasi mengontrol pengaturan WebRTC terlebih dahulu, StageVPN untuk Chrome tidak akan mengubah kebijakan dan membiarkannya apa adanya.
menyelesaikan Matikan ekstensi lain yang mengontrol pengaturan WebRTC dan sambungkan kembali StageVPN untuk Chrome. Jika kebijakan manajemen adalah penyebabnya, hubungi administrator Anda. Untuk menulis di jendela penyamaran, Anda harus mengaktifkan 'Izinkan dalam mode penyamaran' di layar pengelolaan ekstensi. Jika tidak aktif, komunikasi di jendela penyamaran tidak melalui proxy.
Penyebab 8 · Saat koneksi VPN terputus
memeriksa IP asli hanya terlihat segera setelah berpindah jaringan atau bangun dari mode tidur, dan setelah beberapa saat menjadi normal. Selama pemutusan sambungan, semua pertanyaan dan komunikasi keluar melalui rute normal.
menyelesaikan Sebelum melakukan pekerjaan sensitif apa pun, periksa apakah indikator penyelesaian koneksi aplikasi atau ikon ekstensi AKTIF. WireGuard, yang digunakan oleh aplikasi StageVPN, tidak membangun kembali terowongan bahkan ketika beralih dari Wi-Fi ke LTE, namun protokolnya tidak dapat mengkompensasi pemutusan sementara di jaringan itu sendiri. Kemampuan untuk memblokir komunikasi secara otomatis ketika koneksi VPN terputus bukan merupakan fitur yang disediakan oleh StageVPN. Prinsipnya adalah Menjelaskan Prinsip WireGuardada di
Bagaimana cara aplikasi StageVPN dan StageVPN untuk Chrome menghentikan kebocoran?
Aplikasi StageVPN mengurangi kebocoran dengan menyalurkan semua komunikasi, sementara StageVPN untuk Chrome melakukan pencarian nama proxy dan menyesuaikan kebijakan WebRTC. Karena cakupan perlindungannya berbeda, cara penanganannya juga berbeda.
| barang | Aplikasi StageVPN (iPhone·iPad·Android) | StageVPN untuk Chrome |
|---|---|---|
| jangkauan perlindungan | Semua perangkat | Peramban Chrome |
| Komunikasi dikirim melalui rute VPN | IPv4·IPv6 Semua (IP yang Diizinkan 0.0.0.0/0, ::/0) | Permintaan web melalui proxy (tidak termasuk pita IP pribadi dan localhost) |
| Kueri DNS | Meneruskan dalam terowongan ke server DNS yang ditentukan dalam konfigurasi VPN. | Permintaan yang masuk melalui proxy tidak dicari oleh Chrome, namun oleh server proxy. |
| WebRTC | Semua komunikasi UDP melewati terowongan. | disable_non_proxied_udp diterapkan selama koneksi, dan kembali ke pengaturan awal saat terputus. |
| Apa yang saat ini Anda lihat di jaringan | Fakta bahwa ada komunikasi terenkripsi dengan server VPN dan jumlah datanya | Pencarian nama alamat server proxy, koneksi terenkripsi dengan proxy, dan komunikasi dari aplikasi di luar Chrome |
| Kasus yang mungkin tidak berlaku | Saat koneksi VPN terputus, saat aplikasi VPN lain merutekan ulang | Jendela penyamaran dengan Izinkan mode penyamaran dinonaktifkan saat ekstensi atau kebijakan pengelolaan lain mengontrol setelan proxy/WebRTC |
| Riwayat akses (93 hari) | Domain yang dilihat tidak dicatat | Nama host tujuan yang terhubung dicatat, namun jalur atau istilah pencarian tidak dicatat. |
StageVPN tidak memandu Anda melalui menu pengaturan proteksi kebocoran DNS terpisah sebagai fitur penawarannya. Perilaku di atas bergantung pada konfigurasi VPN default aplikasi dan metode koneksi ekstensi. Ruang lingkup pemberiannya adalah Fitur dan Cakupan PenawaranAnda dapat memeriksanya di sini.
Tidak ada kebocoran berarti bahwa pertanyaan dan komunikasi melalui jalur VPN, bukan melalui operator. Ini tidak berarti bahwa tidak ada catatan yang disimpan. StageVPN menyimpan catatan akses selama 93 hari sesuai dengan Undang-Undang Perlindungan Rahasia Komunikasi dan tidak merekam konten komunikasi. Barangnya adalah Akses pemberitahuan penyimpanan catatanYa, alasanku mengungkapkannya adalah Mengapa kami mengungkapkan kebijakan penyimpanan catatan akses kami?menjelaskan.
Periksa kembali daftar periksa: Apa yang Anda periksa ulang setelah melakukan perubahan?
Setiap kali Anda memperbaiki satu penyebab, periksa kembali item di bawah ini dari awal. Jika semuanya lolos maka tidak ada kebocoran. Jika ada item yang gagal, item tersebut akan dikembalikan ke kartu penyebab yang sesuai.
- Setelah memutus dan menghubungkan kembali VPN, saya memeriksa apakah aplikasi menunjukkan penyelesaian koneksi atau ikon perluasan menunjukkan AKTIF.
- Pada halaman verifikasi IP, Anda akan melihat alamat server VPN untuk IPv4 dan IPv6, atau Anda tidak akan melihat IPv6.
- Tes DNS tidak menunjukkan server DNS perusahaan telekomunikasi atau router.
- Kandidat srflx di chrome://webrtc-internals tidak memiliki IP publik asli.
- Fitur jaringan aplikasi VPN lain, proxy/ekstensi VPN, dan program keamanan dimatikan.
- Jika Anda telah mengatur DNS Manual atau DNS Aman untuk perangkat dan browser Anda, Anda telah memverifikasi bahwa ini adalah pengaturan yang dimaksudkan.
- Sistem operasi, browser, serta aplikasi dan ekstensi StageVPN Anda sudah yang terbaru.
- Hasil yang sama bahkan setelah beralih antara Wi-Fi dan data seluler dan memulai ulang browser.
- Jika Anda perlu melindungi program di luar Chrome, Anda dapat menggunakan VPN di seluruh perangkat, bukan ekstensi.
Sebaiknya tentukan juga kapan pemeriksaan ulang diperlukan. Itu terjadi setelah pembaruan besar pada sistem operasi atau browser Anda, setelah memasang ekstensi baru atau aplikasi keamanan, atau sebelum melakukan pekerjaan sensitif apa pun pada jaringan yang Anda sambungkan untuk pertama kalinya. Jika settingannya sama namun hasilnya berubah, biasanya salah satu dari tiga hal ini menjadi penyebabnya. Setelah Anda memahaminya, 6 tahap diagnosis dapat diselesaikan hanya dalam beberapa menit.
Jika masalah terus berlanjut, atur model perangkat, sistem operasi dan versi aplikasi, waktu terjadinya, dan hasil pengujian. dukungan pelangganSilakan hubungi kami. Harap jangan mengirimkan kata sandi atau kode verifikasi Anda. Pengaturan perangkat yang harus diperiksa bersamaan dengan pemeriksaan kebocoran adalah: 10 pengaturan privasi ponsel cerdasYa, ada risiko yang tidak bisa diselesaikan hanya dengan VPN. Apa yang Dicegah dan Tidak Dapat Dicegah oleh VPNNah, kebiasaan Anda di jaringan publik adalah Aturan Keamanan Wi-Fi PublikSaya mengaturnya dalam .
bahan referensi
- RFC 1034: Nama Domain — Konsep dan Fasilitas — Struktur DNS dan peran penyelesai (IETF)
- RFC 8484: Kueri DNS melalui HTTPS (DoH) — Cara mengenkripsi kueri DNS melalui HTTPS (IETF)
- RFC 7858: DNS melalui TLS — Cara mengenkripsi kueri DNS dengan TLS (IETF)
- RFC 8445: Pembentukan Konektivitas Interaktif (ICE) — Jenis kandidat koneksi WebRTC dan prosedur pengumpulan (IETF)
- RFC 8828: Persyaratan Penanganan Alamat IP WebRTC — Rentang alamat yang diekspos browser ke WebRTC (IETF)
- chrome.privasi API — Nilai Kebijakan Penanganan IP WebRTC Chrome (Chrome untuk Pengembang)
- chrome.proxy API — Pengaturan proxy ekstensi, daftar bypass, dan prioritas kontrol (Chrome untuk Pengembang)
- API WebRTC — RTCPeerConnection dan konsep kandidat ICE (MDN Web Docs)
