Portal captive dan VPN buntu: siapa bergerak dahulu

Portal hotel mahu melihat pelayar sebelum membenarkan sebarang trafik melalui. VPN anda enggan membenarkan trafik melalui sebelum terowongnya naik. Setiap pihak menunggu pihak yang lain, dan kedua-duanya berkelakuan tepat seperti dikonfigurasikan. Hanya dua urutan memecahkan kebuntuan itu, dan kedua-duanya berbeza dalam apa yang didedahkan semasa jurang masih terbuka. Pilih satu dengan sengaja dan bukannya menogol mana-mana tetapan yang membuat pelayar dimuatkan.

Dua urutan, satu daripadanya berkesan

Sama ada rangkaian menerima anda dahulu dan terowong menyusul, atau anda membuka pengecualian sempit untuk portal dan memulihkan sekatan itu selepasnya. Kedua-duanya wajar. Yang tidak wajar ialah mematikan sekatan dan lupa memulihkannya.

Kedua-dua urutan tidak sama baik dalam setiap keadaan. Peranti terurus dengan proses kemasukan wajib mempunyai satu jawapan, dan komputer riba peribadi di Wi-Fi hotel mempunyai jawapan yang lain. Perbandingan ini tentang apa yang dilepaskan oleh setiap pilihan.

Mulakan dengan mengetahui mana satu yang benar-benar disokong oleh klien dan dasar peranti anda.

Pilihan A: terima rangkaian, kemudian sambungkan terowong

Sahkan nama rangkaian yang dijangka, kemudian gunakan gesaan log masuk sistem pengendalian atau aliran portal captive yang disokong klien. Pada iPhone dan iPad, menutup helaian log masuk boleh sama ada memutuskan perkaitan atau mengekalkannya dengan amaran bahawa rangkaian tiada internet, dan itu titik permulaan yang berbeza. Selesaikan langkah kemasukan dahulu, kemudian naikkan terowong. Urutan ini mengekalkan sekatan utuh sepanjang masa terowong tidak naik.

Perangkapnya ialah portal yang membenarkan akses internet tidak mengesahkan akaun VPN anda. Terowong masih perlu bersambung selepas itu, dan ia boleh gagal atas sebabnya sendiri. Kemasukan dan pengesahan ialah peristiwa berasingan yang orang gabungkan menjadi satu.

Jika kemasukan terus tamat tempoh, catat sama ada portal bertanya lagi, rangkaian terputus, atau hanya VPN yang gagal.

Pilihan B: pengecualian log masuk yang sempit, kemudian pulihkan sekatan

Alternatifnya ialah membenarkan trafik portal sementara sekatan kekal berkuat kuasa di tempat lain, log masuk, dan kemudian buang pengecualian itu. Pengecualian mesti sempit: satu destinasi atau satu julat alamat, untuk tempoh log masuk, dengan sekatan dipulihkan sejurus selepasnya. Tetingkap sementara yang luas ialah cara log masuk dua minit menjadi sebelah petang trafik tanpa perlindungan.

Ketahui apa yang sebenarnya dilaksanakan oleh klien anda. OpenVPN Connect pada macOS mendokumenkan pengesanan portal captive secara berasingan daripada pilihannya yang menyekat akses internet semasa VPN dijeda atau bersambung semula. Mengesan portal dan membenarkan trafiknya ialah tugas yang berkaitan, bukan janji yang boleh ditukar ganti.

Pada peranti terurus, ikut proses kemasukan yang dikonfigurasikan dan bukannya mencipta pengecualian sendiri.

Apa yang didedahkan oleh jurang itu, dan kepada siapa

Bahagian menarik dalam kebuntuan ini bukan tab pelayar di hadapan anda. Tetapi segala-galanya yang mula menggunakan rangkaian pada saat kesambungan muncul: mel, penyegerakan foto, pemeriksaan kemas kini, klien sembang yang bersambung semula, agen sandaran yang menyambung semula kerjanya.

Tetingkap pelayar yang sunyi tidak memberitahu apa-apa tentang itu. Tutup atau jeda kerja sensitif sebelum setiap selang akses terus yang dibenarkan, dan periksa apa yang berjalan semasa log masuk. Pada Android, VPN sentiasa hidup digabungkan dengan menyekat sambungan di luar VPN ialah kawalan yang berkaitan, dan pengecualian laluan sewenang-wenangnya bukan pengganti untuk memahaminya.

Inilah satu-satunya tempat nasihat lama tentang tetingkap akses sementara masih terpakai. Kebimbangan itu betul walaupun mekanismenya tidak.

Cara memilih dan cara mengesahkannya

Pilih Pilihan A apabila peranti atau klien menyokong aliran portal sebenar, kerana ia mengekalkan sekatan utuh sepanjang masa. Pilih Pilihan B apabila portal tidak boleh dicapai dengan cara lain, dan anggap pengecualian itu sebagai perubahan terhad masa dengan pemilik.

Kemudian sahkan urutannya, bukan hasilnya:

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

Selesaikan kemasukan, tetapkan profil yang dimaksudkan, pulihkan mana-mana kawalan sekatan yang diubah sementara, kemudian buat permintaan baharu yang tidak berbahaya dan sahkan ia mengikut terowong. Permintaan yang berjaya kerana sekatan masih mati tidak membuktikan apa-apa tentang terowong.

Menukar jalan keluar VPN tidak akan memperbaharui sesi hotel yang tamat tempoh. Itu peristiwa berbeza, dan mengelirukannya membuatkan anda mencari di tempat yang salah.