Per què el portal captiu bloqueja la teva VPN i com tornar a iniciar sessió

En una xarxa oberta, el teu punt d'accés no lliura els paquets a internet així com així. Un punt de política més amunt comprova si el teu dispositiu ja ha estat autoritzat, i fins que no ho està, gairebé tot es descarta. El client VPN llegeix aquest silenci com un servidor mort. Poques vegades ho diu: WireGuard reintenta un intercanvi de salutació dins del buit, OpenVPN informa d'un temps d'espera de connexió, i IKEv2 torna amb l'error 809 sobre un servidor remot que no respon.

Què controla realment el portal

Un portal captiu són dues coses enganxades: un punt de decisió de política i un redireccionador. Quan el teu dispositiu s'associa i obté una concessió DHCP, la xarxa et posa en un estat previ a l'autorització.

Aquest estat és un conjunt de regles de tallafocs. Normalment permet DNS i permet HTTP o HTTPS cap a una llista curta d'amfitrions del portal, i descarta tota la resta. La llista permesa és el jardí emmurallat, i gairebé mai no inclou un extrem de VPN.

Cap d'aquests descarts no és amable. Els paquets adreçats a un servidor VPN es descarten en lloc de rebutjar-se, així que el client no rep cap ICMP unreachable ni cap reset de TCP, només l'absència de resposta. Segons el fabricant, el redireccionador pot respondre al port 80 amb una redirecció a la pàgina d'inici de sessió mentre el port 443 es descarta o s'intercepta. Les redireccions són fàcils de detectar perquè porten una resposta HTTP simple; la intercepció al 443 necessita un certificat que el teu navegador es negarà a confiar.

L'autorització mateixa sol estar lligada a l'adreça MAC del dispositiu, de vegades a la IP concedida, i viu en una taula de sessions amb un temporitzador. Iniciar sessió crea una entrada. La regla de tallafocs que deixa passar el teu trànsit només existeix mentre existeix aquesta entrada, i per això tot el problema torna més tard sense que canviï res de la teva banda.

Per què l'intercanvi de salutació de la VPN mor abans de començar

Cada protocol té el seu transport, i el tallafocs previ a l'autorització trenca cadascun de manera diferent. IKEv2 a Windows i iOS va sobre UDP 500 i UDP 4500; un descart en aquests ports es manifesta com a 809, o com una fallada d'estil de resolució de noms en clients que informen de les etapes per separat. OpenVPN sobre UDP 1194 es queda en estat de connexió fins que expira el seu temps d'espera. OpenVPN sobre TCP 443 és el cas interessant, perquè el portal pot completar l'intercanvi TCP i després respondre amb la seva pàgina de redirecció, així que veus un error TLS en lloc d'un temps d'espera.

WireGuard mostra el mecanisme amb més claredat. És només UDP per disseny, sense alternativa TCP, així que un tallafocs que descarta UDP desconegut elimina el transport del tot. El client continua enviant inicis d'intercanvi amb retrocés creixent i informa d'un intercanvi que no s'acaba mai. Res en aquest missatge no esmenta el Wi-Fi, i res no suggereix que hagis d'obrir un navegador.

Les plataformes intenten notar l'estat abans que la teva VPN. Windows demana una URL coneguda per decidir si mostra la notificació d'inici de sessió, Android sol·licita un extrem que hauria de respondre 204 No Content, i els dispositius Apple obren una petita finestra de xarxa captiva. Aquestes sondes funcionen perquè el portal respon amb una redirecció en lloc del cos esperat. El mateix comportament explica com un portal pot semblar perfectament sa mentre el teu túnel és mort: la sonda i el túnel es jutgen amb regles diferents.

Què reinicia realment una caducitat de sessió

Els locals caduquen les sessions per motius aliens al teu compte de VPN: un temps d'inactivitat, una durada màxima de sessió, una nova concessió DHCP o una reassociació a un altre punt d'accés. Quan el temporitzador salta, l'entrada de la taula de sessions desapareix i el conjunt de regles previ a l'autorització torna exactament com era en el registre.

Un túnel establert sovint sobreviu prou temps per semblar sa. Els missatges de manteniment continuen sortint, i si el client ho nota depèn de com tracta el trànsit sense resposta, així que el llum d'estat pot quedar-se verd una estona després que el camí desaparegui. Llavors el túnel cau i cada intent de reconnexió falla als mateixos ports bloquejats.

En aquest punt, l'error del client et diu en quina etapa ets, si el llegeixes amb atenció:

