Portal captiu i bloqueig de la VPN: quin es mou primer

El portal de l’hotel vol un navegador abans de deixar passar cap trànsit. La vostra VPN es nega a deixar passar trànsit abans que el seu túnel estigui aixecat. Cada banda espera l’altra, i totes dues es comporten exactament tal com estan configurades. Només dos ordres trenquen aquest bloqueig, i es diferencien en què exposen mentre el buit és obert. Trieu-ne un deliberadament en lloc de tocar qualsevol paràmetre que faci carregar el navegador.

Dos ordres, un dels quals funciona

O la xarxa us admet primer i el túnel arriba després, o obriu una excepció estreta per al portal i després restaureu el bloqueig. Tots dos són legítims. El que no és legítim és desactivar el bloqueig i oblidar-vos de tornar-lo a posar.

Els dos ordres no són igual de bons en totes les situacions. Un dispositiu gestionat amb un procés d’admissió obligatori té una resposta, i un portàtil personal en un Wi-Fi d’hotel en té una altra. La comparació tracta de què cedeix cada opció.

Comenceu per saber quin dels dos admeten realment el vostre client i la vostra política de dispositius.

Opció A: la xarxa us admet i després es connecta el túnel

Confirmeu el nom de xarxa esperat i després feu servir el diàleg d’inici de sessió del sistema operatiu o el flux de portal captiu que admeti el client. A l’iPhone i l’iPad, tancar el full d’inici de sessió pot trencar l’associació o mantenir-la amb un avís que la xarxa no té internet, i aquests són punts de partida diferents. Completeu primer el pas d’admissió i després aixeceu el túnel. Aquest ordre manté el bloqueig intacte durant tot el temps que el túnel està abaixat.

La trampa és que un portal que autoritza l’accés a internet no ha autenticat el vostre compte de la VPN. El túnel encara s’ha de connectar després, i pot fallar per motius propis. L’admissió i l’autenticació són esdeveniments separats que la gent ajunta en un de sol.

Si l’admissió no para de caducar, fixeu-vos si el portal torna a preguntar, si cau la xarxa o si només falla la VPN.

Opció B: una excepció estreta d’inici de sessió i després restaurar el bloqueig

L’alternativa és permetre el trànsit del portal mentre el bloqueig continua vigent en la resta, iniciar sessió i després eliminar l’excepció. L’excepció ha de ser estreta: una destinació o un rang d’adreces, durant l’inici de sessió, amb el bloqueig restaurat immediatament després. Una finestra temporal àmplia és com un inici de sessió de dos minuts es converteix en una tarda de trànsit no protegit.

Sapigueu què implementa realment el vostre client. OpenVPN Connect a macOS documenta la detecció de portal captiu per separat de la seva opció que bloqueja l’accés a internet mentre la VPN està en pausa o es reconecta. Detectar un portal i permetre’n el trànsit són tasques relacionades, no promeses intercanviables.

En un dispositiu gestionat, seguiu el procés d’admissió configurat en lloc d’inventar una excepció.

Què exposa el buit, i a qui

La part interessant del bloqueig no és la pestanya del navegador que teniu al davant. És tota la resta que comença a usar la xarxa en el moment que apareix la connectivitat: correu, sincronització de fotos, comprovacions d’actualitzacions, un client de xat que es reconnecta, un agent de còpia de seguretat que reprèn.

Una finestra de navegador tranquil·la no us diu res sobre això. Tanqueu o poseu en pausa la feina sensible abans de qualsevol interval permès d’accés directe, i comproveu què s’executa en iniciar sessió. A Android, la VPN sempre activa combinada amb el bloqueig de connexions fora de la VPN és el control rellevant, i una excepció arbitrària de ruta no substitueix entendre’l.

Aquest és l’únic lloc on el consell antic sobre finestres temporals d’accés encara val. La preocupació era encertada fins i tot on el mecanisme no ho era.

Com triar i com confirmar-ho

Trieu l’opció A quan el dispositiu o el client admeten un flux de portal real, perquè manté el bloqueig intacte en tot moment. Trieu l’opció B quan no es pot arribar al portal de cap altra manera, i tracteu l’excepció com un canvi temporitzat amb un responsable.

Després confirmeu la seqüència i no el resultat:

curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'

Completeu l’admissió, establiu el perfil previst, restaureu qualsevol control de bloqueig canviat temporalment i feu després una petició nova i innòcua i confirmeu que segueix el túnel. Una petició que té èxit perquè el bloqueig encara està desactivat no demostra res sobre el túnel.

Canviar la sortida de la VPN no renovarà una sessió d’hotel caducada. Són esdeveniments diferents, i confondre’ls us envia a buscar al lloc equivocat.