Mengapa portal tahanan menyekat VPN anda, dan cara log masuk semula

Pada rangkaian terbuka, titik akses anda tidak menyerahkan paket kepada internet begitu sahaja. Satu titik dasar di hulu memeriksa sama ada peranti anda sudah dibenarkan, dan sehingga ia dibenarkan, hampir semuanya dibuang. Klien VPN anda membaca kesunyian itu sebagai pelayan mati. Ia jarang menyatakannya: WireGuard mengulang jabat tangan ke dalam kehampaan, OpenVPN melaporkan tamat masa sambungan, dan IKEv2 kembali sebagai ralat 809 tentang pelayan jauh yang tidak bertindak balas.

Apa yang portal sebenarnya kawal

Portal tahanan ialah dua perkara yang dilekatkan bersama: titik keputusan dasar dan pengubah hala. Apabila peranti anda bersekutu dan mengambil pajakan DHCP, rangkaian meletakkan anda dalam keadaan sebelum kebenaran.

Keadaan itu ialah satu set peraturan tembok api. Ia biasanya membenarkan DNS dan membenarkan HTTP atau HTTPS ke senarai pendek hos portal, dan ia membuang segala yang lain. Senarai yang dibenarkan ialah taman berdinding, dan ia hampir tidak pernah merangkumi titik akhir VPN.

Tiada satu pun pembuangan itu sopan. Paket yang ditujukan kepada pelayan VPN dibuang dan bukan ditolak, jadi klien tidak menerima ICMP unreachable mahupun TCP reset, hanya ketiadaan jawapan. Bergantung pada vendor, pengubah hala mungkin menjawab port 80 dengan pengubahan hala ke halaman log masuk sementara port 443 dibuang atau dipintas. Pengubahan hala mudah dikesan kerana ia membawa respons HTTP biasa; pintasan pada 443 memerlukan sijil yang pelayar anda akan enggan mempercayainya.

Kebenaran itu sendiri biasanya dikunci kepada alamat MAC peranti, kadangkala kepada IP yang dipajak, dan ia hidup dalam jadual sesi dengan pemasa. Log masuk mencipta satu entri. Peraturan tembok api yang membenarkan trafik anda melalui hanya wujud selagi entri itu wujud, dan itulah sebabnya seluruh masalah kembali kemudian tanpa apa-apa berubah di pihak anda.

Mengapa jabat tangan VPN mati sebelum bermula

Setiap protokol mempunyai pengangkutan sendiri, dan tembok api sebelum kebenaran memecahkan setiap satu secara berbeza. IKEv2 pada Windows dan iOS bergerak di atas UDP 500 dan UDP 4500; pembuangan pada port itu muncul sebagai 809, atau sebagai kegagalan bergaya penyelesaian nama pada klien yang melaporkan peringkat secara berasingan. OpenVPN di atas UDP 1194 kekal dalam keadaan menyambung sehingga tamat masanya. OpenVPN di atas TCP 443 ialah kes yang menarik, kerana portal mungkin menyelesaikan jabat tangan TCP dan kemudian menjawab dengan halaman pengubahan halanya, jadi anda melihat ralat TLS dan bukannya tamat masa.

WireGuard menunjukkan mekanisme itu paling jelas. Ia hanya UDP mengikut reka bentuk, tanpa sandaran TCP, jadi tembok api yang membuang UDP tidak dikenali menghapuskan pengangkutan sepenuhnya. Klien terus menghantar permulaan jabat tangan dengan mundur yang bertambah dan melaporkan jabat tangan yang tidak pernah selesai. Tiada apa-apa dalam mesej itu menyebut Wi-Fi, dan tiada apa-apa di dalamnya mencadangkan anda membuka pelayar.

Platform cuba menyedari keadaan itu sebelum VPN anda. Windows mengambil URL yang diketahui untuk memutuskan sama ada memaparkan pemberitahuan log masuknya, Android meminta titik akhir yang sepatutnya menjawab 204 No Content, dan peranti Apple membuka tetingkap rangkaian tahanan yang kecil. Pemeriksaan itu berfungsi kerana portal menjawab dengan pengubahan hala dan bukannya isi yang dijangka. Tingkah laku yang sama menjelaskan bagaimana portal boleh kelihatan sihat sepenuhnya sedangkan terowong anda mati: pemeriksaan dan terowong dinilai dengan peraturan yang berbeza.

Apa yang tamat sesi sebenarnya tetapkan semula

Tempat menamatkan sesi atas sebab yang tidak berkaitan dengan akaun VPN anda: tamat masa melahu, panjang sesi maksimum, pajakan DHCP baharu, atau persekutuan semula ke titik akses lain. Apabila pemasa berbunyi, entri jadual sesi hilang dan set peraturan sebelum kebenaran kembali tepat seperti semasa daftar masuk.

Terowong yang sudah terbentuk sering bertahan cukup lama untuk kelihatan sihat. Mesej pengekalan hidup terus keluar, dan sama ada klien menyedarinya bergantung pada cara ia mengendalikan trafik tanpa jawapan, jadi lampu status mungkin kekal hijau seketika selepas laluan hilang. Kemudian terowong jatuh dan setiap percubaan menyambung semula gagal pada port yang disekat itu juga.

