VPN vs proxy: apa yang dicakup masing-masing dan apa yang tidak

VPN dan proxy forward sama-sama mengubah alamat yang dilihat situs web, dan di situlah sebagian besar perbandingan berhenti. Perbedaan yang menentukan pengaturan Anda adalah cakupan: proxy forward adalah perantara yang dipilih aplikasi Anda sendiri untuk digunakan, berbeda dari proxy reverse yang berada di depan situs web, sedangkan VPN memindahkan semua yang dirutekan sistem operasi ke dalam terowongan. Enkripsi, penanganan DNS, dan perilaku saat gagal semuanya mengikuti pembagian itu. Jalankan lima pemeriksaan ini secara berurutan, dan yang pertama gagal akan memberi tahu alat mana yang sebenarnya Anda butuhkan.

Aplikasi mana yang dicakup perantara itu?

Ekstensi proxy di peramban hanya berlaku untuk profil peramban tersebut. Klien email, pengelola paket, dan peramban kedua tetap memakai pengaturannya sendiri, dan sebagian aplikasi sepenuhnya mengabaikan variabel proxy sistem. VPN mencakup apa yang dikirim tabel perutean ke terowongan, yang bisa berarti semua aplikasi atau sebagian saja pada terowongan terpisah tergantung rute dan kebijakan klien.

Uji aplikasi yang penting alih-alih menggeneralisasi dari satu pemuatan halaman. curl https://ifconfig.me mengikuti variabel proxy lingkungan; aplikasi desktop mungkin tidak. Di Windows, netsh winhttp show proxy mencetak proxy WinHTTP yang dipakai layanan, dan itu pengaturan yang berbeda dari pengaturan peramban.

Apakah lompatan itu terenkripsi, dan di mana TLS berakhir?

Protokol proxy adalah titik temu, bukan jaminan. SOCKS5 meneruskan TCP tanpa mengenkripsinya, dan proxy HTTP biasa membawa baris permintaan serta header dalam teks polos. HTTPS melalui proxy memakai CONNECT, jadi sesi TLS Anda tetap berakhir di tujuan, bukan di proxy. Panduan MDN tentang server proxy dan terowongan menjelaskan perbedaan itu dari sisi protokol.

VPN mengenkripsi segmen antara perangkat Anda dan titik akhirnya. Di luar titik akhir, aturan yang sama berlaku seperti pada jaringan lain, itulah sebabnya terowongan saja tidak melindungi aplikasi yang mengirim kredensial melalui HTTP polos. Tidak ada dari kedua desain itu yang menyembunyikan akun yang sudah masuk, cookie, atau sidik jari peramban.

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

Keluaran verbose menunjukkan apakah curl mengirim CONNECT ke port 443 atau GET biasa dengan URL lengkap. Dengan socks5h:// nama host diserahkan ke proxy di dalam permintaan SOCKS5 lalu proxy meneruskan TLS yang tidak bisa dibacanya, sehingga ia melihat nama dan jumlah byte. Melalui proxy http://, URL https:// adalah CONNECT, jadi proxy itu juga melihat nama dan volume tujuan, bukan permintaan atau isi respons.

Resolver mana yang melihat nama itu?

Resolusi nama bisa terjadi secara lokal sebelum permintaan keluar, atau dari jarak jauh di proxy. Dengan curl, socks5h:// mengirim nama host ke proxy sementara socks5:// menyelesaikannya secara lokal lebih dulu. Pengaturan proxy peramban menawarkan opsi DNS yang sebanding, dan berkas PAC dapat merutekan host berbeda dengan cara berbeda.

Dua protokol dapat melewati proxy tanpa kesalahan konfigurasi apa pun. WebRTC mengumpulkan kandidat melalui STUN, dan QUIC menjalankan HTTP/3 di atas UDP, yang tidak dapat dibawa proxy TCP. Peramban akan kembali ke TCP jika UDP 443 diblokir, jadi memblokir UDP 443 di firewall host (atau di router untuk seluruh jaringan), bukan bendera peramban, adalah cara andal untuk menjaga HTTP/3 tetap di jalur proxy.

Periksa resolver dari sudut pandang tujuan, bukan dari laptop Anda. Permintaan yang datang dengan alamat keluar proxy tetapi dengan nama yang diresolusikan secara lokal tetap memberi tahu resolver lokal situs mana yang Anda kunjungi.

Apa yang terjadi ketika perantara gagal?

Proxy eksplisit gagal tertutup: hentikan proses proxy dan peramban atau aplikasi mengembalikan kesalahan koneksi alih-alih langsung pergi. Pengaturan PAC dan WPAD adalah yang gagal terbuka - jika skrip tidak dapat diambil, klien kembali ke DIRECT dan situs melihat alamat asli Anda lagi. VPN dapat gagal terbuka atau tertutup tergantung klien dan apakah kill switch atau aturan firewall aktif.

Uji kasus kegagalan dengan sengaja: hentikan layanan proxy dan muat ulang; jika Anda mendapat halaman kesalahan alih-alih pemuatan langsung, arahkan URL PAC ke host yang tidak terjangkau untuk melihat fallback. Jika halaman masih dimuat melalui rute biasa Anda, proxy tidak menawarkan perlindungan terhadap gangguannya sendiri, dan itu sifat yang perlu Anda ketahui sebelum mengandalkannya.

Urutan menentukan apa yang dilihat situs. Proxy yang lalu lintas keluarnya melewati VPN membuat situs melihat alamat titik akhir VPN; letakkan proxy di luar terowongan (VPN ke proxy di host jarak jauh) dan situs akan melihat alamat keluar proxy itu sebagai gantinya. Bagaimanapun, kedua lompatan dapat mencatat hal yang berbeda.

Lima pemeriksaan, secara berurutan

Daftar periksa di bawah ini adalah seluruh keputusan di satu tempat. Cakupan didahulukan karena menghilangkan sebagian besar ketidakcocokan: jika aplikasi yang harus dicakup tidak menghormati pengaturan itu, tidak ada yang lebih jauh dalam daftar yang menyelamatkannya.

Lalu konfirmasi hasilnya dengan aplikasi yang memicu perubahan. Muat halaman di peramban yang dikonfigurasi, ambil halaman yang sama dengan curl, dan bandingkan alamat yang dilaporkan masing-masing. Jika keduanya tidak sepakat, ada ekstensi, aturan PAC, atau penggantian tingkat aplikasi yang masih berperan, dan tidak ada penyetelan terowongan yang akan memperbaikinya.

Catat apa yang Anda konfigurasikan: aplikasi mana yang memakai proxy, apakah DNS lokal atau jarak jauh, apakah UDP diblokir, dan bagaimana perilaku saat gagal. Inventaris kecil itulah yang membuat perbandingan berikutnya mungkin, karena “IP-nya berubah” tidak pernah memberi tahu Anda yang mana dari lima pemeriksaan ini yang lulus.