Bakit hinaharangan ng captive portal ang iyong VPN at paano muling mag-log in

Sa bukas na network, hindi lang basta ipinapasa ng iyong access point ang mga packet sa internet. Sinusuri ng isang policy point sa itaas kung awtorisado na ang device mo, at hangga't hindi, halos lahat ay itinatapon. Binabasa ng iyong VPN client ang katahimikang iyon bilang patay na server. Bihira nitong sabihin iyon: inuulit ng WireGuard ang handshake sa kawalan, nag-uulat ang OpenVPN ng timeout ng koneksyon, at bumabalik ang IKEv2 bilang error 809 tungkol sa malayong server na hindi tumutugon.

Ano talaga ang kinokontrol ng portal

Ang captive portal ay dalawang bagay na pinagdikit: isang policy decision point at isang redirector. Kapag nag-associate ang device mo at kumuha ng DHCP lease, inilalagay ka ng network sa isang estado bago ang awtorisasyon.

Ang estadong iyon ay isang set ng firewall rules. Karaniwang pinapayagan ang DNS at pinapayagan ang HTTP o HTTPS papunta sa maikling listahan ng portal hosts, at itinatapon ang lahat ng iba pa. Ang pinapayagang listahan ay ang nabakurang hardin, at halos hindi kailanman kasama ang endpoint ng VPN.

Wala sa mga pagtatapong ito ang magalang. Ang mga packet na patungo sa VPN server ay itinatapon sa halip na tinatanggihan, kaya walang natatanggap ang client na ICMP unreachable o TCP reset, ang kawalan lang ng sagot. Depende sa vendor, maaaring tumugon ang redirector sa port 80 ng redirect papunta sa sign-in page habang ang port 443 ay itinatapon o hinaharang. Madaling makita ang mga redirect dahil may dalang ordinaryong HTTP response; ang pagharang sa 443 ay nangangailangan ng certificate na tatanggihan ng browser mong pagkatiwalaan.

Ang awtorisasyon mismo ay karaniwang nakatali sa MAC address ng device, kung minsan sa inuupahang IP, at nakatira ito sa isang session table na may timer. Ang pag-log in ay lumilikha ng entry. Ang firewall rule na nagpapadaan sa traffic mo ay umiiral lang habang umiiral ang entry na iyon, at iyon ang dahilan kung bakit bumabalik ang buong problema mamaya nang walang nagbabago sa panig mo.

Bakit namamatay ang handshake ng VPN bago pa magsimula

May sariling transport ang bawat protocol, at iba-iba ang pagkasira ng firewall bago ang awtorisasyon sa bawat isa. Ang IKEv2 sa Windows at iOS ay dumadaan sa UDP 500 at UDP 4500; ang pagtatapon sa mga port na iyon ay lumalabas bilang 809, o bilang pagkabigo na parang name resolution sa mga client na hiwalay na nag-uulat ng mga phase. Ang OpenVPN sa UDP 1194 ay nananatili sa connecting state hanggang ma-expire ang oras nito. Ang OpenVPN sa TCP 443 ang kawili-wiling kaso, dahil maaaring tapusin ng portal ang TCP handshake at pagkatapos ay tumugon ng sarili nitong redirect page, kaya TLS error ang nakikita mo sa halip na timeout.

Pinakamalinaw na ipinapakita ng WireGuard ang mekanismong ito. UDP lang ito ayon sa disenyo, walang TCP fallback, kaya tinatanggal nang tuluyan ng firewall na nagtatapon ng hindi kilalang UDP ang transport. Patuloy na nagpapadala ang client ng handshake initiations na may lumalaking agwat at nag-uulat ng handshake na hindi natatapos. Wala sa mensaheng iyon ang tumutukoy sa Wi-Fi, at wala ring nagpapahiwatig na dapat kang magbukas ng browser.

Sinusubukan ng mga platform na mapansin ang estado bago pa ang VPN mo. Kumukuha ang Windows ng kilalang URL para magpasya kung ipapakita ang sign-in notice nito, humihingi ang Android ng endpoint na dapat tumugon ng 204 No Content, at nagbubukas ang mga Apple device ng maliit na captive network window. Gumagana ang mga probe dahil tumutugon ang portal ng redirect sa halip na ang inaasahang body. Ipinapaliwanag ng parehong pag-uugali kung paanong ang portal ay maaaring mukhang ganap na malusog habang patay ang tunnel mo: ang probe at ang tunnel ay hinuhusgahan sa magkaibang patakaran.

Ano talaga ang nire-reset ng pag-expire ng session

Pinapaso ng mga lugar ang mga session dahil sa mga dahilan na walang kaugnayan sa VPN account mo: timeout ng kawalan ng aktibidad, pinakamahabang haba ng session, bagong DHCP lease, o muling pag-associate sa ibang access point. Kapag tumunog ang timer, nawawala ang entry sa session table at bumabalik ang ruleset bago ang awtorisasyon nang eksakto tulad noong nag-check in ka.

Ang naitatag na tunnel ay madalas mabuhay nang sapat na katagal para magmukhang malusog. Patuloy na lumalabas ang keepalive messages, at kung napapansin ito ng client ay depende sa kung paano nito hinahawakan ang traffic na walang sagot, kaya maaaring manatiling berde ang status light nang ilang sandali matapos mawala ang landas. Pagkatapos ay bumagsak ang tunnel at bawat pagtatangkang muling kumonekta ay nabibigo sa parehong harang na ports.

