Per què falla l’inici de sessió d’openfortivpn en enganxar l’URL del portal
Una ruta de portal com /ext no és un realm. Passa la passarel·la com a host i port, defineix el realm per separat i conserva el nom d’amfitrió perquè les comprovacions TLS continuïn passant.
El fracàs sembla un problema de credencials: openfortivpn demana la contrasenya, l’envia i la passarel·la respon amb un rebuig o amb una redirecció cap a la pàgina d’inici de sessió. Llavors els usuaris tornen a escriure la contrasenya, proven el nom de compte qualificat amb el domini i, finalment, enganxen l’URL del portal del navegador al camp d’amfitrió. Aquest darrer moviment és el que converteix un petit error de configuració en un error desconcertant.
Una adreça de portal de Fortinet com https://vpn.example.com/ext porta diverses peces d’informació alhora, i només algunes pertanyen al client VPN.
El punt final i el realm són entrades separades
openfortivpn espera un punt final en forma de host o host:port, més un compte i, quan el desplegament en fa servir un, un valor de realm. El realm diu a la passarel·la quina política d’autenticació cal aplicar abans d’avaluar el compte. És un camp separat, no un sufix que el client extregui d’una URL.
Per a un desplegament l’operador del qual confirma que el realm és ext, una invocació no secreta té aquest aspecte: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Els mateixos valors van al fitxer de configuració com a entrades host, port, username i realm. Deixa la contrasenya fora de les dues formes i permet que el client la demani, perquè no acabi a l’historial de l’intèrpret ni en un fitxer llegible per tothom. Un segon intent mentre el primer client encara té el túnel fallarà per un motiu que no té res a veure amb el realm.
El manual d’openfortivpn llista totes dues opcions, així que és fàcil confirmar l’ortografia exacta abans de trucar al suport. No et pot dir, però, quin realm té configurat la teva passarel·la.
Un segment de ruta no és automàticament un realm
Els URL de portal apleguen tota mena de coses després del nom d’amfitrió: una aplicació d’inici de sessió, un selector d’idioma, una destinació de redirecció, un identificador de sessió. Tallar l’últim segment de ruta i anomenar-lo realm funciona prou sovint per ser perillós. Demana a l’operador el valor configurat o llegeix-lo del perfil que distribueix la teva organització.
Un realm tampoc no és el mateix que un sufix de domini al nom d’usuari o que la regió on es troba la passarel·la. Alguns desplegaments volen alice, d’altres volen alice@corp, i el realm decideix quin d’aquests acceptarà la passarel·la. Canviar el format del compte per compensar un realm incorrecte sol produir un segon rebuig, menys informatiu.
No arreglis un error de realm canviant l’amfitrió
Canviar el nom d’amfitrió per una adreça IP sembla treure una capa, i trenca més del que arregla. La validació del nom TLS compara el certificat amb el nom que va fer servir el client, i una adreça IP poques vegades apareix als noms alternatius del subjecte d’un certificat. La indicació del nom del servidor canvia amb l’adreça, així que una passarel·la que allotja diversos portals en una adreça pot respondre amb el portal equivocat. Mantén intactes el nom d’amfitrió i la configuració de confiança mentre corregeixes el paràmetre d’autenticació.
Si el certificat no és de confiança al teu entorn, arregla el magatzem de confiança o fixa deliberadament el certificat esperat. Desactivar la verificació per saltar-se un error de realm canvia un problema d’inici de sessió per un risc d’intercepció silenciosa.
Separa un inici de sessió rebutjat d’un túnel fallit
Els errors d’autenticació i els errors de túnel arriben en moments diferents, i els missatges són diferents. Un error de resolució de noms passa abans de qualsevol handshake TLS. Un rebuig TLS passa abans que s’enviïn les credencials. Un rebuig de realm o de compte torna com a resposta a nivell HTTP del portal. Només després d’aquestes etapes comença la negociació PPP, i només llavors apareixen problemes d’encaminament i DNS.
Un realm correcte no crea una ruta que falta ni fa funcionar un mètode d’inici de sessió no compatible. Si el portal insisteix en un flux basat en navegador, fes servir el camí compatible del client per a aquest flux en lloc de repetir un intercanvi de contrasenya i esperar que la sessió coincideixi.
Guarda els valors on els trobarà el proper llançament
Un cop una connexió funciona, escriu la passarel·la, el port, el compte i el realm al perfil gestionat en lloc d’un àlies d’intèrpret. Els perfils que es guarden en un repositori o en un sistema de gestió de configuració eviten que el proper llançament agafi en silenci el realm d’un altre perfil.
Torna a provar una connexió de cap a cap i confirma tant la política aplicada com l’accés a un recurs que realment necessitis. Que l’autenticació funcioni és l’inici d’aquesta comprovació, no el final.