OpenConnect-kirjautuminen päätyy väärälle sivulle? Tarkista ensin polku

Liität osoitteen käyttöönottoviestistä, asiakasohjelma saavuttaa yhdyskäytävän, ja ilmestyvä kirjautumislomake on yleinen portaali eikä operaattorin kuvaama kumppaniportaali. Mikään ei ilmoita virheestä, ja juuri se hämmentää: tunneli voi jopa nousta, vain väärän aloituspisteen takana. Sen URL:n polku teki työtä, ja mikä sen korvasikin, pudotti sen työn.

Erota kaksi asiaa, jotka saapuvat tikettiin yhtenä merkkijonona: osoite, joka saavuttaa palvelun, ja syöte, joka päättää, mistä todennus alkaa. Ensimmäisen korjaaminen toisen huomiotta jättäen on tapa, jolla oikea isäntänimi tuottaa silti väärän kirjautumisen.

Mitä asiakasohjelma lähettää ennen kuin näet lomakkeen

Osoitteella kuten https://vpn.example.net/partners asiakasohjelman ensimmäinen teko on HTTPS-pyyntö tuohon polkuun eikä paljaaseen isäntään. Takaisin tulee yleensä uudelleenohjaus kirjautumisen päätepisteeseen tai itse lomake. Asiakasohjelma, jolle annetaan vain vpn.example.net, aloittaa siitä oletusaloitussivusta, mikä sattuu olemaan, ja se voi olla toinen portaali, toinen ryhmäluettelo tai sivu, joka odottaa täysin toista protokollaa. Ero näkyy vastauksen otsakkeissa kauan ennen kuin mitään tunnistetietoa kirjoitetaan.

Siksi toimiva selaimen välilehti ja epäonnistuva asiakasprofiili voivat nimetä saman yhdyskäytävän ja silti olla eri mieltä. Selain seurasi polkua; profiililla sitä ei koskaan ollut.

Kaksi syötettä, jotka näyttävät vaihdettavilta eivätkä ole

OpenConnect paljastaa alkuperäisen HTTPS-polun muodossa --usergroup, ja käsikirjan sivu käsittelee kyseisen polun sisältävää täyttä URL:ää samana pyyntönä toisin kirjoitettuna. --authgroup on erillinen valinta: se valitsee merkinnän luettelosta, jonka yhdyskäytävä esittää kirjautumislomakkeen sisällä. Jotkin protokollat kutsuvat tätä merkintää ryhmäksi, toiset verkkotunnukseksi tai yhdyskäytäväksi, ja juuri siinä kaksi valitsinta menevät sekaisin.

Palvelu voi laillisesti tarvita molempia. Polku voi viedä sinut oikeaan portaaliin, kun taas lomake pyytää edelleen valitsemaan sen sisällä olevista ryhmistä. Portaalin nimen antaminen ryhmän nimenä tai päinvastoin tuottaa kirjautumisen, joka näyttää hyväksytyltä ja sitten ei valtuuta, koska arvo oli syntaktisesti kelvollinen ja semanttisesti väärä.

Pyydä operaattorilta jokainen arvo omalla rivillään: aloituspolku, lomakevalinta ja tarvitaanko molempia. Älä johda toista toisesta siksi, että nimikkeet kuulostavat samalta.

Miksi polun lyhentäminen muuttaa lopputulosta

Asiakasohjelmat, jotka hyväksyvät vain isännän ja portin, yhdistävät usein silti, joten oire on harvoin kova virhe. Sen sijaan saat väärän kirjautumissivun, tyhjän ryhmäluettelon, varmenteen nimen, joka ei enää vastaa operaattorin julkaisemaa, tai tunnelin, joka nousee ilman reittiä haluamaasi palveluun. Jokainen näistä istuu eri kerroksessa, eikä mitään niistä korjata liittämällä pidempää merkkijonoa kenttään, joka on dokumentoitu isäntänimeksi. Kaksi niistä on myös ulkopuolelta erottamattomia, koska molemmat saapuvat kirjautumislomakkeena, joka yksinkertaisesti ei jatku.

Isäntänimen korvaaminen IP-osoitteella on erillinen virhe, joka usein kulkee tämän mukana. Nimeen perustuva palvelunvalinta ja varmenteen validointi riippuvat molemmat nimestä, joten numeerinen osoite voi muuttaa polkumuodon ongelman TLS-virheeksi.

Selaimen osoitteet sisältävät muutakin kuin polkuja. Istunnon tunnisteet, uudelleenohjauksen kohteet, kielietuliitteet ja tilapäiset kirjautumisparametrit näkyvät kaikki osoitepalkissa, eikä mikään niistä kuulu tallennettuun asiakasprofiiliin.

Vahvista aloituspiste ennen kuin muokkaat mitään muuta

Lue saamasi polun otsakkeet. Pyyntö kuten curl -sS -o /dev/null -D - https://vpn.example.net/partners tulostaa tilanrivin ja mahdollisen Location-otsakkeen seuraamatta uudelleenohjausta. Nimettyyn kirjautumisen päätepisteeseen osoittava 302 vahvistaa, että polku on olemassa, ja näyttää, minne se johtaa; 404 tarkoittaa, että operaattorin osoite on vanhentunut.

Toista sitten sama aloituspiste hyväksytyssä asiakasohjelmassa, esimerkiksi openconnect --usergroup=partners vpn.example.net, ja katso, mikä lomake ilmestyy. Jos lomake on oikea ja tunneli epäonnistuu silti, polku ei ollut koskaan ongelma ja seuraava pysäkki on käytäntö tai reititys.

Kirjaa isäntänimi, portti, protokolla, aloituspolku ja lomakevalinta viitenä erillisenä kenttänä tikettiin. Juuri se luettelo antaa seuraavalle insinöörille mahdollisuuden erottaa tavoittamaton palvelin TLS-hylkäyksestä, hylätystä valinnasta ja tunnelista, joka nousi ilman tarvittavia reittejä.