OpenConnect-inloggningen landar på fel sida? Kontrollera sökvägen först

Du klistrar in adressen från onboarding-mejlet, klienten når gatewayen, och inloggningsformuläret som visas är den allmänna portalen och inte partnerportalen som operatören beskrev. Inget ger fel, och just det förvirrar: tunneln kan till och med komma upp, bara bakom fel ingångspunkt. Sökvägen i den URL:en gjorde arbete, och vad som än ersatte den tappade det arbetet.

Skilj på två saker som kommer som en enda sträng i ett ärende: adressen som når tjänsten och indata som avgör var autentiseringen börjar. Att reparera det första medan det andra ignoreras är hur ett korrekt värdnamn ändå ger fel inloggning.

Vad klienten skickar innan du ser ett formulär

Med en adress som https://vpn.example.net/partners är klientens första handling en HTTPS-begäran till den sökvägen i stället för till den bara värden. Det som kommer tillbaka är vanligtvis en omdirigering till inloggningsslutpunkten, eller formuläret självt. En klient som bara får vpn.example.net börjar på den standardlandningssida som finns, och det kan vara en annan portal, en annan grupplista eller en sida som förväntar sig ett helt annat protokoll. Skillnaden syns i svarshuvudena långt innan några inloggningsuppgifter skrivs in.

Därför kan en fungerande webbläsarflik och en misslyckad klientprofil nämna samma gateway och ändå inte vara överens. Webbläsaren följde sökvägen; profilen hade den aldrig.

Två indata som ser utbytbara ut och inte är det

OpenConnect exponerar den inledande HTTPS-sökvägen som --usergroup, och handbokssidan behandlar en fullständig URL med den sökvägen som samma begäran skriven annorlunda. --authgroup är ett separat alternativ: det väljer en post från listan som gatewayen visar inne i inloggningsformuläret. Vissa protokoll kallar posten en grupp, andra en domän eller en gateway, och det är just där de två flaggorna blandas ihop.

En tjänst kan legitimt behöva båda. Sökvägen kan ta dig till rätt portal medan formuläret fortfarande ber dig välja bland grupper inuti den. Att ange portalnamnet som gruppnamn, eller tvärtom, ger en inloggning som ser accepterad ut och sedan inte auktoriserar, eftersom värdet var syntaktiskt giltigt och semantiskt fel.

Be operatören om varje värde på sin egen rad: ingångssökväg, formulärval och om båda krävs. Härled inte det ena från det andra bara för att etiketterna låter lika.

Varför avkortning av sökvägen ändrar resultatet

Klienter som bara accepterar värd och port ansluter ofta ändå, så symtomet är sällan ett hårt fel. I stället får du fel inloggningssida, en tom grupplista, ett certifikatnamn som inte längre stämmer med det operatören publicerade, eller en tunnel som kommer upp utan rutt till tjänsten du ville ha. Var och en av dessa sitter i ett annat lager, och ingen av dem repareras genom att klistra in en längre sträng i ett fält som dokumenterats som värdnamn. Två av dem går inte heller att skilja utifrån, eftersom båda kommer som ett inloggningsformulär som helt enkelt inte fortsätter.

Att ersätta värdnamnet med en IP-adress är ett separat fel som ofta reser med detta. Namnbaserat tjänsteval och certifikatvalidering beror båda på namnet, så en numerisk adress kan göra ett sökvägsformatproblem till ett TLS-fel.

Webbläsaradresser bär också mer än sökvägar. Sessionsidentifierare, omdirigeringsmål, språkprefix och tillfälliga inloggningsparametrar dyker alla upp i adressfältet, och ingen av dem hör hemma i en sparad klientprofil.

Bekräfta ingångspunkten innan du redigerar något annat

Läs huvudena för sökvägen du fick. En begäran som curl -sS -o /dev/null -D - https://vpn.example.net/partners skriver ut statusraden och eventuellt Location-huvud utan att följa omdirigeringen. En 302 som pekar på en namngiven inloggningsslutpunkt bekräftar att sökvägen finns och visar vart den leder; en 404 betyder att operatörens adress är inaktuell.

Återskapa sedan samma ingångspunkt i den godkända klienten, till exempel openconnect --usergroup=partners vpn.example.net, och se vilket formulär som visas. Om formuläret är korrekt och tunneln fortfarande misslyckas var sökvägen aldrig problemet, och nästa stopp är policy eller routing.

Notera värdnamn, port, protokoll, ingångssökväg och formulärval som fem separata fält i ärendet. Den listan är det som låter nästa ingenjör skilja en oåtkomlig server från en TLS-avvisning, ett avvisat val och en tunnel som kom upp utan de rutter den behövde.