Un detall enganya la gent: quan la sessió està lligada a una adreça MAC, recarregar la pàgina d'inici de sessió pot no ajudar. Has de trencar l'associació i tornar-te a connectar perquè el portal vegi un nou intent d'autorització en lloc d'un de caducat.

Primer inicia sessió, després aixeca el túnel

L'ordre que funciona és: autoritza el dispositiu, demostra el camí, engega la VPN, demostra el túnel i després restaura el teu bloqueig habitual. Aquest darrer pas importa perquè l'estat temporal que necessites per arribar al portal és exactament l'estat que un interruptor de seguretat existeix per evitar.

Un client d'escriptori amb l'opció de bloquejar fora del túnel s'ha de posar en pausa perquè es carregui la pàgina del portal, i hauries de mantenir les aplicacions sensibles tancades durant aquesta finestra fora del túnel; és l'únic interval en què el trànsit local surt sense protecció. Un dispositiu gestionat sempre engegat hauria d'usar el procediment que el seu propietari ha publicat en lloc que siguis tu qui elimini la política. Si el portal mostra un avís de certificat, atura't: acceptar-lo encamina la teva sessió pel proxy d'intercepció del local, i aquest proxy pot llegir tot el que envies. A Android, el bloqueig sota VPN sempre engegada bloqueja el trànsit abans que el túnel estigui aixecat, i algunes compilacions no poden eximir el flux del portal; si la teva no pot, usa l'accés alternatiu del local o un altre dispositiu en lloc de deixar el bloqueig desactivat. Les regles d'Apple sota demanda es poden escriure perquè rebutgin el túnel fins que una sonda tingui èxit, que és el comportament que vols en xarxes d'hotel.

Verifica per ordre amb les eines que ja tens. Abans del túnel, executa la sonda amb les capçaleres i el cos tots dos visibles, i mira si el teu transport VPN rep cap resposta:

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'

Abans de l'autorització, un portal normal dóna una de dues respostes: un 302 el Location del qual apunta a la pàgina d'inici de sessió, o un 200 amb un cos HTML que és la pàgina del portal. Anota quin has rebut. Una redirecció no és una fallada abans d'iniciar sessió; és el portal dient-te on has d'anar. Després que el portal informi d'èxit, repeteix l'ordre i espera un 200 el cos del qual sigui la paraula literal Success. Aquesta cadena és el que fa significativa la sonda. Si l'amfitrió respon amb normalitat abans que hagis iniciat sessió, en aquesta xarxa no hi ha cap portal d'intercepció. A la captura, un descart previ a l'autorització són paquets sortints dels quals no torna res, mentre que un camí que funciona mostra una resposta al mateix flux en cosa d'un segon. Connecta't i després repeteix la captura.

Si el túnel encara falla després que el portal digui sí

L'èxit d'inici de sessió no és el mateix que un transport permès. Molts locals permeten el portal i la navegació normal mentre bloquegen UDP de ple, cosa que deixa WireGuard i OpenVPN sobre UDP trencats i TCP 443 funcionant. Si TCP 443 passa i UDP no, això és política del local i no un client mal configurat per tu, així que canvia de transport o accepta el límit i continua. Si una reconnexió encara falla després d'això, guarda l'error exacte; anomena l'etapa on estàs encallat.

Altres fallades viuen al dispositiu. Una sessió encara lligada a una MAC antiga, un segon adaptador Wi-Fi amb la seva pròpia concessió, o un client que ha memoritzat l'excepció de certificat del portal poden continuar fallant després d'una reautorització neta. Trenca l'associació, torna a autoritzar i reintenta una vegada abans de tocar la configuració del client. RFC 8952 val la pena llegir-lo si vols l'arquitectura que hi ha darrere dels components que estàs vigilant.

Si el portal mateix es nega a autoritzar, el problema és del compte o de l'assignació del dispositiu i cap configuració de VPN ho arreglarà. Canviar el país de sortida de la VPN no reinicia l'estat d'accés local del local; aquesta taula està lligada al teu dispositiu, no al servidor que triïs. Pregunta a l'operador del local i dóna-li temps, perquè la taula de sessions és el que mirarà.

Abans del teu proper viatge, anota tres coses: la pàgina del portal com a pas zero, el pas de pausar el bloqueig per a cada dispositiu que portis, i una alternativa de transport que hagis provat de veritat. Quan un túnel que funcionava fa deu minuts torni a parar-se, tracta'l com una autorització caducada i torna a comprovar el portal abans de tocar el perfil de la VPN.