O punto de acceso entrega un enderezo antes de entregar internet, e a confianza decidese nese oco. O dispositivo asóciase, pide un enderezo e entón cada petición de saída queda interceptada ata que un portal di que a sesión está autorizada. Ese mecanismo explica por que unha páxina pode parecer que carga mentres non existe ningunha conexión real. Probe o oco con algo inofensivo antes de que o toque calquera credencial de traballo.

Que fai o punto de acceso coa súa primeira petición

A asociación dálle ao dispositivo unha ligazón, e DHCP dálle un enderezo, unha pasarela e normalmente un servidor DNS propiedade do local. Ata que se completa a autorización, a pasarela descarta ou redirixe o tráfico de saída, e moitos portais responden ao DNS de cada nome coa súa propia dirección. Por iso unha consulta parece ter éxito: a resposta é o portal, non o sitio que pediu. A rede compórtase como foi deseñada; simplemente aínda non é internet.

A primeira petición HTTP recibe normalmente unha redirección ao portal, que o sistema operativo pode abrir por vostede. HTTPS non se pode redirixir así, de modo que falla ou colga, e o navegador mostra un erro de certificado ou un tempo de espera esgotado. A diferenza é diagnóstica: unha redirección HTTP é o portal falando, mentres que un fallo de TLS cara a un host non relacionado é outra cousa. Un xardín amurallado, onde se deixan pasar uns poucos dominios para pagamento ou inicio de sesión, produce un terceiro patrón.

Confirme a rede antes de iniciar sesión

Confirme o SSID e o método de inicio de sesión co local por unha canle que non sexa a propia rede. Un portal que pide un contrasinal corporativo, un número de tarxeta e un enderezo de correo fai tres cousas distintas, e só as dúas últimas son habituais para o acceso de convidados. Prefira o aviso de portal cativo do sistema operativo, que detecta a redirección mediante un extremo coñecido en lugar de confiar en calquera páxina que apareza. Se o local non pode describir o seu propio portal, é un motivo para esperar e non para improvisar.

Un aviso de certificado durante o inicio de sesión no portal non é un paso que se salte cun clic. O portal non precisa facerse pasar por un host non relacionado para autenticalo.

Faga a comprobación máis pequena que demostre acceso

Complete a autorización lexítima, despois solicite unha páxina HTTPS pública corrente que non cargase antes, para que a resposta non poida vir da caché. Anote que fallou realmente se falla: unha consulta de nome, un tempo de espera de conexión, un erro de certificado ou un rexeitamento do servizo. Eses catro pertencen a capas distintas, e anotalos evita que a seguinte persoa volva probar a cegas. Despois conecte a VPN prevista e solicite un recurso que a requira.

Manteña a proba pequena. Unha descarga de test de velocidade en acceso con límites responde a unha pregunta que ninguén fixo e pode custarlle diñeiro ao usuario. Unha resposta con cabeceiras abonda para establecer a alcanzabilidade, e non arrastra megabytes por unha ligazón que factura por xigabyte.

Se o acceso corrente funciona e o túnel non, é unha investigación distinta da dunha rede que nunca autorizou. Manteña os dous resultados separados en lugar de cambiar varios axustes de privacidade á vez.

Manteña o traballo privado fóra da comparación

Cada aplicación do dispositivo é un observador potencial, e un portal cativo é o momento en que todas intentan chegar aos seus servidores. Pecha as que poida, e trate un dispositivo xestionado sempre activo como unha cuestión de política e non técnica: use o método aprobado para a comparación en lugar de retirar a protección que o fai xestionado. Se o dispositivo prohibe por completo o tráfico fóra do túnel, faga a comprobación noutro dispositivo non sensible. O sentido do exercicio é aprender sobre a rede sen expoñerlle credenciais.

Non capture o tráfico doutras persoas para diagnosticar o local, e manteña calquera captura de diagnóstico dentro do seu propio dispositivo e sesión. Revise os campos de enderezo e identificador antes de adxuntar unha captura a un ticket, porque a rede do local non é o seu armario de probas.

Decida que lle permite facer o resultado

Son posibles tres resultados: acceso completo cun túnel que funciona, acceso só ao portal cun túnel que falla, ou ningún acceso. Cada un ten un seguinte paso distinto, e o valor da proba é saber en cal está antes de cambiar axustes. Acceso completo significa que o traballo pode seguir polo túnel; acceso só ao portal suxire que o porto ou o protocolo do túnel está bloqueado, así que a resposta é outro transporte ou outra rede; ningún acceso significa que o local hoxe non pode soportar a tarefa. Un dispositivo que só proba un protocolo non pode distingilos.

Anote o SSID, o resultado e a hora, para que a seguinte persoa no mesmo local comece con probas. A guía de redes cativas de Apple describe o comportamento de detección detrás do aviso, que é a parte que merece entenderse antes de culpar a VPN.

Artigos relacionados