OpenConnect-login belandt op de verkeerde pagina? Controleer eerst het pad

Je plakt het adres uit de onboardingmail, de client bereikt de gateway en het inlogformulier dat verschijnt is het algemene portaal in plaats van het partnerportaal dat de operator beschreef. Niets geeft een fout, en dat is juist verwarrend: de tunnel kan zelfs omhoogkomen, alleen achter het verkeerde toegangspunt. Het pad in die URL deed werk, en wat het ook verving, liet dat werk vallen.

Scheid twee dingen die als één string in een ticket aankomen: het adres dat de dienst bereikt, en de invoer die bepaalt waar de authenticatie begint. Het eerste repareren terwijl je het tweede negeert, is hoe een correcte hostnaam toch de verkeerde login oplevert.

Wat de client stuurt voordat je een formulier ziet

Met een adres als https://vpn.example.net/partners is de eerste handeling van de client een HTTPS-verzoek naar dat pad in plaats van naar de kale host. Wat terugkomt is meestal een omleiding naar het inlogpunt, of het formulier zelf. Een client die alleen vpn.example.net krijgt, begint bij de standaardlandingspagina die er is, en dat kan een ander portaal, een andere groepenlijst of een pagina zijn die een heel ander protocol verwacht. Het verschil is in de responsheaders zichtbaar lang voordat er een inloggegeven wordt getypt.

Daarom kunnen een werkend browsertabblad en een falend clientprofiel dezelfde gateway noemen en het toch oneens zijn. De browser volgde het pad; het profiel had het nooit.

Twee invoerwaarden die uitwisselbaar lijken en het niet zijn

OpenConnect stelt het initiële HTTPS-pad beschikbaar als --usergroup, en de handleidingspagina behandelt een volledige URL met dat pad als hetzelfde verzoek, anders geschreven. --authgroup is een aparte optie: die kiest een item uit de lijst die de gateway binnen het inlogformulier toont. Sommige protocollen noemen dat item een groep, andere een domein of een gateway, en precies daar raken de twee vlaggen verward.

Een dienst kan legitiem beide nodig hebben. Het pad kan je op het juiste portaal brengen terwijl het formulier nog vraagt om binnen dat portaal een groep te kiezen. De portaalnaam als groepsnaam opgeven, of andersom, levert een login op die geaccepteerd lijkt en daarna niet autoriseert, omdat de waarde syntactisch geldig en semantisch onjuist was.

Vraag de operator om elke waarde op een eigen regel: toegangspad, formulierkeuze en of beide nodig zijn. Leid het ene niet van het andere af omdat de labels hetzelfde klinken.

Waarom het inkorten van het pad de uitkomst verandert

Clients die alleen host en poort accepteren, verbinden vaak toch, dus het symptoom is zelden een harde fout. In plaats daarvan krijg je de verkeerde inlogpagina, een lege groepenlijst, een certificaatnaam die niet meer overeenkomt met wat de operator publiceerde, of een tunnel die omhoogkomt zonder route naar de dienst die je wilde. Elk daarvan zit in een andere laag, en geen ervan wordt gerepareerd door een langere string in een veld te plakken dat als hostnaam is gedocumenteerd. Twee ervan zijn van buitenaf ook niet te onderscheiden, omdat beide aankomen als een inlogformulier dat simpelweg niet doorgaat.

De hostnaam vervangen door een IP-adres is een aparte fout die vaak met deze meereist. Naamgebaseerde dienstkeuze en certificaatvalidatie hangen beide van de naam af, dus een numeriek adres kan een padformaatprobleem omzetten in een TLS-fout.

Browseradressen bevatten ook meer dan paden. Sessie-identificatoren, omleidingsdoelen, taalprefixen en tijdelijke inlogparameters verschijnen allemaal in de adresbalk, en geen ervan hoort in een opgeslagen clientprofiel.

Bevestig het toegangspunt voordat je iets anders bewerkt

Lees de headers voor het pad dat je hebt gekregen. Een verzoek als curl -sS -o /dev/null -D - https://vpn.example.net/partners drukt de statusregel en elke Location-header af zonder de omleiding te volgen. Een 302 die naar een genoemd inlogpunt wijst, bevestigt dat het pad bestaat en laat zien waar het heen gaat; een 404 betekent dat het adres van de operator verouderd is.

Reproduceer daarna hetzelfde toegangspunt in de goedgekeurde client, bijvoorbeeld openconnect --usergroup=partners vpn.example.net, en kijk welk formulier verschijnt. Als het formulier correct is en de tunnel nog steeds faalt, was het pad nooit het probleem en is de volgende stop beleid of routering.

Noteer hostnaam, poort, protocol, toegangspad en formulierkeuze als vijf afzonderlijke velden in het ticket. Die lijst is wat de volgende engineer in staat stelt een onbereikbare server te onderscheiden van een TLS-weigering, een geweigerde keuze en een tunnel die omhoogkwam zonder de routes die hij nodig had.