Salah satu sebab utama untuk menggunakan VPN ialah menyembunyikan alamat IP sebenar anda. Apabila menggunakan VPN, lalu lintas internet anda disulitkan dan dihantar ke pelayan VPN yang dijalankan oleh pembekal VPN anda, sebelum keluar ke internet.

Ini bermakna pemerhati luar hanya dapat melihat alamat IP pelayan VPN dan bukan alamat IP sebenar anda. Oleh itu, satu-satunya cara bagi mereka untuk mengetahui alamat IP sebenar anda ialah untuk meyakinkan penyedia VPN anda untuk menyerahkannya kepada mereka (dan pembekal yang baik menggunakan langkah-langkah yang teguh seperti menggunakan IP yang dikongsi dan tidak menyimpan log untuk membuat ini sesedih mungkin).

Malangnya, kadang kala mungkin bagi laman web untuk mengesan alamat IP sebenar anda, walaupun menggunakan VPN.

Artikel ini bertujuan untuk menjawab: apakah kebocoran IP, mengapa IP saya bocor walaupun saya bersambung dengan VPN, dan bagaimana saya membetulkan masalah?

Bagaimana untuk Menguji kebocoran DNS atau kebocoran IP

Untuk menentukan sama ada anda mengalami kebocoran IP:


1. Lawati ipleak.net tanpa menjalankan VPN. Buat nota semua alamat IP yang anda lihat (atau tinggalkan tetingkap terbuka), kerana ini adalah alamat IP sebenar anda.

Berikut adalah apa yang kelihatan sambungan pejabat IPv6 kami kelihatan seperti tanpa VPN. Jika sambungan anda tidak mampu IPv6 maka anda hanya akan melihat alamat IPv4. Seperti yang dapat kita lihat, WebRTC dengan betul melaporkan alamat IPv6 sebenar kami. Sekiranya kita tidak mempunyai keupayaan IPv6 maka ia akan melaporkan alamat IPv4 kita.

WebRTC juga melaporkan alamat Penggunaan Swasta (IANA Persendirian atau Alamat Khas), tetapi ini tidak membimbangkan kami. Alamat Penggunaan Swasta ini adalah alamat dalaman yang hanya digunakan oleh rangkaian tempatan anda sahaja.

Walaupun WebRTC tidak mengembalikan alamat IP Gunakan Swasta sebenar apabila VPN sedang berjalan ia bukan risiko privasi kerana ini tidak boleh digunakan untuk mengenal pasti anda dari internet.

2. Hidupkan VPN anda. Walaupun tidak diperlukan, menghubungkan ke pelayan VPN di negara yang lain membuat percikan IP kebocoran lebih mudah.

3. Buka tetingkap Persendirian / Penyamaran dalam pelayar anda, lawati ipleak.net sekali lagi, dan bandingkan keputusan dengan yang anda peroleh tanpa VPN yang sedang berjalan.

  • Jika alamat IPv4 biasa adalah alamat IPv4 sebenar anda maka VPN sama ada tidak dihidupkan atau tidak berfungsi.
  • Anda boleh mengabaikan IP Penggunaan Swasta yang dikesan oleh WebRTC. Seperti telah dibincangkan, ini tidak memberi ancaman kepada privasi dalam talian anda dan oleh itu tidak dikira sebagai kebocoran IP (dalam istilah praktikal, bagaimanapun juga).
  • Jika mana-mana alamat lain di laman web ipleak.net sepadan dengan alamat sebenar anda maka VPN sedang bekerja tetapi bocor alamat IP anda dalam beberapa cara.

Yang baik

Menyambung ke pelayan VPN AS dari UK, di bawah adalah hasil yang ingin kita lihat.

  • Alamat IPv4 telah berubah ke lokasi pelayan VPN. Jadi VPN berfungsi.
  • IPv6 telah dilumpuhkan atau disekat untuk mengelakkan kebocoran IPv6 teratur.
  • WebRTC tidak mengesan alamat IPv4 atau IPv6 sebenar kami. Kita boleh mengabaikan alamat Penggunaan Swasta kerana ia tidak mengancam privasi kami.
  • Pelayan DNS yang digunakan bukan milik ISP kami dan diselesaikan di negara yang betul.

