OpenConnect-innlogging ender på feil side? Sjekk stien først

Du limer inn adressen fra onboarding-e-posten, klienten når gatewayen, og innloggingsskjemaet som vises, er den generelle portalen og ikke partnerportalen operatøren beskrev. Ingenting gir feil, og nettopp det er forvirrende: tunnelen kan til og med komme opp, bare bak feil inngangspunkt. Stien i den URL-en gjorde arbeid, og hva som enn erstattet den, mistet det arbeidet.

Skill to ting som kommer som én streng i en sak: adressen som når tjenesten, og inndataen som avgjør hvor autentiseringen begynner. Å reparere det første mens det andre ignoreres, er måten et korrekt vertsnavn likevel gir feil innlogging.

Hva klienten sender før du ser et skjema

Med en adresse som https://vpn.example.net/partners er klientens første handling en HTTPS-forespørsel til den stien i stedet for til den bare verten. Det som kommer tilbake, er vanligvis en omdirigering til innloggingsendepunktet, eller skjemaet selv. En klient som bare får vpn.example.net, starter på den standardlandingssiden som finnes, og det kan være en annen portal, en annen gruppeliste eller en side som forventer en helt annen protokoll. Forskjellen er synlig i svarhodene lenge før noen legitimasjon skrives inn.

Derfor kan en fungerende nettleserfane og en feilende klientprofil nevne samme gateway og likevel være uenige. Nettleseren fulgte stien; profilen hadde den aldri.

To inndata som ser ut som de kan byttes og ikke kan det

OpenConnect eksponerer den innledende HTTPS-stien som --usergroup, og håndbokssiden behandler en full URL med den stien som samme forespørsel skrevet annerledes. --authgroup er et eget alternativ: det velger en oppføring fra listen gatewayen viser inne i innloggingsskjemaet. Noen protokoller kaller den oppføringen en gruppe, andre et domene eller en gateway, og det er nettopp der de to flaggene blandes.

En tjeneste kan legitimt trenge begge. Stien kan lande deg på riktig portal mens skjemaet fortsatt ber deg velge blant grupper inne i den. Å oppgi portalnavnet som gruppenavn, eller omvendt, gir en innlogging som ser akseptert ut og deretter ikke autoriserer, fordi verdien var syntaktisk gyldig og semantisk feil.

Be operatøren om hver verdi på sin egen linje: inngangssti, skjemavalg og om begge er nødvendige. Ikke utled den ene av den andre fordi etikettene høres like ut.

Hvorfor avkorting av stien endrer resultatet

Klienter som bare godtar vert og port, kobler ofte likevel til, så symptomet er sjelden en hard feil. I stedet får du feil innloggingsside, en tom gruppeliste, et sertifikatnavn som ikke lenger samsvarer med det operatøren publiserte, eller en tunnel som kommer opp uten rute til tjenesten du ville ha. Hver av disse sitter i et forskjellig lag, og ingen av dem repareres ved å lime en lengre streng inn i et felt som er dokumentert som vertsnavn. To av dem kan heller ikke skilles utenfra, siden begge kommer som et innloggingsskjema som rett og slett ikke fortsetter.

Å erstatte vertsnavnet med en IP-adresse er en egen feil som ofte reiser sammen med denne. Navnbasert tjenestevalg og sertifikatvalidering avhenger begge av navnet, så en numerisk adresse kan gjøre et stiformatproblem om til en TLS-feil.

Nettleseradresser bærer også mer enn stier. Sesjonsidentifikatorer, omdirigeringsmål, språkprefikser og midlertidige innloggingsparametere dukker alle opp i adresselinjen, og ingen av dem hører hjemme i en lagret klientprofil.

Bekreft inngangspunktet før du redigerer noe annet

Les hodene for stien du fikk. En forespørsel som curl -sS -o /dev/null -D - https://vpn.example.net/partners skriver ut statuslinjen og enhver Location-header uten å følge omdirigeringen. En 302 som peker på et navngitt innloggingsendepunkt, bekrefter at stien finnes og viser hvor den fører; en 404 betyr at operatørens adresse er utdatert.

Gjenskap deretter samme inngangspunkt i den godkjente klienten, for eksempel openconnect --usergroup=partners vpn.example.net, og se hvilket skjema som vises. Hvis skjemaet er riktig og tunnelen fortsatt feiler, var stien aldri problemet, og neste stopp er policy eller ruting.

Noter vertsnavn, port, protokoll, inngangssti og skjemavalg som fem separate felt i saken. Den listen er det som lar den neste ingeniøren skille en utilgjengelig server fra en TLS-avvisning, et avvist valg og en tunnel som kom opp uten rutene den trengte.