Separe os inícios de sessão do portal Wi-Fi dos do VPN
Dois sistemas diferentes pedem a mesma coisa: iniciar sessão. O portal controla o acesso local; o VPN, o acesso a uma rede privada. Pergunte em cada janela quem pode verificar realmente esse segredo.
Dois sistemas diferentes pedem-lhe que inicie sessão antes de chegar a algo útil numa rede pública: o Wi-Fi do local e a sua gateway VPN. Parecem iguais no ecrã e autorizam coisas completamente diferentes. O portal decide se este dispositivo pode usar a rede local; o VPN decide se pode chegar a uma rede privada noutro sítio. Mantenho-os separados fazendo uma pergunta a cada janela: quem pode verificar realmente este segredo? O que se segue é a lista de verificação que aplico em hotéis, aeroportos e centros de conferências, incluindo os pontos em que deixo de escrever.
Associe cada início de sessão ao serviço que o verifica
Uma única ligação de hotel pode envolver quatro verificações separadas, e apenas algumas querem a sua intervenção. Ponha-as primeiro por ordem, porque o ecrã raramente diz a que etapa pertence.
| Stage | Who checks it | What you give it | What it proves |
|---|---|---|---|
| Wi-Fi association | The access point | WPA2 passphrase or 802.1X credentials | That the device may join this SSID |
| Portal authorization | The venue or its portal provider | Room number, booking name, voucher, email or access code | That a guest may use local access |
| VPN authentication | Your gateway or identity provider | Client certificate, password, one-time code or SSO approval | That the user or device may enter the private network |
| Application login | Each internal service | That service's own account | That you may use that service |
As redes 802.1X, comuns em escritórios e universidades, esbatem as duas primeiras linhas. Aí o início de sessão Wi-Fi é ele próprio uma verificação de identidade contra um servidor RADIUS, e o cliente pode apresentar uma identidade de encaminhamento enquanto a conta real viaja dentro da troca cifrada. Mesmo assim, a verificação é sobre aderir à rede; não autoriza o túnel, e a gateway VPN não a aceita como prova de nada.
A ordem importa mais do que os rótulos. Os portais cativos existem porque o acesso pode ser concedido após a associação, e é por isso que um local pode entregar a página a um fornecedor especializado. O RFC 8952 da IETF trata o portal como um componente próprio, pelo que um domínio desconhecido é motivo para verificar, não prova de fraude por si só. Compare o domínio com as instruções escritas do local e os campos com a tabela.
Verifique o que um portal pode pedir
Os campos do portal dizem respeito ao direito de acesso, não à identidade: número do quarto, apelido da reserva, código do voucher, o código impresso na capa da chave, um e-mail para um passe temporário, aceitação dos termos. O local já sabe quem reservou o quarto, por isso pode cruzar esses dados sem aprender nada que lhe permitisse agir como você noutro sítio.
Qualquer coisa além dessa lista merece uma pausa. Uma página de hotspot não pode verificar a sua palavra-passe de domínio, e também não pode verificar o seu código de utilização única do VPN, um código de recuperação ou uma chave privada, e não tem motivo para os querer. A única exceção legítima é uma rede gerida por uma organização: um SSID de convidados de escritório ou um Wi-Fi de conferência podem encaminhá-lo para o fornecedor de identidade que já usa para o trabalho. Continua a ser distinguível: o anfitrião de início de sessão é o seu diário, o ecrã de consentimento nomeia o seu tenant e o fluxo abre num separador visível do navegador.
O e-mail de marketing é à parte: um alias de viagem satisfaz o campo sem entregar a sua identidade profissional.
Verifique se o cliente VPN quer as suas próprias credenciais
O cliente pede exatamente aquilo para que o seu perfil está configurado, pelo que a janela esperada é uma propriedade do perfil e não da rede em que se encontra. Os perfis de certificado mostram geralmente uma escolha de perfil e depois ligam-se em silêncio. Os perfis de nome de utilizador e palavra-passe pedem ambos, muitas vezes com um código de utilização única. Os perfis SSO abrem o seu navegador no fornecedor de identidade e voltam com um token. O WireGuard é diferente outra vez: autentica dispositivos com chave pública e não tem início de sessão de utilizador, pelo que uma janela que oferece nome de utilizador e palavra-passe do WireGuard não descreve o WireGuard.
Leia o perfil antes de viajar. Em OpenVPN, auth-user-pass diz-lhe que é esperado um pedido de palavra-passe, enquanto cert, key ou pkcs12 significa que um certificado deveria fazer o trabalho. Se um perfil que normalmente liga sem pedido pedir de repente uma palavra-passe, suspeite de um perfil que não conseguiu carregar o certificado ou que recuou para outro método. Um pedido não é um convite para escrever a palavra-passe de trabalho em qualquer janela que tenha aparecido.
Nenhum cliente VPN legítimo pede o número do quarto, o voucher do portal ou a frase de acesso do Wi-Fi como entrada de autenticação. Quando isso acontece, ou o cliente não é o que diz ser, ou um portal cativo interceta o tráfego antes de o túnel se formar e está a ler uma página HTML desenhada para parecer um início de sessão.
Pare nestas cinco condições
Estes são os pontos em que paro em vez de continuar com uma solução alternativa plausível. Cada um é barato de verificar e caro de errar.
- Aparece um aviso de certificado ou TLS no portal ou na página SSO. Não o ultrapasse clicando para chegar à rede.
- A página pede um segredo que só a gateway VPN ou o fornecedor de identidade podem verificar: palavra-passe de domínio, código de utilização única, código de recuperação, chave privada.
- O domínio não corresponde às instruções impressas do local nem ao anfitrião de início de sessão que a sua organização documenta para os seus próprios serviços.
- Pedem-lhe para instalar um certificado raiz, um perfil de configuração ou uma aplicação auxiliar que não vem da gestão dos seus dispositivos.
- Chega uma aprovação MFA que não iniciou, ou o cliente VPN pede credenciais do hotel.
A alternativa não é outra palavra-passe. Use um hotspot de telemóvel, pergunte na receção o nome exato da rede e o método de acesso, e reporte a página a quem gere a rede ou ao seu serviço de TI. Nada disso exige testar uma credencial contra uma página que não consegue atribuir.
Atribua uma falha à etapa correta
Depois de ambas as etapas passarem, as falhas continuam a acontecer, e o erro nomeia geralmente a etapa se for lido por ordem: associação, atribuição de endereço, autorização do portal, estabelecimento do túnel, depois o recurso interno. Mudar uma palavra-passe do VPN porque um código do portal expirou perde tempo e deixa o problema real no lugar.
Algumas provas separam as etapas. Após o início de sessão no portal, peça uma página HTTPS pública comum. Se voltar o portal em vez dela, a autorização nunca foi concluída nessa camada. Se o cliente VPN indicar que não alcança a gateway, o problema está abaixo do túnel: a sessão do portal, a resolução de nomes ou uma rede que bloqueia a porta. Se o túnel subir e um nome de anfitrião interno falhar, a resolução de nomes ou a política dentro da rede privada é o suspeito mais provável.
As sessões do portal também expiram independentemente do túnel. Quando o local revoga o acesso, uma ligação VPN estabelecida cai mesmo que as suas credenciais nunca tenham estado erradas. Autorize novamente o portal, depois volte a ligar o VPN e deixe-o renegociar. Rodar a palavra-passe do VPN nessa altura não corrige nada e pode bloqueá-lo fora.
Dê cada segredo apenas ao sistema que o pode verificar, e trate um pedido que não encaixa na tabela como um sinal de stop e não como um passo a contornar. Se ambas as etapas passarem e o túnel continuar a recusar, capture o erro exato do cliente antes de mudar qualquer credencial.