Captive-portalo kaj VPN-blokado: kiu moviĝas unue
La hotelportalo volas trafikon antaŭ ol ekzistas la tunelo; la VPN blokas ĝis la tunelo staras. Komparu la du sinsekvojn kaj kion ĉiu el ili malkaŝas en la breĉo.
La portalo de la hotelo volas retumilon antaŭ ol lasi trairi ajnan trafikon. Via VPN rifuzas lasi trafikon trairi antaŭ ol ĝia tunelo staras. Ĉiu flanko atendas la alian, kaj ambaŭ kondutas ĝuste tiel, kiel ili estas agorditaj. Nur du sinsekvoj rompas tiun blokadon, kaj ili diferencas en tio, kion ili malkaŝas dum la breĉo restas malfermita. Elektu unu konscie anstataŭ ŝaltadi ajnan agordon, kiu igas la retumilon ŝargi.
Du sinsekvoj, unu el ili funkcias
Aŭ la reto akceptas vin unue kaj la tunelo venas due, aŭ vi malfermas mallarĝan escepton por la portalo kaj poste restarigas la blokadon. Ambaŭ estas legitimaj. Ne legitime estas malŝalti la blokadon kaj forgesi restarigi ĝin.
| 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 |
La du sinsekvoj ne same bonas en ĉiu situacio. Administrita aparato kun deviga akcepta procezo havas unu respondon, kaj persona tekkomputilo en hotela Wi-Fi havas alian. La komparo temas pri tio, kion ĉiu opcio rezignas.
Komencu per scii, kiun el ili via kliento kaj via aparata politiko efektive subtenas.
Opcio A: la reto akceptas vin, poste konektiĝas la tunelo
Konfirmu la atendatan retan nomon, poste uzu la saluton de la operaciumo aŭ la subtenatan fluon de captive-portalo de la kliento. Sur iPhone kaj iPad, fermi la salutfolion povas aŭ forigi la asociiĝon aŭ konservi ĝin kun averto, ke la reto ne havas interreton, kaj tiuj estas malsamaj startpunktoj. Unue finu la akceptan paŝon, poste starigu la tunelon. Ĉi tiu sinsekvo konservas la blokadon sendifekta dum la tuta tempo, kiam la tunelo estas malsupre.
La kaŝitaĵo estas, ke portalo, kiu rajtigas interretan aliron, ne aŭtentikigis vian VPN-konton. La tunelo tamen devas konektiĝi poste, kaj ĝi povas malsukcesi pro siaj propraj kaŭzoj. Akcepto kaj aŭtentikigo estas apartaj okazoj, kiujn homoj kunfandas en unu.
Se la akcepto daŭre eksvalidiĝas, notu, ĉu la portalo denove demandas, ĉu la reto falas, aŭ ĉu nur la VPN malsukcesas.
Opcio B: mallarĝa salutescepto, poste restarigo de la blokado
La alternativo estas permesi la trafikon de la portalo dum la blokado alie validas, saluti, kaj poste forigi la escepton. La escepto devas esti mallarĝa: unu celloko aŭ unu adresaro, por la daŭro de la saluto, kun la blokado restarigita tuj poste. Larĝa provizora fenestro estas la maniero, kiel saluto de du minutoj fariĝas posttagmezo de neprotektita trafiko.
Sciu, kion via kliento efektive realigas. OpenVPN Connect sur macOS dokumentas la detekton de captive-portalo aparte de sia opcio, kiu blokas interretan aliron dum la VPN estas paŭzigita aŭ rekonektiĝas. Detekti portalon kaj permesi ĝian trafikon estas rilataj taskoj, ne interŝanĝeblaj promesoj.
Sur administrita aparato, sekvu la agorditan akceptan procezon anstataŭ elpensi escepton.
Kion la breĉo malkaŝas, kaj al kiu
La interesa parto de la blokado ne estas la retumila langeto antaŭ vi. Ĝi estas ĉio alia, kio komencas uzi la reton en la momento, kiam konekteco aperas: poŝto, fotosinkronigo, ĝisdatigaj kontroloj, babileja kliento rekonektiĝanta, savkopiagento rekomenciĝanta.
Kvieta retumila fenestro diras al vi nenion pri tio. Fermu aŭ paŭzigu senteman laboron antaŭ ĉiu permesita intervalo de rekta aliro, kaj kontrolu, kio funkcias ĉe saluto. Sur Android, ĉiam-aktiva VPN kunligita kun blokado de konektoj ekster la VPN estas la koncerna kontrolo, kaj arbitra itin-escepto ne anstataŭas kompreni ĝin.
Ĉi tio estas la sola loko, kie la pli malnova konsilo pri provizoraj alirfenestroj ankoraŭ validas. La zorgo estis prava eĉ tie, kie la mekanismo ne estis.
Kiel elekti kaj kiel konfirmi
Elektu opcion A, kiam la aparato aŭ la kliento subtenas realan portalan fluon, ĉar ĝi konservas la blokadon sendifekta la tutan tempon. Elektu opcion B, kiam la portalo ne estas atingebla alimaniere, kaj traktu la escepton kiel tempolimigitan ŝanĝon kun posedanto.
Poste konfirmu la sinsekvon, ne la rezulton:
curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'Finu la akcepton, starigu la celitan profilon, restarigu ajnan provizore ŝanĝitan blokadan kontrolon, kaj poste faru novan sendanĝeran peton kaj konfirmu, ke ĝi sekvas la tunelon. Prito, kiu sukcesas ĉar la blokado ankoraŭ estas malŝaltita, pruvas nenion pri la tunelo.
Ŝanĝi la VPN-eliron ne renovigos eksvalidiĝintan hotelan seancon. Tiuj estas malsamaj okazoj, kaj ilia konfuzo sendas vin serĉi en la malĝusta loko.