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

Du limer inn adressa frå onboarding-e-posten, klienten når gatewayen, og innloggingsskjemaet som kjem fram, er den generelle portalen og ikkje partnarportalen operatøren skildra. Ingenting gjev feil, og nettopp det er forvirrande: tunnelen kan til og med kome opp, berre bak feil inngangspunkt. Stien i den URL-en gjorde arbeid, og kva som enn erstatta han, mista det arbeidet.

Skil to ting som kjem som ein streng i ei sak: adressa som når tenesta, og inndataen som avgjer kvar autentiseringa byrjar. Å reparere det første medan det andre vert ignorert, er måten eit korrekt vertsnamn likevel gjev feil innlogging.

Kva klienten sender før du ser eit skjema

Med ei adresse som https://vpn.example.net/partners er den første handlinga til klienten ein HTTPS-førespurnad til den stien i staden for til den berre verten. Det som kjem tilbake, er vanlegvis ei omdirigering til innloggingsendepunktet, eller skjemaet sjølv. Ein klient som berre får vpn.example.net, byrjar på den standardlandingssida som finst, og det kan vere ein annan portal, ei anna gruppeliste eller ei side som ventar ein heilt annan protokoll. Skilnaden er synleg i svarhovuda lenge før nokon legitimasjon vert skriven inn.

Difor kan ei fungerande nettlesarfane og ein feilande klientprofil nemne same gateway og likevel vere usamde. Nettlesaren følgde stien; profilen hadde han aldri.

To inndata som ser ut som dei kan bytast og ikkje kan det

OpenConnect eksponerer den innleiande HTTPS-stien som --usergroup, og handboksida behandlar ein full URL med den stien som same førespurnad skriven annleis. --authgroup er eit eige alternativ: det vel ein oppføring frå lista gatewayen viser inne i innloggingsskjemaet. Nokre protokollar kallar den oppføringa ei gruppe, andre eit domene eller ein gateway, og det er nettopp der dei to flagga vert blanda.

Ei teneste kan legitimt trenge båe. Stien kan lande deg på rett portal medan skjemaet framleis ber deg velje mellom grupper inne i han. Å oppgje portalnamnet som gruppenamn, eller omvendt, gjev ei innlogging som ser godteken ut og deretter ikkje autoriserer, fordi verdien var syntaktisk gyldig og semantisk feil.

Be operatøren om kvar verdi på si eiga line: inngangssti, skjemavalg og om båe er naudsynte. Ikkje lei den eine ut av den andre fordi etikettene høyrest like ut.

Kvifor avkorting av stien endrar resultatet

Klientar som berre godtek vert og port, koplar ofte likevel til, så symptomet er sjeldan ein hard feil. I staden får du feil innloggingsside, ei tom gruppeliste, eit sertifikatnamn som ikkje lenger samsvarar med det operatøren publiserte, eller ein tunnel som kjem opp utan rute til tenesta du ville ha. Kvar av desse sit i eit anna lag, og ingen av dei vert reparerte ved å lime ein lengre streng inn i eit felt som er dokumentert som vertsnamn. To av dei kan heller ikkje skiljast utanfrå, sidan båe kjem som eit innloggingsskjema som rett og slett ikkje held fram.

Å erstatte vertsnamnet med ei IP-adresse er ein eigen feil som ofte reiser saman med denne. Namnbasert tenesteval og sertifikatvalidering avheng båe av namnet, så ei numerisk adresse kan gjere eit stiformatproblem om til ein TLS-feil.

Nettlesaradresser ber òg meir enn stiar. Sesjonsidentifikatorar, omdirigeringsmål, språkprefiks og mellombelse innloggingsparameterar dukkar alle opp i adresselina, og ingen av dei høyrer heime i ein lagra klientprofil.

Stadfest inngangspunktet før du redigerer noko anna

Les hovuda for stien du fekk. Ein førespurnad som curl -sS -o /dev/null -D - https://vpn.example.net/partners skriv ut statuslina og eit kva Location-hovud som helst utan å følgje omdirigeringa. Ein 302 som peikar på eit namngjeve innloggingsendepunkt, stadfestar at stien finst og viser kvar han fører; ein 404 tyder at adressa til operatøren er utdatert.

Gjenskap deretter same inngangspunkt i den godkjende klienten, til dømes openconnect --usergroup=partners vpn.example.net, og sjå kva skjema som kjem fram. Viss skjemaet er rett og tunnelen framleis feilar, var stien aldri problemet, og neste stopp er policy eller ruting.

Noter vertsnamn, port, protokoll, inngangssti og skjemavalg som fem skilde felt i saka. Den lista er det som lèt den neste ingeniøren skilje ein utilgjengeleg tenar frå ei TLS-avvising, eit avvist val og ein tunnel som kom opp utan rutene han trong.