Varför openfortivpn-inloggningen misslyckas när du klistrar in portalens URL

Felet ser ut som ett problem med inloggningsuppgifterna: openfortivpn frågar efter lösenordet, skickar det, och gatewayen svarar med en avvisning eller en omdirigering tillbaka till inloggningssidan. Användarna skriver då lösenordet igen, provar det domänkvalificerade kontonamnet och klistrar till slut in webbläsarens portal-URL i värd-fältet. Det är just detta sista steg som gör ett litet konfigurationsfel till ett förvirrande.

En Fortinet-portaladress som https://vpn.example.com/ext bär flera uppgifter samtidigt, och bara några av dem tillhör VPN-klienten.

Slutpunkten och realm är separata indata

openfortivpn förväntar sig en slutpunkt i formen host eller host:port, plus ett konto och, där distributionen använder en, ett realm-värde. Realm talar om för gatewayen vilken autentiseringspolicy som ska tillämpas innan kontot utvärderas. Det är ett eget fält, inte ett suffix som klienten plockar ut ur en URL.

För en distribution vars operatör bekräftar att realm är ext, ser ett icke-hemligt anrop ut så här: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Samma värden hör hemma i konfigurationsfilen som host-, port-, username- och realm-poster. Lämna lösenordet utanför båda formerna och låt klienten fråga efter det, så att det inte hamnar i skallhistoriken eller i en fil som alla kan läsa. Ett nytt försök medan den första klienten fortfarande håller tunneln kommer att misslyckas av en anledning som inte har något med realm att göra.

openfortivpn-handboken listar båda alternativen, så den exakta stavningen är lätt att bekräfta före ett supportsamtal. Den kan dock inte tala om vilket realm som är konfigurerat på din gateway.

Ett sökvägssegment är inte automatiskt ett realm

Portal-URL:er samlar allehanda saker efter värdnamnet: en inloggningsapplikation, en språkväljare, ett omdirigeringsmål, en sessionsidentifierare. Att klippa bort det sista sökvägssegmentet och kalla det ett realm fungerar tillräckligt ofta för att vara farligt. Fråga operatören efter det konfigurerade värdet, eller läs det från profilen som din organisation distribuerar.

Ett realm är inte heller samma sak som ett domänsuffix på användarnamnet eller regionen där gatewayen ligger. Vissa distributioner vill ha alice, andra vill ha alice@corp, och realm avgör vilket av dem gatewayen accepterar. Att ändra kontoformatet för att kompensera för ett felaktigt realm ger vanligtvis en andra, mindre informativ avvisning.

Åtgärda inte ett realm-fel genom att byta värd

Att byta ut värdnamnet mot en IP-adress känns som att ta bort ett lager, och det bryter mer än det reparerar. TLS-namnvalidering jämför certifikatet med namnet som klienten använde, och en IP-adress förekommer sällan i ett certifikats alternativa subjektnamn. Server Name Indication ändras med adressen, så en gateway som är värd för flera portaler på en adress kan svara med den felaktiga. Behåll värdnamnet och förtroendekonfigurationen intakta medan du korrigerar autentiseringsparametern.

Om certifikatet inte är betrott i din miljö, reparera förtroendelagret eller fäst det förväntade certifikatet medvetet. Att stänga av verifieringen för att komma runt ett realm-fel byter ett inloggningsproblem mot en risk för tyst avlyssning.

Skilj en avvisad inloggning från en misslyckad tunnel

Autentiseringsfel och tunnelfel inträffar vid olika tidpunkter, och meddelandena skiljer sig. Ett namnupplösningsfel inträffar före varje TLS-handskakning. En TLS-avvisning inträffar innan inloggningsuppgifter skickas. En avvisning av realm eller konto kommer tillbaka som ett svar på HTTP-nivå från portalen. Först efter dessa faser börjar PPP-förhandlingen, och först då dyker routing- och DNS-problem upp.

Ett korrekt realm skapar ingen saknad rutt och får inte en icke-stödd inloggningsmetod att fungera. Om portalen insisterar på ett webbläsarbaserat flöde, använd klientens stödda väg för det flödet i stället för att upprepa ett lösenordsutbyte och hoppas att sessionen matchar.

Förvara värdena där nästa start hittar dem

När en anslutning lyckas, skriv gatewayen, porten, kontot och realm i den hanterade profilen i stället för i ett skalalias. Profiler som förvaras i ett arkiv eller ett konfigurationshanteringssystem hindrar nästa start från att tyst plocka upp en annan profils realm.

Testa en anslutning igen från början till slut och bekräfta både policyn som tillämpades och åtkomsten till en resurs som du faktiskt behöver. Att autentiseringen lyckas är början på den kontrollen, inte slutet.