Jika DNS diselesaikan dekat dengan tempat pelayan VPN terletak maka ia sangat menyarankan bahawa perkhidmatan VPN menjalankan pelayan DNS sendiri di sana.

Sekiranya anda melihat berbilang alamat DNS yang hanya mencari lokasi negara atau geografi yang lebih luas, maka terjemahan DNS mungkin dilakukan oleh resolver DNS pihak ketiga seperti DNS Google.

Ini tidak menjadi masalah selagi kita menganggap permintaan DNS dihantar melalui sambungan VPN dan oleh itu disokong oleh pelayan VPN (andaian yang agak selamat, walaupun anda tidak pernah tahu).

Malangnya, biasanya tidak ada cara mudah bagi pengguna akhir untuk mengetahui apakah permintaan DNS dikendalikan oleh resolver pihak ketiga yang disokong oleh perkhidmatan VPN atau dihantar terus kepada resolver. Oleh itu, anda hanya perlu mempercayai penyedia anda pada satu ini (atau bertukar kepada pembekal yang pasti menjalankan pelayan DNS sendiri).

Perlu diingat bahawa Google DNS menyelesaikan semua permintaan DNS Eropah menggunakan pelayan yang terletak di Belanda dan Belgium. Jadi jika anda disambungkan ke pelayan VPN di UK, Perancis, atau Romania, tetapi pelayan DNS terletak di Belgium, itu sebabnya. Dan itu bukan masalah (selagi kita menganggap permintaan DNS sedang proksi dan tidak dihantar terus ke Google).

Yang jahat

Ini adalah contoh yang anda tidak mahu lihat apabila menyambung ke pelayan VPN di Jerman dari UK.

  • Alamat IPv4 telah berubah menjadi bahasa Jerman, jadi VPN sedang bekerja pada tahap asas.
  • Walau bagaimanapun, kami masih dapat melihat alamat IPv6 biasa sebenar kami. Ini bermakna kita mempunyai kebocoran IPv6 biasa (atau hanya "kebocoran IPv6").
  • WebRTC juga melaporkan alamat IPv6 sebenar kami. Jadi kita mempunyai kebocoran WebRTC IPv6.
  • Alamat DNS bukan di Jerman, tetapi mereka tidak termasuk ISP sebenar kami. Jadi mereka tidak menjadi kebocoran DNS.

Di bawah ini, kami akan menjelaskan jenis kebocoran IP yang berlainan dan cara untuk membetulkannya. Walau bagaimanapun, dalam semua kes, penyelesaian yang sering tidak direkodkan tetapi disyorkan ialah untuk menukar perkhidmatan VPN kepada orang yang tidak bocor.

Kebocoran IPv6 yang kerap

Memahami IPv4

Setiap sambungan internet mempunyai alamat berangka unik yang dipanggil alamat Protokol Internet (IP). Alamat IP (atau hanya "IP") diberikan oleh penyedia Internet (ISP) yang menghubungkan peranti tersebut.

Sehingga baru-baru ini, seluruh internet menggunakan standard Internet Protocol versi 4 (IPv4) untuk menentukan alamat IP. Ini menyokong alamat internet 32-bit maksimum, yang diterjemahkan ke 2 ^ 32 alamat IP (sekitar 4.29 bilion) yang tersedia untuk tugasan.

Malangnya, berkat peningkatan penggunaan internet yang belum pernah berlaku sebelum ini sejak beberapa tahun kebelakangan ini, alamat IPv4 sedang habis. Sebenarnya, secara teknis mereka telah berbuat demikian, walaupun jalan penyelesaian bermakna bahawa IPv4 masih jauh dari mati. Pada masa ini, kebanyakan alamat internet masih menggunakan piawaian IPv4.

Memahami IPv6

