Captive portal at VPN na deadlock: sino ang unang gumalaw
Kailangan ng portal ng hotel ang trapiko bago umiral ang tunnel; hinaharangan ng VPN hanggang umangat ang tunnel. Ihambing ang dalawang pagkakasunod-sunod at ang inilalantad ng bawat isa sa patlang.
Gusto ng portal ng hotel na makakita ng browser bago ito magpadaan ng anumang trapiko. Tumatanggi ang iyong VPN na magpadaan ng trapiko hanggang umangat ang tunnel nito. Naghihintayan ang dalawang panig, at parehong kumikilos nang eksakto ayon sa pagkaka-configure. Dalawa lang ang pagkakasunod-sunod na bumabasag sa deadlock na ito, at nagkakaiba sila sa inilalantad habang bukas ang patlang. Pumili ng isa nang sinasadya sa halip na i-toggle ang anumang setting na nagpapakarga sa browser.
Dalawang pagkakasunod-sunod, isa ang gumagana
Either tinatanggap ka muna ng network at saka darating ang tunnel, o magbubukas ka ng makitid na pagbubukod para sa portal at ibabalik ang pagharang pagkatapos. Pareho silang lehitimo. Ang hindi lehitimo ay patayin ang pagharang at kalimutang ibalik ito.
| Order | What it costs | When it fails |
|---|---|---|
| Admit, then connect | Nothing extra; the block stays on | The client cannot reach the portal with the tunnel down |
| Exception, then restore | A timed window of direct access | The window is left open, or scoped too broadly |
Hindi parehong mabuti ang dalawang pagkakasunod-sunod sa lahat ng sitwasyon. May isang sagot ang pinamamahalaang device na may sapilitang proseso ng pagtanggap, at may iba ang personal na laptop sa Wi-Fi ng hotel. Ang paghahambing ay tungkol sa kung ano ang isinusuko ng bawat opsyon.
Simulan sa pag-alam kung alin sa dalawa ang aktwal na sinusuportahan ng iyong kliyente at patakaran ng device.
Opsyon A: tanggapin ang network, pagkatapos ikonekta ang tunnel
Kumpirmahin ang inaasahang pangalan ng network, pagkatapos gamitin ang prompt ng pag-sign in ng operating system o ang sinusuportahang daloy ng captive portal ng kliyente. Sa iPhone at iPad, ang pagsasara ng sign-in sheet ay maaaring putulin ang koneksyon o panatilihin ito na may babala na walang internet ang network, at magkaibang simulang punto ang mga iyon. Tapusin muna ang hakbang ng pagtanggap, pagkatapos itaas ang tunnel. Pinapanatili ng pagkakasunod-sunod na ito ang pagharang na buo sa buong panahong nakababa ang tunnel.
Ang bitag ay ang portal na nagpapahintulot ng access sa internet ay hindi nag-authenticate ng iyong VPN account. Kailangan pa ring kumonekta ng tunnel pagkatapos, at maaari itong mabigo sa sarili nitong mga dahilan. Ang pagtanggap at pag-authenticate ay magkaibang pangyayari na pinagsasama ng mga tao sa isa.
Kung paulit-ulit na nag-expire ang pagtanggap, itala kung muling nagtatanong ang portal, bumabagsak ang network, o ang VPN lang ang nabibigo.
Opsyon B: makitid na pagbubukod sa pag-sign in, pagkatapos ibalik ang pagharang
Ang alternatibo ay payagan ang trapiko ng portal habang nananatiling may bisa ang pagharang sa ibang bahagi, mag-sign in, at pagkatapos alisin ang pagbubukod. Dapat makitid ang pagbubukod: isang destinasyon o isang hanay ng address, sa tagal ng pag-sign in, at agad na naibalik ang pagharang pagkatapos. Ang malawak na pansamantalang window ay kung paano nagiging isang hapon ng walang proteksyong trapiko ang dalawang minutong pag-sign in.
Alamin kung ano talaga ang ipinapatupad ng iyong kliyente. Dinodokumento ng OpenVPN Connect sa macOS ang pagtuklas ng captive portal nang hiwalay sa opsyon nitong humaharang sa access sa internet habang naka-pause o muling kumokonekta ang VPN. Ang matuklasan ang portal at payagan ang trapiko nito ay magkaugnay na gawain, hindi mapagpapalit na pangako.
Sa pinamamahalaang device, sundin ang naka-configure na proseso ng pagtanggap sa halip na mag-imbento ng pagbubukod.
Ano ang inilalantad ng patlang, at kanino
Ang kawili-wiling bahagi ng deadlock ay hindi ang tab ng browser sa harap mo. Ito ay lahat ng iba pang nagsisimulang gumamit ng network sa sandaling lumitaw ang konektibidad: mail, pag-sync ng larawan, pagsusuri ng update, kliyenteng chat na muling kumokonekta, agent ng backup na nagpapatuloy.
Walang sinasabi sa iyo ang isang tahimik na window ng browser tungkol sa mga iyon. Isara o i-pause ang sensitibong trabaho bago ang anumang pinapayagang agwat ng direktang access, at tingnan kung ano ang tumatakbo sa pag-sign in. Sa Android, always-on VPN na sinasamahan ng pagharang sa mga koneksyon sa labas ng VPN ang kaugnay na control, at ang arbitraryong pagbubukod sa ruta ay hindi kapalit ng pag-unawa dito.
Ito ang tanging lugar kung saan nananatiling wasto ang lumang payo tungkol sa pansamantalang window ng access. Tama ang pag-aalala kahit saan hindi tama ang mekanismo.
Paano pumili at paano kumpirmahin
Piliin ang Opsyon A kapag sinusuportahan ng device o kliyente ang tunay na daloy ng portal, dahil pinapanatili nitong buo ang pagharang sa buong panahon. Piliin ang Opsyon B kapag hindi maabot ang portal sa ibang paraan, at ituring ang pagbubukod bilang pagbabagong may takdang oras at may may-ari.
Pagkatapos, kumpirmahin ang pagkakasunod-sunod, hindi ang resulta:
curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'Tapusin ang pagtanggap, itatag ang nilalayong profile, ibalik ang anumang control sa pagharang na pansamantalang binago, pagkatapos gumawa ng bago at walang pinsalang kahilingan at kumpirmahing sinusundan nito ang tunnel. Ang kahilingang nagtagumpay dahil patay pa rin ang pagharang ay walang pinapatunayan tungkol sa tunnel.
Ang pagpapalit ng labasan ng VPN ay hindi magre-renew ng nag-expire na sesyon sa hotel. Magkaiba ang mga pangyayaring iyon, at ang paghahalo sa kanila ay magpapahanap sa iyo sa maling lugar.