OpenConnect-login lander på den forkerte side? Tjek stien først

Du indsætter adressen fra onboarding-mailen, klienten når gatewayen, og den loginformular, der vises, er den generelle portal og ikke den partnerportal, operatøren beskrev. Intet giver fejl, og det er netop det forvirrende: tunnelen kan endda komme op, blot bag det forkerte indgangspunkt. Stien i den URL gjorde arbejde, og hvad der end erstattede den, tabte arbejdet.

Adskil to ting, der ankommer som én streng i en sag: adressen, der når tjenesten, og det input, der afgør, hvor autentificeringen begynder. At reparere det første og ignorere det andet er måden, hvorpå et korrekt værtsnavn stadig giver det forkerte login.

Hvad klienten sender, før du ser en formular

Med en adresse som https://vpn.example.net/partners er klientens første handling en HTTPS-anmodning til den sti i stedet for til den bare vært. Det, der kommer tilbage, er som regel en omdirigering til login-endpointet eller selve formularen. En klient, der kun får vpn.example.net, starter på den standardlandingsside, der nu engang er, og det kan være en anden portal, en anden gruppeliste eller en side, der forventer en helt anden protokol. Forskellen er synlig i svarheaderne længe før, der indtastes en eneste legitimationsoplysning.

Derfor kan en fungerende browserfane og en fejlende klientprofil nævne den samme gateway og stadig være uenige. Browseren fulgte stien; profilen havde den aldrig.

To input, der ser ud til at kunne byttes og ikke kan

OpenConnect eksponerer den indledende HTTPS-sti som --usergroup, og manualsiden behandler en fuld URL med den sti som den samme anmodning skrevet anderledes. --authgroup er en separat indstilling: den vælger en post fra den liste, gatewayen viser inde i loginformularen. Nogle protokoller kalder den post en gruppe, andre et domæne eller en gateway, og det er præcis der, de to flag bliver forvekslet.

En tjeneste kan legitimt have brug for begge. Stien kan lande dig på den rigtige portal, mens formularen stadig beder dig vælge blandt grupper inde i den. At angive portalnavnet som gruppenavn, eller omvendt, giver et login, der ser accepteret ud og derefter ikke autoriserer, fordi værdien var syntaktisk gyldig og semantisk forkert.

Bed operatøren om hver værdi på sin egen linje: indgangssti, formularvalg og om begge er påkrævet. Udled ikke den ene af den anden, fordi etiketterne lyder ens.

Hvorfor afkortning af stien ændrer resultatet

Klienter, der kun accepterer vært og port, opretter ofte stadig forbindelse, så symptomet er sjældent en hård fejl. I stedet får du den forkerte loginside, en tom gruppeliste, et certifikatnavn, der ikke længere matcher det, operatøren offentliggjorde, eller en tunnel, der kommer op uden en rute til den tjeneste, du ville have. Hver af dem sidder i et forskelligt lag, og ingen af dem repareres ved at indsætte en længere streng i et felt, der er dokumenteret som værtsnavn. To af dem kan heller ikke skelnes udefra, da begge ankommer som en loginformular, der simpelthen ikke fortsætter.

At erstatte værtsnavnet med en IP-adresse er en separat fejl, der ofte rejser med denne. Navnbaseret tjenestevalg og certifikatvalidering afhænger begge af navnet, så en numerisk adresse kan forvandle et stiformatproblem til en TLS-fejl.

Browseradresser bærer også mere end stier. Sessions-id'er, omdirigeringsmål, sprogpræfikser og midlertidige loginparametre dukker alle op i adresselinjen, og ingen af dem hører hjemme i en gemt klientprofil.

Bekræft indgangspunktet, før du redigerer noget andet

Læs headeren for den sti, du fik. En anmodning som curl -sS -o /dev/null -D - https://vpn.example.net/partners udskriver statuslinjen og enhver Location-header uden at følge omdirigeringen. En 302, der peger på et navngivet login-endpoint, bekræfter, at stien findes, og viser, hvor den fører hen; en 404 betyder, at operatørens adresse er forældet.

Gengiv derefter det samme indgangspunkt i den godkendte klient, for eksempel openconnect --usergroup=partners vpn.example.net, og se, hvilken formular der vises. Hvis formularen er korrekt, og tunnelen stadig fejler, var stien aldrig problemet, og næste stop er politik eller routing.

Notér værtsnavn, port, protokol, indgangssti og formularvalg som fem separate felter i sagen. Den liste er det, der lader den næste ingeniør skelne en utilgængelig server fra en TLS-afvisning, et afvist valg og en tunnel, der kom op uden de ruter, den havde brug for.