Walaupun pelbagai strategi pengurangan telah digunakan untuk memanjangkan jangka hayat IPv4, penyelesaian sebenar datang dalam bentuk standard baru - IPv6. Ini menggunakan alamat web 128-bit, dengan itu mengembangkan bilangan alamat web maksimum yang maksimum kepada 2 ^ 128 (sekitar 340 bilion bilion bilion!). Yang sepatutnya membuat kami dibekalkan dengan alamat IP untuk masa hadapan yang boleh dijangka.

Walau bagaimanapun, penggunaan IPv6 telah perlahan - terutamanya disebabkan peningkatan kos, kebolehpasaran keupayaan mundur, dan kemalasan semata-mata. Akibatnya, walaupun semua Sistem Operasi moden menyokong IPv6, kebanyakan ISP dan laman web tidak lagi mengganggu.

Ini telah membawa laman web yang menyokong IPv6 untuk menerima pakai pendekatan dwi-peringkat. Apabila disambungkan ke dari alamat yang hanya menyokong IPv4, ia akan menyampaikan alamat IPv4, tetapi apabila disambungkan dari alamat yang menyokong IPv6, mereka akan menyampaikan alamat IPv6.

Ini telah membawa laman web yang menyokong IPv6 untuk menerima pakai pendekatan dwi-peringkat. Apabila disambungkan ke alamat yang hanya menyokong IPv4, mereka akan menyampaikan alamat IPv4. Tetapi apabila disambungkan dari alamat yang menyokong IPv6, mereka akan menyampaikan alamat IPv6.

Sehingga alamat IPv4 mula kehabisan, tidak ada kelemahan untuk menggunakan sambungan IPv4 sahaja.

Kebocoran VPN IPv6

Sayangnya, banyak perisian VPN tidak terjejas dengan IPv6. Apabila anda menyambung ke laman web yang didayakan IPv6 dari sambungan internet yang didayakan IPv6, klien VPN akan menggunakan sambungan IPv4 anda melalui antara muka VPN tetapi tidak menyedari sambungan IPv6 juga dibuat.

Jadi laman web tidak akan melihat alamat IPv4 sebenar anda, tetapi ia akan melihat alamat IPv6 anda. Yang boleh digunakan untuk mengenal pasti anda.

Penyelesaian

1. Gunakan klien VPN dengan perlindungan kebocoran IPv6

Semua pelanggan VPN yang baik hari ini menawarkan perlindungan kebocoran IPv6. Dalam kebanyakan kes, ini dilakukan dengan melumpuhkan IPv6 pada tahap sistem untuk memastikan sambungan IPv6 tidak dapat dilakukan. Ini adalah penyelesaian yang malas, tetapi ia berfungsi dengan baik.

Lebih menarik dari segi teknikal adalah aplikasi VPN yang menggunakan laluan IPv6 dengan betul melalui antara muka VPN. Ini adalah penyelesaian yang lebih elegan dan sudah pasti masa depan untuk semua aplikasi VPN.

Jika perisian tersuai VPN anda tidak menghalang kebocoran IPv6 teratur maka anda boleh menggunakan aplikasi pihak ketiga sebaliknya. OpenVPN GUI untuk Windows, Tunnelblick untuk macOS, OpenVPN untuk Android, dan OpenVPN Connect untuk iOS (dan platform lain) semuanya menyediakan perlindungan kebocoran IPv6 yang berkesan.

2. Matikan IPv6 secara manual pada sistem anda

Cara yang paling pasti untuk menghalang kemungkinan kebocoran IP adalah untuk melumpuhkan IPv6 di peringkat sistem (jika mungkin). Sila lihat panduan kami tentang Cara untuk melumpuhkan IPv6 pada semua peranti untuk arahan tentang cara melakukan ini.

Kebocoran DNS

Kebocoran DNS adalah bentuk kebocoran IP yang paling terkenal kerana ia digunakan untuk menjadi yang paling biasa. Dalam tahun-tahun kebelakangan ini kebanyakan perkhidmatan VPN telah melangkah ke tanda, bagaimanapun, dan dalam ujian kami, kami mengesan kebocoran DNS lebih kurang.

