Ĉu la saluto de OpenConnect surteriĝas sur la malĝusta paĝo? Unue kontrolu la vojon
La plena VPN-adreso portas vojon, kiu elektas la ensalutan enirpunkton. Tenu ĝin aparte de la formulara grupo, kaj kontrolu la alidirektadon antaŭ ol redakti la profilon.
Vi gluas la adreson el la enkonduka retpoŝto, la kliento atingas la enirejon, kaj la ensaluta formularo, kiu aperas, estas la ĝenerala portalo, ne la partnera, kiun priskribis la administranto. Nenio raportas eraron, kaj ĝuste tio konfuzas: la tunelo eĉ povas ekfunkcii, nur malantaŭ la malĝusta enirpunkto. La vojo en tiu URL faris laboron, kaj kio ajn anstataŭigis ĝin, perdis tiun laboron.
Apartigu du aferojn, kiuj alvenas kiel unu ĉeno en bileto: la adreso, kiu atingas la servon, kaj la enigo, kiu decidas, kie komenciĝas la aŭtentikigo. Ripari la unuan ignorante la duan estas la maniero, kiel ĝusta gastigantnomo tamen produktas la malĝustan saluton.
Kion la kliento sendas antaŭ ol vi vidas formularon
Kun adreso kiel https://vpn.example.net/partners, la unua ago de la kliento estas HTTPS-peto al tiu vojo, ne al la nuda gastiganto. Tio, kio revenas, kutime estas alidirektado al la ensaluta finpunkto, aŭ la formularo mem. Kliento, kiu ricevas nur vpn.example.net, komencas ĉe kia ajn estas la defaŭlta alteriĝa paĝo, kiu povas esti alia portalo, alia gruplisto aŭ paĝo atendanta tute alian protokolon. La diferenco videblas en la respondaj kaplinioj longe antaŭ ol iu ajn legitimilo estas tajpita.
Tial funkcianta retumila langeto kaj malsukcesa klienta profilo povas nomi la saman enirejon kaj tamen malkonsenti. La retumilo sekvis la vojon; la profilo neniam havis ĝin.
Du enigoj, kiuj aspektas interŝanĝeblaj kaj ne estas
OpenConnect elmetas la komencan HTTPS-vojon kiel --usergroup, kaj la manlibra paĝo traktas plenan URL-on portantan tiun vojon kiel la saman peton skribitan alie. --authgroup estas aparta opcio: ĝi elektas eron el la listo, kiun la enirejo prezentas ene de la ensaluta formularo. Iuj protokoloj nomas tiun eron grupo, aliaj domajno aŭ enirejo, kaj ĝuste tie la du flagoj konfuziĝas.
Servo povas laŭleĝe bezoni ambaŭ. La vojo povas konduki vin al la ĝusta portalo, dum la formularo ankoraŭ petas vin elekti inter grupoj ene de ĝi. Doni la portalnomon kiel grupnomon, aŭ inverse, produktas saluton, kiu aspektas akceptita kaj poste ne rajtigas, ĉar la valoro estis sintakse valida kaj semantike malĝusta.
Petu de la administranto ĉiun valoron sur sia propra linio: enirvojo, formulara elekto, kaj ĉu ambaŭ necesas. Ne derivu unu el la alia ĉar la etikedoj sonas similaj.
Kial tondi la vojon ŝanĝas la rezulton
Klientoj, kiuj akceptas nur gastiganton kaj pordon, ofte tamen konektiĝas, do la simptomo malofte estas malmola fiasko. Anstataŭe vi ricevas la malĝustan ensalutan paĝon, malplenan grupliston, atestilan nomon, kiu ne plu kongruas kun tio, kion la administranto publikigis, aŭ tunelon, kiu ekfunkcias sen vojo al la servo, kiun vi volis. Ĉiu el tiuj sidas sur malsama tavolo, kaj neniu estas riparita per gluo de pli longa ĉeno en kampon dokumentitan kiel gastigantnomo. Du el ili ankaŭ estas nedistingeblaj de ekstere, ĉar ambaŭ alvenas kiel ensaluta formularo, kiu simple ne daŭras.
Anstataŭigi la gastigantnomon per IP-adreso estas aparta eraro, kiu ofte vojaĝas kun ĉi tiu. Nom-bazita servoelekto kaj atestila validigo ambaŭ dependas de la nomo, do numera adreso povas transformi vojformatan problemon en TLS-eraron.
Retumilaj adresoj portas ankaŭ pli ol vojojn. Sesio-identigiloj, alidirektaj celoj, lingvaj prefiksoj kaj provizoraj ensalutaj parametroj ĉiuj aperas en la adresbreto, kaj neniu el ili apartenas al konservita klienta profilo.
Konfirmu la enirpunkton antaŭ ol redakti ion ajn alian
Legu la kapliniojn por la vojo, kiun vi ricevis. Peto kiel curl -sS -o /dev/null -D - https://vpn.example.net/partners presas la statuslinion kaj ajnan Location-kaplinian sen sekvi la alidirektadon. 302 indikanta nomitan ensalutan finpunkton konfirmas, ke la vojo ekzistas, kaj montras, kien ĝi iras; 404 signifas, ke la adreso de la administranto estas malnova.
Poste reproduktu la saman enirpunkton en la aprobita kliento, ekzemple openconnect --usergroup=partners vpn.example.net, kaj observu, kiu formularo aperas. Se la formularo estas ĝusta kaj la tunelo ankoraŭ fiaskas, la vojo neniam estis la problemo, kaj la sekva halto estas politiko aŭ enkursigado.
Registru gastigantnomon, pordon, protokolon, enirvojon kaj formularan elekton kiel kvin apartajn kampojn en la bileto. Tiu listo estas tio, kio ebligas al la sekva inĝeniero distingi neatingeblan servilon de TLS-rifuzo, rifuzita elekto kaj tunelo, kiu ekfunkciis sen la bezonataj vojoj.