Mengapa portal penahan memblokir VPN Anda, dan cara masuk kembali

Di jaringan terbuka, titik akses Anda tidak serta-merta menyerahkan paket ke internet. Titik kebijakan di hulu memeriksa apakah perangkat Anda sudah diotorisasi, dan sampai itu terjadi, hampir semuanya dibuang. Klien VPN Anda membaca kesunyian itu sebagai server mati. Ia jarang mengatakannya: WireGuard mengulang jabat tangan ke kehampaan, OpenVPN melaporkan waktu tunggu koneksi, dan IKEv2 kembali sebagai galat 809 tentang server jauh yang tidak merespons.

Apa yang sebenarnya dikendalikan portal

Portal penahan adalah dua hal yang ditempel jadi satu: titik keputusan kebijakan dan pengalih. Saat perangkat Anda berasosiasi dan mengambil sewa DHCP, jaringan menempatkan Anda dalam keadaan sebelum otorisasi.

Keadaan itu adalah sekumpulan aturan tembok api. Biasanya ia mengizinkan DNS dan mengizinkan HTTP atau HTTPS ke daftar pendek hos portal, dan membuang semua yang lain. Daftar yang diizinkan adalah taman berpagar, dan hampir tidak pernah mencakup titik akhir VPN.

Tidak satu pun pembuangan itu sopan. Paket yang ditujukan ke server VPN dibuang, bukan ditolak, sehingga klien tidak menerima ICMP unreachable maupun TCP reset, hanya ketiadaan jawaban. Tergantung vendor, pengalih dapat menjawab port 80 dengan pengalihan ke halaman masuk sementara port 443 dibuang atau dicegat. Pengalihan mudah dikenali karena membawa respons HTTP biasa; pencegatan pada 443 memerlukan sertifikat yang akan ditolak dipercaya oleh peramban Anda.

Otorisasi itu sendiri biasanya terikat pada alamat MAC perangkat, kadang pada IP yang disewa, dan hidup dalam tabel sesi dengan pewaktu. Masuk menciptakan entri. Aturan tembok api yang meloloskan lalu lintas Anda hanya ada selama entri itu ada, dan itulah sebabnya seluruh masalah kembali kemudian tanpa ada yang berubah di pihak Anda.

Mengapa jabat tangan VPN mati sebelum dimulai

Setiap protokol punya transpor sendiri, dan tembok api sebelum otorisasi merusak masing-masing secara berbeda. IKEv2 di Windows dan iOS berjalan di atas UDP 500 dan UDP 4500; pembuangan pada port itu muncul sebagai 809, atau sebagai kegagalan bergaya penyelesaian nama pada klien yang melaporkan tahap secara terpisah. OpenVPN di atas UDP 1194 bertahan dalam keadaan menghubungkan sampai batas waktunya habis. OpenVPN di atas TCP 443 adalah kasus menarik, karena portal dapat menyelesaikan jabat tangan TCP lalu menjawab dengan halaman pengalihannya, sehingga Anda melihat galat TLS alih-alih waktu tunggu.

WireGuard menunjukkan mekanismenya paling jelas. Ia hanya UDP secara desain, tanpa cadangan TCP, sehingga tembok api yang membuang UDP tak dikenal menghapus transpornya sepenuhnya. Klien terus mengirim inisiasi jabat tangan dengan jeda yang makin besar dan melaporkan jabat tangan yang tidak pernah selesai. Tidak ada yang menyebut Wi-Fi dalam pesan itu, dan tidak ada yang menyarankan Anda membuka peramban.

Platform berusaha menyadari keadaan itu sebelum VPN Anda. Windows mengambil URL yang dikenal untuk memutuskan apakah menampilkan notifikasi masuknya, Android meminta titik akhir yang seharusnya menjawab 204 No Content, dan perangkat Apple membuka jendela kecil jaringan penahan. Pemeriksaan itu bekerja karena portal menjawab dengan pengalihan alih-alih isi yang diharapkan. Perilaku yang sama menjelaskan bagaimana portal dapat tampak sepenuhnya sehat sementara terowongan Anda mati: pemeriksaan dan terowongan dinilai dengan aturan berbeda.

Apa yang sebenarnya diatur ulang oleh kedaluwarsa sesi

Tempat usaha mengakhiri sesi karena alasan yang tidak terkait akun VPN Anda: waktu tunggu menganggur, panjang sesi maksimum, sewa DHCP baru, atau asosiasi ulang ke titik akses lain. Saat pewaktu berbunyi, entri tabel sesi hilang dan kumpulan aturan sebelum otorisasi kembali persis seperti saat check-in.

Terowongan yang sudah terbentuk sering bertahan cukup lama untuk tampak sehat. Pesan pemeliharaan terus keluar, dan apakah klien menyadarinya bergantung pada cara ia memperlakukan lalu lintas tanpa jawaban, sehingga lampu status bisa tetap hijau beberapa saat setelah jalurnya hilang. Lalu terowongan jatuh dan setiap upaya penyambungan ulang gagal pada port yang diblokir itu juga.