Sistem Nama Dinamik (DNS) digunakan untuk menterjemahkan alamat web yang mudah difahami dan ingat yang kita kenal dengan (URL), ke alamat IP berangka "benar" mereka. Sebagai contoh, menterjemahkan nama domain www.proprivacy.com ke alamat IPv4nya iaitu 104.20.239.134. Jadi di DNS jantung hanyalah buku telefon mewah yang sepadan dengan URL ke alamat IP mereka yang sepadan.

Proses terjemahan DNS ini biasanya dilakukan oleh pelayan DNS yang dijalankan oleh penyedia internet anda (ISP). Dengan ISP yang lebih besar, kemungkinan pertanyaan DNS akan diselesaikan secara geografi berdekatan dengan anda (misalnya di suatu tempat di bandar anda), tetapi ini tidak selalu berlaku.

Apa yang pasti adalah bahawa DNS quires akan diselesaikan di negara anda berdasarkan ISP anda (iaitu negara anda sendiri). Di mana pun pertanyaan DNS diselesaikan, walaupun, ia tidak akan berada di alamat IP rumah anda. Tetapi ...

Risiko privasi

ISP anda dapat melihat apa yang anda raih

ISP anda yang menyelesaikan pertanyaan DNS anda, jadi:

  1. Ia tahu alamat IP yang mereka hasilkan.
  2. Ia tahu laman web yang anda lawati kerana ia merupakan terjemahan URL yang anda taip ke alamat IP. Kebanyakan ISP di seluruh dunia menyimpan log maklumat ini, yang mana mereka mungkin atau mungkin tidak berkongsi dengan pasukan kerajaan atau polis anda sebagai perkara rutin, tetapi mereka sentiasa boleh dipaksa untuk berkongsi.

Sekarang ... dalam hal biasa hal-hal ini tidak terlalu penting kerana ISP anda yang menghubungkan anda langsung ke alamat IP yang anda lawati. Jadi ia tahu laman web mana yang anda lawati.

Pelayan VPN proksi sambungan internet anda, bagaimanapun, untuk menghalang ISP anda daripada melihat apa yang anda bangun di internet. Kecuali ia masih menyelesaikan pertanyaan DNS anda, dalam hal ini ia masih dapat (secara tidak langsung) melihat laman web yang anda lawati.

Anda boleh dikesan

Laman web boleh melihat dan log alamat IP pelayan DNS yang mengarahkan sambungan kepada mereka. Mereka tidak akan tahu alamat IP unik anda dengan cara ini, tetapi mereka akan tahu yang ISP diselesaikan pertanyaan DNS dan secara rutin mencipta cap waktu apabila ia berlaku.

Sekiranya mereka (atau pihak polis misalnya) ingin mengenal pasti pengunjung, mereka hanya perlu bertanya kepada ISP "yang membuat permintaan DNS ke alamat ini pada masa ini?"

Sekali lagi, dalam hal perkara biasa, ini tidak relevan, kerana laman web dapat melihat alamat IP unik anda. Tetapi apabila anda menyembunyikan alamat IP anda dengan VPN, ia menjadi satu cara penting untuk "menghidupkan tanpa nama" pengguna VPN.

Bagaimana kebocoran DNS berlaku

Secara teori, apabila menggunakan VPN semua permintaan DNS harus dihantar melalui VPN, di mana mereka boleh ditangani secara dalaman oleh pembekal VPN atau proksied kepada pihak ketiga yang hanya akan melihat permintaan itu datang dari pelayan VPN.

Malangnya, sistem pengendalian kadangkala gagal mengemukakan pertanyaan DNS melalui antara muka VPN dan sebaliknya menghantarnya ke pelayan DNS lalai yang dinyatakan dalam tetapan sistem (yang akan menjadi pelayan DNS ISP anda melainkan anda menukar tetapan DNS secara manual).