Pada ketika itu ralat klien memberitahu anda di peringkat mana anda berada, jika anda membacanya dengan teliti:

Satu butiran mengelirukan orang: apabila sesi dikunci kepada alamat MAC, memuat semula halaman log masuk mungkin tidak membantu. Anda perlu melepaskan persekutuan dan menyertai semula supaya portal melihat percubaan kebenaran baharu dan bukannya yang tamat.

Log masuk dahulu, kemudian naikkan terowong

Urutan yang berkesan ialah: benarkan peranti, buktikan laluan, mulakan VPN, buktikan terowong, kemudian pulihkan sekatan biasa anda. Langkah terakhir itu penting kerana keadaan sementara yang anda perlukan untuk mencapai portal ialah tepat keadaan yang suiz maut wujud untuk menghalangnya.

Klien desktop dengan pilihan menyekat di luar terowong mesti dijeda supaya halaman portal dimuatkan, dan anda harus menutup aplikasi sensitif sepanjang tetingkap di luar terowong itu; itulah satu-satunya selang apabila trafik setempat keluar tanpa perlindungan. Peranti terurus yang sentiasa hidup harus menggunakan prosedur yang diterbitkan oleh pemiliknya dan bukannya anda membuang dasar. Jika portal memaparkan amaran sijil, berhenti: menerimanya mengubah hala sesi anda melalui proksi pintasan tempat itu, dan proksi itu boleh membaca segala yang anda hantar. Pada Android, kunci di bawah VPN sentiasa aktif menyekat trafik sebelum terowong naik, dan sesetengah binaan tidak dapat mengecualikan aliran portal; jika binaan anda tidak dapat, gunakan akses alternatif tempat itu atau peranti lain dan bukannya membiarkan kunci dimatikan. Peraturan atas permintaan Apple boleh ditulis untuk menolak terowong sehingga pemeriksaan berjaya, dan itulah tingkah laku yang anda mahu pada rangkaian hotel.

Sahkan mengikut urutan dengan alat yang sudah anda miliki. Sebelum terowong, jalankan pemeriksaan dengan pengepala dan isi kedua-duanya kelihatan, dan perhatikan sama ada pengangkutan VPN anda menerima sebarang jawapan:

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 kebenaran, portal biasa memberikan satu daripada dua jawapan: 302 yang Location-nya menunjuk ke halaman log masuk, atau 200 dengan isi HTML yang merupakan halaman portal. Catat mana yang anda terima. Pengubahan hala bukan kegagalan sebelum log masuk; portal memberitahu anda ke mana perlu pergi. Selepas portal melaporkan kejayaan, ulangi arahan itu dan jangkakan 200 yang isinya ialah perkataan literal Success. Rentetan itulah yang menjadikan pemeriksaan itu bermakna. Jika hos menjawab secara normal sebelum anda pernah log masuk, tiada portal pintasan pada rangkaian ini. Dalam tangkapan, pembuangan sebelum kebenaran ialah paket keluar yang tiada apa kembali, manakala laluan yang berfungsi menunjukkan jawapan kepada aliran yang sama dalam masa kira-kira satu saat. Sambung, kemudian ulangi tangkapan.

Jika terowong masih gagal selepas portal berkata ya

Kejayaan log masuk bukanlah sama dengan pengangkutan yang dibenarkan. Banyak tempat membenarkan portal dan pelayaran biasa tetapi menyekat UDP sepenuhnya, yang membiarkan WireGuard dan OpenVPN di atas UDP rosak dan TCP 443 berfungsi. Jika TCP 443 lulus dan UDP tidak, itu dasar tempat itu dan bukan klien yang anda salah konfigurasikan, jadi tukar pengangkutan atau terima hadnya dan teruskan. Jika sambungan semula masih gagal selepas itu, simpan ralat yang tepat; ia menamakan peringkat tempat anda tersekat.

Kegagalan lain tinggal pada peranti. Sesi yang masih dikunci kepada MAC lama, penyesuai Wi-Fi kedua dengan pajakannya sendiri, atau klien yang menyimpan pengecualian sijil portal boleh terus gagal selepas kebenaran semula yang bersih. Lepaskan persekutuan, benarkan semula, dan cuba sekali sebelum menyentuh tetapan klien. RFC 8952 wajar dibaca jika anda mahu seni bina di sebalik komponen yang anda perhatikan.

Jika portal itu sendiri enggan membenarkan, masalahnya pada akaun atau peruntukan peranti dan tiada tetapan VPN akan membaikinya. Menukar negara keluar VPN tidak menetapkan semula keadaan akses setempat tempat itu; jadual itu dikunci kepada peranti anda, bukan kepada pelayan yang anda pilih. Tanya pengendali tempat itu dan berikan masa, kerana jadual sesi ialah apa yang akan dia lihat.

Sebelum perjalanan seterusnya, catat tiga perkara: halaman portal sebagai langkah sifar, langkah menjeda sekatan bagi setiap peranti yang anda bawa, dan satu pengangkutan sandaran yang benar-benar anda uji. Apabila terowong yang berfungsi sepuluh minit lalu berhenti semula, anggap ia kebenaran yang tamat dan periksa portal semula sebelum menyentuh profil VPN.