Hvorfor openfortivpn-login mislykkes, når du indsætter portalens URL

Fejlen ligner et problem med legitimationsoplysningerne: openfortivpn spørger efter adgangskoden, sender den, og gatewayen svarer med en afvisning eller en omdirigering tilbage til login-siden. Brugerne skriver derefter adgangskoden igen, prøver det domænekvalificerede kontonavn og indsætter til sidst browserens portal-URL i vært-feltet. Det sidste træk er det, der gør en lille konfigurationsfejl til en forvirrende en.

En Fortinet-portaladresse som https://vpn.example.com/ext bærer flere oplysninger på én gang, og kun nogle af dem hører til VPN-klienten.

Endepunktet og realm er separate input

openfortivpn forventer et endepunkt i formen host eller host:port samt en konto og, hvor udrulningen bruger en, en realm-værdi. Realm fortæller gatewayen, hvilken godkendelsespolitik der skal anvendes, før den vurderer kontoen. Det er et separat felt, ikke et suffiks, som klienten udleder af en URL.

For en udrulning, hvor operatøren bekræfter, at realm er ext, ser et ikke-hemmeligt kald sådan ud: openfortivpn vpn.example.com:443 --username=alice --realm=ext. De samme værdier hører i konfigurationsfilen som host-, port-, username- og realm-poster. Lad adgangskoden være uden for begge former og lad klienten spørge, så den ikke ender i shell-historikken eller i en fil, alle kan læse. Et andet forsøg, mens den første klient stadig holder tunnelen, vil mislykkes af en grund, der intet har med realm at gøre.

openfortivpn-manualen viser begge muligheder, så den præcise stavemåde er nem at bekræfte, før du ringer til supporten. Den kan dog ikke fortælle dig, hvilket realm din gateway har konfigureret.

Et stisegment er ikke automatisk et realm

Portal-URL'er samler alle mulige ting efter værtsnavnet: en login-applikation, en sprogvælger, et omdirigeringsmål, en sessionsidentifikator. At klippe det sidste stisegment af og kalde det et realm virker tit nok til at være farligt. Spørg operatøren om den konfigurerede værdi, eller læs den fra den profil, din organisation uddeler.

Et realm er heller ikke det samme som et domænesuffiks på brugernavnet eller den region, gatewayen står i. Nogle udrulninger vil have alice, andre vil have alice@corp, og realm afgør, hvilken af dem gatewayen accepterer. At ændre kontoformatet for at kompensere for et forkert realm giver normalt en anden, mindre informativ afvisning.

Ret ikke en realm-fejl ved at ændre værten

At bytte værtsnavnet ud med en IP-adresse føles som at fjerne et lag, og det ødelægger mere, end det retter. TLS-navnevalidering sammenligner certifikatet med det navn, klienten brugte, og en IP-adresse optræder sjældent i et certifikats alternative navne. Server Name Indication ændrer sig med adressen, så en gateway, der hoster flere portaler på én adresse, kan svare med den forkerte. Behold værtsnavnet og tillidskonfigurationen intakt, mens du retter godkendelsesparameteren.

Hvis certifikatet ikke er betroet i dit miljø, skal du rette tillidslageret eller bevidst pinne det forventede certifikat. At slå verifikation fra for at komme uden om en realm-fejl bytter et login-problem for en risiko for tavs aflytning.

Adskil et afvist login fra en mislykket tunnel

Godkendelsesfejl og tunnelfejl kommer på forskellige tidspunkter, og meddelelserne er forskellige. En navneopløsningsfejl sker før enhver TLS-håndtryk. En TLS-afvisning sker, før legitimationsoplysninger sendes. En afvisning af realm eller konto kommer tilbage som et svar på HTTP-niveau fra portalen. Først efter disse faser begynder PPP-forhandlingen, og først da vises rute- og DNS-problemer.

Et korrekt realm skaber ikke en manglende rute, og det får ikke en ikke-understøttet loginmetode til at virke. Hvis portalen insisterer på et browserbaseret flow, så brug klientens understøttede vej til det flow i stedet for at gentage en adgangskodeudveksling og håbe på, at sessionen passer.

Behold værdierne, hvor næste start vil finde dem

Når en forbindelse lykkes, skal du skrive gateway, port, konto og realm i den administrerede profil i stedet for et shell-alias. Profiler, der opbevares i et repository eller et konfigurationsstyringssystem, forhindrer, at næste start i al hemmelighed samler et andet profils realm op.

Test en forbindelse igen fra ende til anden, og bekræft både den politik, der blev anvendt, og adgangen til en ressource, du faktisk har brug for. At godkendelsen lykkes er starten på den kontrol, ikke slutningen.