Penyelesaian

1. Gunakan klien VPN dengan perlindungan kebocoran DNS

Ramai pelanggan VPN menangani masalah ini dengan ciri "perlindungan kebocoran DNS". Ini menggunakan peraturan firewall untuk memastikan tiada permintaan DNS yang boleh dihantar di luar terowong VPN. Malangnya, langkah-langkah ini tidak selalu berkesan.

Kami tidak faham mengapa "perlindungan kebocoran DNS" sering merupakan ciri yang boleh dipilih pengguna yang tidak didayakan secara lalai.

Sekali lagi, OpenVPN GUI untuk Windows, Tunnelblick untuk macOS, OpenVPN untuk Android, dan OpenVPN Connect untuk iOS (dan platform lain) semua menawarkan perlindungan kebocoran DNS yang baik.

2. Matikan IPv6

Perhatikan bahawa ini hanya penyelesaian separa, kerana ia tidak menghalang kebocoran DNS IPv4. Tetapi salah satu sebab utama bahawa walaupun aplikasi VPN yang mempunyai perlindungan kebocoran DNS gagal untuk menghalang kebocoran DNS adalah bahawa mereka hanya permintaan DNS firewall untuk pelayan DNS IPv4.

Memandangkan kebanyakan pelayan DNS kekal IPv4-sahaja, mereka sering boleh lari dengan ini. Tetapi ISP yang menawarkan sambungan IPv6 juga biasanya menawarkan pelayan DNS IPv6. Oleh itu, sekiranya pelanggan hanya menyekat permintaan DNS IPv4 di luar antara muka VPN maka IPv6 boleh dilalui.

3. Tukar tetapan DNS anda

Pertanyaan DNS yang tidak disengajakan yang tidak membuat laluan melalui antara muka VPN (sebagaimana mestinya) akan dihantar kepada pelayan DNS lalai yang ditentukan dalam tetapan sistem anda.

Kecuali anda telah menukar ini, maka alamat pelayan DNS (IPv4 dan IPv6 jika tersedia) akan diperoleh secara automatik dari ISP anda. Tetapi anda boleh mengubahnya, dan kami mempunyai arahan untuk melakukannya di sini.

Perhatikan bahawa mengubah tetapan DNS anda tidak benar-benar "membetulkan" masalah kebocoran DNS. Hanya saja anda membocorkan permintaan DNS kepada resolver pihak ketiga dan bukannya ISP anda.

Nasib baik, kini terdapat beberapa perkhidmatan DNS yang berfokus pada privasi yang sangat baik yang tidak menyimpan sebarang log. Mereka juga melindungi permintaan DNS dengan DNS melalui HTTPS (DoH) atau DNS melalui penyulitan DNS TLS (DoT), tanpa ISP anda boleh melihat permintaan DNS, walaupun, walaupun ia tidak mengendalikannya.

Untuk maklumat lanjut tentang subjek ini, ditambah dengan senarai perkhidmatan DNS percuma dan swasta yang disyorkan, sila lihat di sini.

Nota untuk pengguna Linux

Persediaan VPN manual di Linux, sama ada menggunakan NetworkManager, klien CLI OpenVPN, strongSwan, atau apa sahaja, tidak memberikan perlindungan kebocoran DNS. Mujurlah, terdapat beberapa langkah yang boleh anda ambil untuk menyelesaikan masalah ini, walaupun ia merumitkan proses persediaan VPN.

Anda boleh mengubah resolvconf untuk menolak DNS ke pelayan DNS VPN anda, atau anda boleh mengkonfigurasi firewall iptables secara manual untuk memastikan semua lalu lintas (termasuk permintaan DNS) tidak dapat meninggalkan mesin Linux anda di luar terowong VPN. Sila lihat nota kami untuk membina firewall anda sendiri kemudian di artikel ini untuk lebih lanjut mengenai ini.

Kebocoran WebRTC

