Portal captive dan VPN buntu: siapa bergerak lebih dulu

Portal hotel ingin melihat peramban sebelum meloloskan lalu lintas apa pun. VPN Anda menolak meloloskan lalu lintas sebelum terowongannya aktif. Kedua pihak menunggu satu sama lain, dan keduanya berperilaku persis seperti dikonfigurasi. Hanya dua urutan yang memutus kebuntuan itu, dan keduanya berbeda dalam apa yang diungkap selama celah masih terbuka. Pilih satu dengan sengaja alih-alih mengutak-atik pengaturan apa pun yang membuat peramban termuat.

Dua urutan, salah satunya berhasil

Entah jaringan menerima Anda lebih dulu dan terowongan menyusul, atau Anda membuka pengecualian sempit untuk portal lalu memulihkan blokir sesudahnya. Keduanya sah. Yang tidak sah adalah mematikan blokir lalu lupa mengembalikannya.

Kedua urutan tidak sama baiknya dalam setiap situasi. Perangkat terkelola dengan proses penerimaan wajib punya satu jawaban, dan laptop pribadi di Wi-Fi hotel punya jawaban lain. Perbandingannya adalah tentang apa yang dilepas setiap opsi.

Mulailah dengan mengetahui mana yang benar-benar didukung klien dan kebijakan perangkat Anda.

Opsi A: terima jaringan, lalu sambungkan terowongan

Konfirmasi nama jaringan yang diharapkan, lalu gunakan permintaan masuk sistem operasi atau alur portal captive yang didukung klien. Di iPhone dan iPad, menutup lembar masuk bisa memutus asosiasi atau mempertahankannya dengan peringatan bahwa jaringan tidak punya internet, dan itu titik awal yang berbeda. Selesaikan dulu langkah penerimaan, baru naikkan terowongan. Urutan ini menjaga blokir tetap utuh sepanjang waktu terowongan mati.

Jebakannya adalah portal yang mengizinkan akses internet tidak mengautentikasi akun VPN Anda. Terowongan tetap harus tersambung sesudahnya, dan bisa gagal karena alasannya sendiri. Penerimaan dan autentikasi adalah peristiwa terpisah yang orang lebur menjadi satu.

Jika penerimaan terus kedaluwarsa, catat apakah portal bertanya lagi, jaringan terputus, atau hanya VPN yang gagal.

Opsi B: pengecualian masuk yang sempit, lalu pulihkan blokir

Alternatifnya adalah mengizinkan lalu lintas portal sementara blokir tetap berlaku di bagian lain, masuk, lalu hapus pengecualian. Pengecualian harus sempit: satu tujuan atau satu rentang alamat, selama proses masuk, dengan blokir dipulihkan segera sesudahnya. Jendela sementara yang lebar adalah cara masuk dua menit menjadi sepanjang sore lalu lintas tanpa perlindungan.

Ketahui apa yang benar-benar diterapkan klien Anda. OpenVPN Connect di macOS mendokumentasikan deteksi portal captive secara terpisah dari opsinya yang memblokir akses internet saat VPN dijeda atau menyambung ulang. Mendeteksi portal dan mengizinkan lalu lintasnya adalah tugas yang berkaitan, bukan janji yang bisa dipertukarkan.

Di perangkat terkelola, ikuti proses penerimaan yang dikonfigurasi alih-alih mengarang pengecualian.

Apa yang diungkap celah itu, dan kepada siapa

Bagian menarik dari kebuntuan ini bukan tab peramban di depan Anda. Melainkan semua hal lain yang mulai memakai jaringan begitu konektivitas muncul: surel, sinkronisasi foto, pemeriksaan pembaruan, klien obrolan yang menyambung ulang, agen cadangan yang melanjutkan.

Jendela peramban yang tenang tidak memberi tahu apa pun tentang itu. Tutup atau jeda pekerjaan sensitif sebelum setiap interval akses langsung yang diizinkan, dan periksa apa yang berjalan saat masuk. Di Android, VPN selalu aktif yang dipadukan dengan pemblokiran koneksi di luar VPN adalah kontrol yang relevan, dan pengecualian rute sembarangan bukan pengganti untuk memahaminya.

Inilah satu-satunya tempat nasihat lama tentang jendela akses sementara masih berlaku. Kekhawatirannya benar bahkan ketika mekanismenya tidak.

Cara memilih dan cara memastikannya

Pilih Opsi A ketika perangkat atau klien mendukung alur portal sungguhan, karena itu menjaga blokir tetap utuh sepanjang waktu. Pilih Opsi B ketika portal tidak dapat dijangkau dengan cara lain, dan perlakukan pengecualian sebagai perubahan berbatas waktu dengan penanggung jawab.

Lalu pastikan urutannya, bukan hasilnya:

curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'

Selesaikan penerimaan, bangun profil yang dimaksud, pulihkan kontrol pemblokiran apa pun yang sempat diubah, lalu buat permintaan baru yang tidak berbahaya dan pastikan permintaan itu mengikuti terowongan. Permintaan yang berhasil karena blokir masih mati tidak membuktikan apa pun tentang terowongan.

Mengganti jalan keluar VPN tidak akan memperbarui sesi hotel yang kedaluwarsa. Itu peristiwa yang berbeda, dan mencampuradukkannya membuat Anda mencari di tempat yang salah.