VPN vs proksi: apa yang dilindungi oleh setiap satu dan apa yang tidak

Kedua-dua VPN dan proksi hadapan mengubah alamat yang dilihat oleh laman web, dan di situlah kebanyakan perbandingan berhenti. Perbezaan yang menentukan persediaan anda ialah liputan: proksi hadapan ialah perantara yang dipilih oleh aplikasi anda sendiri untuk digunakan, berbeza daripada proksi songsang yang terletak di hadapan laman web, manakala VPN memindahkan semua yang dihalakan sistem pengendalian ke dalam terowong. Penyulitan, pengendalian DNS dan tingkah laku kegagalan semuanya berpunca daripada pembahagian itu. Jalankan lima semakan ini mengikut urutan, dan yang pertama gagal akan memberitahu alat mana yang sebenarnya anda perlukan.

Aplikasi mana yang diliputi oleh perantara itu?

Sambungan proksi dalam pelayar hanya terpakai pada profil pelayar itu. Klien mel, pengurus pakej dan pelayar kedua terus menggunakan tetapan mereka sendiri, dan sesetengah aplikasi mengabaikan pemboleh ubah proksi sistem sepenuhnya. VPN meliputi apa yang dihantar oleh jadual penghalaan ke dalam terowong, dan itu boleh menjadi semua aplikasi atau subset dalam terowong berpecah bergantung pada laluan dan dasar klien.

Uji aplikasi yang penting dan bukannya membuat generalisasi daripada satu muatan halaman. curl https://ifconfig.me mengikut pemboleh ubah proksi persekitaran; aplikasi desktop mungkin tidak. Dalam Windows, netsh winhttp show proxy mencetak proksi WinHTTP yang digunakan oleh perkhidmatan, dan itu tetapan yang berbeza daripada pelayar.

Adakah lonjakan itu disulitkan, dan di mana TLS berakhir?

Protokol proksi ialah tempat pertemuan, bukan jaminan. SOCKS5 memajukan TCP tanpa menyulitkannya, dan proksi HTTP biasa membawa baris permintaan dan pengepala dalam teks jelas. HTTPS melalui proksi menggunakan CONNECT, jadi sesi TLS anda masih berakhir di destinasi, bukan di proksi. Panduan MDN tentang pelayan proksi dan penerowongan menerangkan perbezaan itu dari sisi protokol.

VPN menyulitkan segmen antara peranti anda dan titik akhirnya. Di luar titik akhir, peraturan yang sama terpakai seperti pada rangkaian lain, itulah sebabnya terowong sahaja tidak melindungi aplikasi yang menghantar kelayakan melalui HTTP biasa. Tiada satu pun reka bentuk itu menyembunyikan akaun yang telah log masuk, kuki atau cap jari pelayar.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

Output terperinci menunjukkan sama ada curl menghantar CONNECT ke port 443 atau GET biasa dengan URL penuh. Dengan socks5h:// nama hos diberikan kepada proksi di dalam permintaan SOCKS5 dan kemudiannya memajukan TLS yang tidak dapat dibacanya, jadi ia melihat nama dan bilangan bait. Melalui proksi http://, URL https:// ialah CONNECT, jadi proksi itu juga melihat nama dan jumlah destinasi, tetapi bukan permintaan atau badan respons.

Penyelesai mana yang melihat nama itu?

Penyelesaian nama boleh berlaku secara setempat sebelum permintaan keluar, atau dari jauh di proksi. Dengan curl, socks5h:// menghantar nama hos kepada proksi manakala socks5:// menyelesaikannya secara setempat dahulu. Tetapan proksi pelayar menawarkan pilihan DNS yang setanding, dan fail PAC boleh menghalakan hos berbeza dengan cara berbeza.

Dua protokol boleh memintas proksi tanpa sebarang salah konfigurasi. WebRTC mengumpul calon melalui STUN, dan QUIC menjalankan HTTP/3 di atas UDP, yang tidak dapat dibawa oleh proksi TCP. Pelayar akan kembali ke TCP jika UDP 443 disekat, jadi menyekat UDP 443 pada tembok api hos (atau pada penghala untuk seluruh rangkaian), bukan bendera pelayar, ialah cara yang boleh dipercayai untuk mengekalkan HTTP/3 dalam laluan proksi.

Semak penyelesai dari sudut pandangan destinasi, bukan dari komputer riba anda. Permintaan yang tiba dengan alamat keluar proksi tetapi dengan nama yang diselesaikan secara setempat masih memberitahu penyelesai setempat laman mana yang anda lawati.

Apa yang berlaku apabila perantara gagal?

Proksi eksplisit gagal tertutup: hentikan proses proksi dan pelayar atau aplikasi mengembalikan ralat sambungan dan bukannya pergi terus. Persediaan PAC dan WPAD ialah yang gagal terbuka - jika skrip tidak dapat diambil, klien kembali ke DIRECT dan laman melihat alamat sebenar anda semula. VPN boleh gagal terbuka atau tertutup bergantung pada klien dan sama ada suis bunuh atau peraturan tembok api aktif.

Uji kes kegagalan dengan sengaja: hentikan perkhidmatan proksi dan muat semula; jika anda mendapat halaman ralat dan bukannya muatan terus, halakan URL PAC ke hos yang tidak dapat dicapai untuk melihat sandaran. Jika halaman masih dimuatkan melalui laluan biasa anda, proksi tidak menawarkan perlindungan terhadap gangguan sendiri, dan itu sifat yang patut anda ketahui sebelum bergantung padanya.

Urutan menentukan apa yang dilihat oleh laman. Proksi yang trafik keluarnya melalui VPN membiarkan laman melihat alamat titik akhir VPN; letakkan proksi di luar terowong (VPN ke proksi pada hos jauh) dan laman akan melihat alamat keluar proksi itu pula. Dalam apa jua keadaan, kedua-dua lonjakan boleh merekod perkara yang berbeza.

Lima semakan, mengikut urutan

Senarai semak di bawah ialah keseluruhan keputusan di satu tempat. Liputan datang dahulu kerana ia menghapuskan kebanyakan ketidakpadanan: jika aplikasi yang perlu diliputi tidak menghormati tetapan itu, tiada apa lagi dalam senarai yang menyelamatkannya.

Kemudian sahkan hasilnya dengan aplikasi yang mencetuskan perubahan. Muatkan halaman dalam pelayar yang dikonfigurasikan, dapatkan halaman yang sama dengan curl, dan bandingkan alamat yang dilaporkan oleh setiap satu. Jika mereka tidak bersetuju, sambungan, peraturan PAC atau penggantian peringkat aplikasi masih berkuat kuasa, dan tiada penalaan terowong akan membetulkannya.

Catatkan apa yang anda konfigurasikan: aplikasi mana yang menggunakan proksi, sama ada DNS setempat atau jauh, sama ada UDP disekat, dan apakah tingkah laku kegagalan. Inventori kecil itulah yang menjadikan perbandingan seterusnya mungkin, kerana “IP berubah” tidak pernah memberitahu anda yang mana antara lima semakan ini lulus.