Por que falla o inicio de sesión de openfortivpn ao pegar a URL do portal

O fallo parece un problema de credenciais: openfortivpn pide o contrasinal, envíao e a pasarela responde cun rexeitamento ou cunha redirección de volta á páxina de inicio de sesión. Entón os usuarios volven escribir o contrasinal, proban o nome de conta cualificado por dominio e acaban pegando a URL do portal do navegador no campo de host. Ese último movemento é o que converte un pequeno erro de configuración nun erro confuso.

Un enderezo de portal de Fortinet como https://vpn.example.com/ext leva varias pezas de información á vez, e só algunhas pertencen ao cliente VPN.

O punto final e o realm son entradas separadas

openfortivpn espera un punto final en forma de host ou host:port, ademais dunha conta e, cando o despregamento usa unha, un valor de realm. O realm di á pasarela que política de autenticación aplicar antes de avaliar a conta. É un campo separado, non un sufixo que o cliente extraia dunha URL.

Para un despregamento cuxo operador confirma que o realm é ext, unha invocación non secreta ten este aspecto: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Os mesmos valores van no ficheiro de configuración como entradas host, port, username e realm. Deixa o contrasinal fóra de ambas as formas e deixa que o cliente o pida, para que non acabe no historial da consola nin nun ficheiro lexible por todos. Un segundo intento mentres o primeiro cliente aínda mantén o túnel fallará por un motivo que non ten nada que ver co realm.

O manual de openfortivpn enumera ambas as opcións, así que a ortografía exacta é fácil de confirmar antes de chamar ao soporte. Non pode dicirche, con todo, que realm ten configurado a túa pasarela.

Un segmento de ruta non é automaticamente un realm

As URL de portal xuntan todo tipo de cousas despois do nome de host: unha aplicación de inicio de sesión, un selector de idioma, un destino de redirección, un identificador de sesión. Cortar o último segmento de ruta e chamalo realm funciona con suficiente frecuencia como para ser perigoso. Pregunta ao operador polo valor configurado ou leo do perfil que distribúe a túa organización.

Un realm tampouco é o mesmo que un sufixo de dominio no nome de usuario ou que a rexión na que se atopa a pasarela. Algúns despregamentos queren alice, outros queren alice@corp, e o realm decide cal deles aceptará a pasarela. Cambiar o formato da conta para compensar un realm incorrecto adoita producir un segundo rexeitamento, menos informativo.

Non arranxes un erro de realm cambiando o host

Cambiar o nome de host por un enderezo IP parece quitar unha capa, e rompe máis do que arranxa. A validación do nome TLS compara o certificado co nome que usou o cliente, e un enderezo IP raramente aparece nos nomes alternativos do suxeito dun certificado. A indicación do nome do servidor cambia co enderezo, así que unha pasarela que aloxa varios portais nun enderezo pode responder co equivocado. Mantén intactos o nome de host e a configuración de confianza mentres corrixes o parámetro de autenticación.

Se o certificado non é de confianza na túa contorna, arranxa o almacén de confianza ou fixa deliberadamente o certificado esperado. Desactivar a verificación para sortear un erro de realm cambia un problema de inicio de sesión por un risco de intercepción silenciosa.

Separa un inicio de sesión rexeitado dun túnel fallido

Os fallos de autenticación e os fallos de túnel chegan en momentos distintos, e as mensaxes son diferentes. Un erro de resolución de nomes ocorre antes de calquera handshake TLS. Un rexeitamento TLS ocorre antes de que se envíen as credenciais. Un rexeitamento de realm ou de conta volve como unha resposta a nivel HTTP do portal. Só despois desas etapas comeza a negociación PPP, e só entón aparecen problemas de enrutamento e DNS.

Un realm correcto non crea unha ruta que falta nin fai que funcione un método de inicio de sesión non compatible. Se o portal insiste nun fluxo baseado no navegador, usa a ruta compatible do cliente para ese fluxo en lugar de repetir un intercambio de contrasinal e esperar que a sesión coincida.

Garda os valores onde os atopará o próximo arranque

Cando unha conexión funcione, escribe a pasarela, o porto, a conta e o realm no perfil xestionado en lugar dun alias da consola. Os perfís gardados nun repositorio ou nun sistema de xestión de configuración evitan que o próximo arranque colla en silencio o realm doutro perfil.

Proba de novo unha conexión de principio a fin e confirma tanto a política aplicada como o acceso a un recurso que realmente necesites. Que a autenticación funcione é o principio desa comprobación, non o final.