Sa puntong iyon, sinasabi ng error ng client kung saang yugto ka, kung babasahin mo ito nang mabuti:

Isang detalye ang nakakalito sa mga tao: kapag ang session ay nakatali sa isang MAC address, maaaring hindi makatulong ang muling pag-load ng sign-in page. Kailangan mong i-drop ang association at sumali muli, para makita ng portal ang bagong pagtatangka sa awtorisasyon sa halip na ang nag-expire na.

Mag-log in muna, pagkatapos itaas ang tunnel

Ang order na gumagana ay: awtorisahin ang device, patunayan ang landas, simulan ang VPN, patunayan ang tunnel, at pagkatapos ay ibalik ang dati mong pagharang. Mahalaga ang huling hakbang na iyon dahil ang pansamantalang estado na kailangan mo para maabot ang portal ay eksaktong estadong inilaan ng kill switch na pigilan.

Ang desktop client na may opsyong harangin sa labas ng tunnel ay dapat i-pause para mag-load ang portal page, at dapat mong panatilihing sarado ang mga sensitibong app sa window na iyon sa labas ng tunnel; ito ang tanging pagitan kung kailan lumalabas ang lokal na traffic na walang proteksyon. Ang managed na laging nakabukas na device ay dapat gamitin ang pamamaraang inilathala ng may-ari nito sa halip na ikaw ang magtanggal ng policy. Kung magpakita ang portal ng babala sa certificate, huminto: ang pagtanggap nito ay dumadaan sa interception proxy ng lugar, at mababasa ng proxy na iyon ang lahat ng ipinapadala mo. Sa Android, hinaharangan ng lockdown sa ilalim ng laging aktibong VPN ang traffic bago umangat ang tunnel, at may mga build na hindi kayang i-exclude ang portal flow; kung hindi kaya ng sa iyo, gamitin ang alternatibong access ng lugar o ibang device sa halip na iwang nakapatay ang lockdown. Maaaring isulat ang on-demand rules ng Apple para tumanggi sa tunnel hanggang magtagumpay ang isang probe, at iyon ang pag-uugaling gusto mo sa mga hotel network.

I-verify nang sunud-sunod gamit ang mga tool na mayroon ka na. Bago ang tunnel, patakbuhin ang probe nang nakikita ang headers at body, at tingnan kung may natatanggap na sagot ang transport ng VPN mo:

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'

Bago ang awtorisasyon, nagbibigay ang normal na portal ng isa sa dalawang sagot: isang 302 na ang Location ay tumuturo sa sign-in page, o isang 200 na may HTML body na siyang portal page. Itala kung alin ang nakuha mo. Ang redirect bago mag-log in ay hindi pagkabigo; sinasabi lang ng portal kung saan ka dapat pumunta. Pagkatapos iulat ng portal ang tagumpay, ulitin ang command at asahan ang 200 na ang body ay literal na salitang Success. Ang string na iyon ang nagbibigay-kahulugan sa probe. Kung normal na tumugon ang host bago ka pa kailanman mag-log in, walang interception portal sa network na ito. Sa capture, ang pagtatapon bago ang awtorisasyon ay mga palabas na packet na walang bumabalik, habang ang gumaganang landas ay nagpapakita ng sagot sa parehong flow sa loob ng halos isang segundo. Kumonekta, pagkatapos ay ulitin ang capture.

Kung nabibigo pa rin ang tunnel pagkatapos sabihin ng portal na oo

Ang tagumpay sa pag-log in ay hindi katulad ng pinapayagang transport. Maraming lugar ang nagpapahintulot sa portal at ordinaryong pag-browse pero ganap na hinaharangan ang UDP, na nag-iiwan sa WireGuard at UDP OpenVPN na sira at gumagana ang TCP 443. Kung pumapasok ang TCP 443 at hindi ang UDP, iyon ay patakaran ng lugar at hindi isang client na mali ang pagkaka-configure mo, kaya palitan ang transport o tanggapin ang limitasyon at magpatuloy. Kung nabibigo pa rin ang muling pagkonekta pagkatapos niyon, itago ang eksaktong error; sinasabi nito ang yugtong kinikiligiran mo.

Nakatira sa device ang ibang mga pagkabigo. Isang session na nakatali pa rin sa lumang MAC, pangalawang Wi-Fi adapter na may sariling lease, o client na nag-cache ng certificate exception ng portal ay maaaring patuloy na mabigo pagkatapos ng malinis na muling awtorisasyon. I-drop ang association, awtorisahin muli, at subukan isang beses bago hawakan ang client settings. Sulit basahin ang RFC 8952 kung gusto mo ang arkitektura sa likod ng mga component na sinusubaybayan mo.

Kung ang portal mismo ang tumangging mag-awtorisa, ang problema ay nasa account o sa paglalaan ng device at walang VPN setting ang makakapag-ayos niyon. Ang pagpapalit ng exit country ng VPN ay hindi nagre-reset ng lokal na access state ng lugar; ang table na iyon ay nakatali sa device mo, hindi sa server na pinipili mo. Tanungin ang operator ng lugar at bigyan ito ng oras, dahil ang session table ang titingnan nito.

Bago ang susunod na biyahe, isulat ang tatlong bagay: ang portal page bilang step zero, ang step ng pag-pause ng pagharang para sa bawat device na dadalhin mo, at isang backup na transport na talagang sinubukan mo. Kapag huminto muli ang tunnel na gumana sampung minuto ang nakalipas, ituring itong expired na awtorisasyon at muling suriin ang portal bago hawakan ang VPN profile.