Kebocoran WebRTC kini merupakan kebocoran IP yang paling biasa yang kita lihat dalam ujian kami. Sebenarnya, kebocoran WebRTC adalah isu pelayar, bukan isu VPN, yang telah menyebabkan banyak penyedia VPN menjauhkan diri dari masalah yang tidak mudah untuk diperbaiki.

Dalam pandangan kami, ini tidak cukup baik. Sesungguhnya, kami juga tidak menganggap bahawa penerbitan panduan "Cara Nonaktifkan WebRTC" yang tersembunyi di dalam seksyen bantuan pembekal adalah cukup baik, sama ada.

Apakah kebocoran WebRTC??

WebRTC adalah platform HTML5 yang membolehkan komunikasi suara dan video lancar di dalam tetingkap pelayar pengguna. Hampir semua pelayar moden pada hampir semua platform utama kini menyokong WebRTC, termasuk Chrome, Firefox, Opera, Edge, Safari, dan Brave.

Pengecualian adalah dalam IOS, di mana hanya Safari menyokong WebRTC (sekurang-kurangnya tanpa plugin tambahan).

Untuk mencapai komunikasi peramban-ke-penyemak imbas yang lancar melalui halangan seperti firewall, penyemak imbas yang membolehkan WebRTC menyiarkan alamat IP sebenar anda ke pelayan STUN yang menyimpan senarai alamat IP awam dan alamat IP sebenar mereka..

Sesiapa yang ingin memulakan perbualan WebRTC dengan anda (atau hanya mana-mana laman web yang baik) boleh meminta alamat IP sebenar anda dan pelayan STUN hanya akan menyerahkannya.

Biasanya disebut sebagai kebocoran WebRTC, masalah ini kadang-kadang dipanggil "bug WebRTC." Yang merupakan salah satu kesalahan kerana ia adalah ciri yang disengajakan dan sangat berguna dari WebRTC. Tetapi ia adalah kesakitan yang nyata untuk pengguna VPN yang cuba menyembunyikan alamat IP sebenar mereka!

Penyelesaian

1. Lumpuhkan WebRTC di pelayar anda

Ini adalah satu-satunya cara berkesan 100% untuk mencegah kebocoran WebRTC apabila menggunakan VPN. Kami mengesyorkan untuk melakukannya walaupun klien VPN anda berkesan untuk mengurangkan kebocoran VPN.

Di Firefox, mudah untuk melumpuhkan WebRTC. Ketik "about: config" ke dalam bar URL untuk memasukkan tetapan lanjutan Firefox, cari "media.peerconnection.enabled," dan klik dua kali pada entri untuk mengubah nilainya ke false.

Sebagai alternatif (dan dalam penyemak imbas lain), terdapat pelbagai penyemak imbas pelayar boleh melumpuhkan WebRTC, termasuk Lumpuhkan WebRTC, uBlock, uBlock Asal dan NoScript. Sesetengah penyedia VPN termasuk ciri Disable WebRTC dalam alat penyemak imbas kustom mereka.

Perbincangan yang lebih lengkap mengenai subjek ini boleh didapati di Apa yang WebRTC VPN "Bug" dan Bagaimana Betulkan Ia?

2. Gunakan perkhidmatan VPN yang meringankan kebocoran WebRTC

Kebocoran WebRTC adalah isu penyemak imbas, jadi satu-satunya cara yang berkesan untuk menghalangnya ialah dengan melumpuhkan WebRTC dalam penyemak imbas.

Yang mengatakan, penyedia VPN boleh menggunakan peraturan firewall dan mengetatkan tetapan pada kedua-dua klien dan tahap VPN untuk mengurangkan kemungkinan kebocoran WebRTC berlaku. Tiada pembekal VPN akan menjamin bahawa langkah-langkah ini berfungsi kerana selalu ada kemungkinan untuk tapak web untuk melaksanakan kode JavaScript yang cerdas yang dirancang untuk meningkatkan kebocoran kebocoran.