Pada titik itu, galat klien memberi tahu Anda di tahap mana, jika Anda membacanya dengan cermat:

Satu detail mengecoh orang: ketika sesi terikat pada alamat MAC, memuat ulang halaman masuk mungkin tidak membantu. Anda harus melepas asosiasi dan bergabung lagi agar portal melihat upaya otorisasi baru alih-alih yang kedaluwarsa.

Masuk dulu, baru naikkan terowongan

Urutan yang bekerja adalah: otorisasi perangkat, buktikan jalurnya, jalankan VPN, buktikan terowongannya, lalu pulihkan pemblokiran normal Anda. Langkah terakhir itu penting karena keadaan sementara yang Anda butuhkan untuk mencapai portal justru keadaan yang hendak dicegah oleh sakelar mati.

Klien desktop dengan opsi blokir di luar terowongan harus dijeda agar halaman portal termuat, dan Anda sebaiknya menutup aplikasi sensitif selama jendela di luar terowongan itu; itulah satu-satunya selang saat lalu lintas lokal keluar tanpa perlindungan. Perangkat terkelola yang selalu menyala sebaiknya memakai prosedur yang diterbitkan pemiliknya alih-alih Anda mencabut kebijakan. Jika portal menampilkan peringatan sertifikat, berhentilah: menerimanya mengarahkan sesi Anda melalui proksi pencegatan tempat itu, dan proksi itu dapat membaca semua yang Anda kirim. Di Android, penguncian di bawah VPN selalu aktif memblokir lalu lintas sebelum terowongan naik, dan sebagian build tidak dapat mengecualikan aliran portal; jika milik Anda tidak bisa, gunakan akses alternatif tempat itu atau perangkat lain alih-alih membiarkan penguncian mati. Aturan sesuai permintaan Apple dapat ditulis untuk menolak terowongan sampai pemeriksaan berhasil, dan itulah perilaku yang Anda inginkan di jaringan hotel.

Verifikasi berurutan dengan alat yang sudah Anda miliki. Sebelum terowongan, jalankan pemeriksaan dengan tajuk dan isi keduanya terlihat, dan perhatikan apakah transpor VPN Anda mendapat jawaban sama sekali:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Sebelum otorisasi, portal normal memberi satu dari dua jawaban: 302 yang Location-nya menunjuk ke halaman masuk, atau 200 dengan isi HTML yang merupakan halaman portal. Catat mana yang Anda dapat. Pengalihan bukan kegagalan sebelum masuk; portal sedang memberi tahu Anda ke mana harus pergi. Setelah portal melaporkan sukses, ulangi perintahnya dan harapkan 200 yang isinya kata literal Success. String itulah yang membuat pemeriksaan bermakna. Jika hos menjawab normal sebelum Anda pernah masuk, tidak ada portal pencegatan di jaringan ini. Dalam tangkapan, pembuangan sebelum otorisasi adalah paket keluar yang tidak kembali, sedangkan jalur yang bekerja menunjukkan jawaban pada aliran yang sama dalam sekitar satu detik. Sambungkan, lalu ulangi tangkapan.

Jika terowongan masih gagal setelah portal berkata ya

Sukses masuk bukan berarti transpor diizinkan. Banyak tempat mengizinkan portal dan penjelajahan biasa tetapi memblokir UDP sepenuhnya, yang membuat WireGuard dan OpenVPN di atas UDP rusak dan TCP 443 bekerja. Jika TCP 443 lolos dan UDP tidak, itu kebijakan tempat, bukan klien yang salah Anda konfigurasi, jadi ganti transpor atau terima batasnya dan lanjutkan. Jika penyambungan ulang masih gagal setelah itu, simpan galat persisnya; ia menyebut tahap tempat Anda tersangkut.

Kegagalan lain hidup di perangkat. Sesi yang masih terikat ke MAC lama, adaptor Wi-Fi kedua dengan sewanya sendiri, atau klien yang menyimpan pengecualian sertifikat portal dapat terus gagal setelah otorisasi ulang yang bersih. Lepas asosiasinya, otorisasi lagi, dan coba sekali sebelum menyentuh setelan klien. RFC 8952 layak dibaca jika Anda ingin arsitektur di balik komponen yang Anda amati.

Jika portal itu sendiri menolak memberi otorisasi, masalahnya ada pada akun atau alokasi perangkat dan tidak ada setelan VPN yang akan memperbaikinya. Mengubah negara keluar VPN tidak mengatur ulang keadaan akses lokal tempat itu; tabel itu terikat pada perangkat Anda, bukan pada server yang Anda pilih. Tanyakan kepada operator tempat itu dan beri dia waktu, karena tabel sesi adalah yang akan dia lihat.

Sebelum perjalanan berikutnya, catat tiga hal: halaman portal sebagai langkah nol, langkah menjeda pemblokiran untuk setiap perangkat yang Anda bawa, dan satu transpor cadangan yang benar-benar Anda uji. Ketika terowongan yang berfungsi sepuluh menit lalu berhenti lagi, anggap itu otorisasi kedaluwarsa dan periksa ulang portal sebelum menyentuh profil VPN.