OpenConnect-oanmelding belânet op de ferkearde side? Kontrolearje earst it paad
De folsleine VPN-URL draacht in paad dat it oanmeldpunt kiest. Hâld it los fan de formuliergroep en kontrolearje de trochferwizing foardat jo it profyl bewurkje.
Jo plakke it adres út de onboardingsmail, de klient berikt de poarte, en it oanmeldformulier dat ferskynt is it algemiene portaal en net it partnerportaal dat de operator beskreau. Neat jout in flater, en dat is krekt wat it betiizjend makket: de tunnel kin sels omheech komme, mar efter it ferkearde oanmeldpunt. It paad yn dy URL die wurk, en wat it ek ferfong, liet dat wurk falle.
Skied twa dingen dy’t as ien string yn in ticket oankomme: it adres dat de tsjinst berikt, en de ynfier dy’t bepaalt wêr’t de autentikaasje begjint. It earste reparearje en it twadde negearje is hoe’t in korrekte hostnamme dochs de ferkearde oanmelding jout.
Wat de klient stjoert foardat jo in formulier sjogge
Mei in adres lykas https://vpn.example.net/partners is de earste die fan de klient in HTTPS-fersyk nei dat paad ynstee fan nei de bleate host. Wat weromkomt is meastentiids in trochferwizing nei it oanmeldpunt, of it formulier sels. In klient dy’t allinnich vpn.example.net krijt, begjint by hokker standert lâningsside dan ek, en dat kin in oar portaal, in oare groeplist of in side wêze dy’t in hiel oar protokol ferwachtet. It ferskil is yn de antwurdkoppen te sjen lang foardat der ek mar ien oanmeldgegevens yntypen wurdt.
Dêrom kinne in wurkjend browser-tab en in mislearjend klientprofyl deselde poarte neame en dochs net oerienkomme. De browser folge it paad; it profyl hie it nea.
Twa ynfierden dy’t útwikselber lykje en it net binne
OpenConnect eksposearret it begjinpaad fan HTTPS as --usergroup, en de hânliedingside behannelet in folsleine URL mei dat paad as itselde fersyk, oars skreaun. --authgroup is in aparte opsje: it kiest in ynskriuwing út de list dy’t de poarte binnen it oanmeldformulier toant. Guon protokollen neame dy ynskriuwing in groep, oaren in domein of in poarte, en krekt dêr wurde de twa flaggen betiizje.
In tsjinst kin wetlik beide nedich wêze. It paad kin jo op it goede portaal bringe wylst it formulier jo noch freget om binnen dat portaal in groep te kiezen. De portaalnamme as groepsnamme jaan, of oarsom, jout in oanmelding dy’t akseptearre liket en dan net autorisearret, omdat de wearde syntaktysk jildich en semantysk ferkeard wie.
Freegje de operator om elke wearde op syn eigen rigel: yngongspaad, formulierkar en oft beide nedich binne. Lied it iene net fan it oare ôf omdat de labels gelyk klinke.
Wêrom’t it koartsjen fan it paad de útkomst feroaret
Klienten dy’t allinnich host en poarte akseptearje, ferbine har faak dochs, sadat it symptoom selden in hurde flater is. Ynstee krije jo de ferkearde oanmeldside, in lege groeplist, in sertifikaatnamme dy’t net mear oerienkomt mei wat de operator publisearre hat, of in tunnel dy’t omheech komt sûnder rûte nei de tsjinst dy’t jo woene. Elk dêrfan sit op in oare laach, en net ien wurdt reparearre troch in langer string yn in fjild te plakken dat as hostnamme dokumintearre is. Twa derfan binne ek fan bûten net te ûnderskieden, want beide komme as in oanmeldformulier dat gewoan net trochgiet.
It ferfangen fan de hostnamme troch in IP-adres is in aparte flater dy’t faak mei dizze reizget. Namme-basearre tsjinstkar en sertifikaatfalidaasje hingje beide fan de namme ôf, sadat in numeriek adres in paadformaatsprobleem yn in TLS-flater feroarje kin.
Browseradressen drage ek mear as paden. Sessy-ID’s, trochferwizingsdoelen, taalprefiksen en tydlike oanmeldparameters ferskine allegear yn de adresbalke, en net ien derfan heart yn in bewarre klientprofyl.
Befêstigje it oanmeldpunt foardat jo eat oars bewurkje
Lês de koppen foar it paad dat jo krigen hawwe. In fersyk lykas curl -sS -o /dev/null -D - https://vpn.example.net/partners prints de statusrigel en elke Location-kop sûnder de trochferwizing te folgjen. In 302 dy’t nei in neamd oanmeldpunt wiist, befêstiget dat it paad bestiet en lit sjen wêr’t it hinne giet; in 404 betsjut dat it adres fan de operator ferâldere is.
Reprodusearje dan itselde oanmeldpunt yn de goedkarde klient, bygelyks openconnect --usergroup=partners vpn.example.net, en sjoch hokker formulier ferskynt. As it formulier korrekt is en de tunnel dochs mislearret, wie it paad nea it probleem en is de folgjende stop belied of rûteleas.
Skriuw hostnamme, poarte, protokol, yngongspaad en formulierkar as fiif aparte fjilden yn it ticket. Dy list is wat de folgjende yngenieur by steat stelt om in net berikbere server te ûnderskieden fan in TLS-ôfwizing, in wegere kar en in tunnel dy’t omheech kaam sûnder de rûtes dy’t er nedich hie.