Walau bagaimanapun, kami mendapati bahawa sesetengah perkhidmatan VPN secara konsisten berkesan untuk mencegah kebocoran VPN. Kami masih mencadangkan melumpuhkan WebRTC pada tahap penyemak imbas walaupun dengan ini. Hanya berada di tempat yang selamat.

Dropouts VPN dan bunuh suis

Walaupun tidak secara teknikal "kebocoran IP," kerana masalahnya berlaku tepat kerana anda tidak mempunyai sambungan VPN, kesannya sama - anda fikir anda dilindungi oleh VPN, padahal sebenarnya seluruh dunia dapat melihat alamat IP anda.

Apakah penurunan VPN??

Kadangkala sambungan VPN gagal, sering sebab-sebab di luar kawalan walaupun perkhidmatan VPN yang terbaik. . Jika komputer anda masih bersambung ke internet selepas ini berlaku, maka IP sebenar anda akan didedahkan.

Ini amat menjadi masalah untuk pengundian P2P yang meninggalkan pelanggan BitTorrent yang sedang berjalan semasa mereka berada jauh dari komputer mereka (selalunya dalam masa yang lama). Sekiranya sambungan VPN jatuh, IP benar mereka terdedah kepada mana-mana penguatkuasa hak cipta yang menjejaki torrent yang mereka muat turun.

Ia juga menjadi masalah untuk pengguna mudah alih, seperti menukar antara WiFi dan rangkaian mudah alih, dan menukar rangkaian mudah alih, boleh menyebabkan penurunan VPN.

Penyelesaian

1. Gunakan suis bunuh

Suis bunuh menghalang peranti anda dari menyambung ke internet apabila VPN tidak berfungsi. Hampir semua suis bunuh moden sebenarnya firewall atau peraturan firewall peringkat sistem yang menyekat semua sambungan internet di luar antara muka VPN.

Jadi, jika perisian VPN gagal atau perlu menyambung semula, maka semua akses ke internet disekat. Memang, peraturan firewall yang sama memberikan perlindungan kebocoran DNS yang berkesan dan dapat membantu menangani kebocoran WebRTC.

Bunuh suis kini menjadi ciri yang sangat umum dalam pelanggan VPN desktop, walaupun jarang dalam aplikasi mudah alih. Walau bagaimanapun, Android 7+ termasuk suis bunuh terbina dalam yang berfungsi dengan aplikasi VPN yang dipasang.

Apl VPN boleh menggunakan firewall mereka sendiri untuk membuat suis bunuh (dan perlindungan kebocoran yang lain) atau boleh mengubah suai firewall terbina dalam sistem anda. Kami lebih suka penyelesaian terakhir kerana suis bunuh akan bertahan walaupun aplikasi itu benar-benar terhempas. Tetapi mana-mana suis membunuh jauh lebih baik daripada tiada.

Bina suis bunuh anda sendiri dan perlindungan kebocoran DNS menggunakan peraturan firewall

Seperti yang telah kita lihat, banyak aplikasi VPN menggunakan peraturan firewall mereka sendiri atau mengubah peraturan firewall sistem anda untuk membuat suis membunuh dan mencegah kebocoran DNS. Ia adalah mungkin untuk anda melakukan perkara yang sama secara manual.

Butiran berbeza dengan program OS dan firewall, tetapi prinsip asasnya adalah:

1. Tambah peraturan yang menghalang semua lalu lintas keluar dan masuk pada sambungan internet anda.

2. Tambah pengecualian untuk alamat IP penyedia VPN anda.

3. Tambah peraturan untuk penyesuai TUN / Ketik anda (jika menggunakan OpenVPN, atau untuk mana-mana peranti VPN yang lain) untuk membolehkan semua lalu lintas keluar untuk terowong VPN.

Kami mempunyai panduan terperinci untuk melakukan ini menggunakan Comodo Firewall untuk Windows. Pengguna Mac boleh melakukan perkara yang sama menggunakan Little Snitch, sementara pengguna Linux dan mereka yang menjalankan klien VPN pada penghala DD-WRT boleh menggunakan iptables.

Brayan Jackson
Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me