Ang pag-log in sa OpenConnect ay napupunta sa maling pahina? Suriin muna ang landas

I-paste mo ang address mula sa onboarding email, naaabot ng client ang gateway, at ang form ng pag-log in na lumalabas ay ang pangkalahatang portal, hindi ang portal ng partner na inilarawan ng operator. Walang nagpapakita ng error, at iyon mismo ang nakakalito: maaaring tumaas pa ang tunnel, pero sa likod ng maling pasukan. May ginagawang trabaho ang landas sa URL na iyon, at anuman ang pumalit dito ay binitawan ang trabahong iyon.

Ihiwalay ang dalawang bagay na dumarating bilang isang string sa isang ticket: ang address na umaabot sa serbisyo, at ang input na nagpapasya kung saan nagsisimula ang pagpapatunay. Ang ayusin ang una habang binabalewala ang pangalawa ay ang paraan kung paano ang tamang hostname ay nagbubunga pa rin ng maling pag-log in.

Ano ang ipinapadala ng client bago ka makakita ng form

Sa address na tulad ng https://vpn.example.net/partners, ang unang aksyon ng client ay isang HTTPS request sa landas na iyon, hindi sa hubad na host. Ang bumabalik ay karaniwang redirect sa pasukan ng pag-log in, o ang form mismo. Ang client na binigyan lamang ng vpn.example.net ay nagsisimula sa anumang default na landing page, at maaaring ibang portal iyon, ibang listahan ng grupo, o pahinang umaasa sa ganap na ibang protocol. Ang pagkakaiba ay makikita sa mga header ng tugon bago pa man may maipasok na kredensyal.

Kaya't ang gumaganang tab ng browser at ang nabibigong profile ng client ay maaaring magpangalan ng parehong gateway at hindi pa rin magkasundo. Sinundan ng browser ang landas; hindi ito kailanman nagkaroon ang profile.

Dalawang input na mukhang mapagpapalit at hindi naman

Inilalantad ng OpenConnect ang paunang HTTPS na landas bilang --usergroup, at itinuturing ng pahina ng manwal ang buong URL na may dalang landas na iyon bilang parehong request na nakasulat nang iba. Ang --authgroup ay hiwalay na opsyon: pumipili ito ng entry mula sa listahan na ipinapakita ng gateway sa loob ng form ng pag-log in. Tinatawag ng ilang protocol ang entry na iyon na grupo, ng iba ay domain o gateway, at doon mismo nagkakalito ang dalawang flag.

Maaaring lehitimong kailanganin ng serbisyo ang dalawa. Maaaring dalhin ka ng landas sa tamang portal habang hinihiling pa rin ng form na pumili ka sa mga grupo sa loob nito. Ang ibigay ang pangalan ng portal bilang pangalan ng grupo, o kabaliktaran, ay gumagawa ng pag-log in na mukhang tinanggap at pagkatapos ay hindi nagpapahintulot, dahil ang halaga ay wasto sa sintaks at mali sa kahulugan.

Hilingin sa operator ang bawat halaga sa sarili nitong linya: landas ng pasukan, pagpili sa form, at kung kailangan ang dalawa. Huwag maghinuha ng isa mula sa isa pa dahil lang magkatunog ang mga label.

Bakit binabago ng pagputol ng landas ang resulta

Ang mga client na tumatanggap lamang ng host at port ay madalas na kumokonekta pa rin, kaya bihirang maging matigas na pagkabigo ang sintomas. Sa halip, nakakakuha ka ng maling pahina ng pag-log in, walang laman na listahan ng grupo, pangalan ng sertipiko na hindi na tumutugma sa inilathala ng operator, o tunnel na tumataas nang walang ruta patungo sa serbisyong gusto mo. Ang bawat isa sa mga ito ay nasa ibang antas, at wala sa kanila ang naaayos sa pamamagitan ng pag-paste ng mas mahabang string sa field na nakadokumento bilang hostname. Dalawa sa kanila ay hindi rin makilala mula sa labas, dahil parehong dumarating bilang form ng pag-log in na simpleng hindi nagpapatuloy.

Ang palitan ang hostname ng IP address ay hiwalay na pagkakamali na madalas sumama dito. Ang pagpili ng serbisyo batay sa pangalan at ang pagpapatunay ng sertipiko ay parehong nakadepende sa pangalan, kaya ang numerong address ay maaaring gawing TLS error ang problema sa format ng landas.

Ang mga address ng browser ay may dalang higit pa sa mga landas. Ang mga identifier ng session, target ng redirect, prefix ng wika at pansamantalang parameter ng pag-log in ay lumalabas lahat sa address bar, at wala sa mga ito ang nababagay sa naka-save na profile ng client.

Kumpirmahin ang pasukan bago i-edit ang anupaman

Basahin ang mga header para sa landas na ibinigay sa iyo. Ang request na tulad ng curl -sS -o /dev/null -D - https://vpn.example.net/partners ay nagpi-print ng status line at anumang Location header nang hindi sinusundan ang redirect. Ang 302 na tumuturo sa pinangalanang pasukan ng pag-log in ay nagpapatunay na umiiral ang landas at nagpapakita kung saan ito patungo; ang 404 ay nangangahulugang luma na ang address ng operator.

Pagkatapos ay muling likhain ang parehong pasukan sa aprubadong client, halimbawa openconnect --usergroup=partners vpn.example.net, at panoorin kung aling form ang lumalabas. Kung tama ang form at nabibigo pa rin ang tunnel, hindi kailanman naging problema ang landas at ang susunod na hinto ay patakaran o routing.

Itala ang hostname, port, protocol, landas ng pasukan at pagpili sa form bilang limang magkakahiwalay na field sa ticket. Ang listahang iyon ang nagpapahintulot sa susunod na inhinyero na makilala ang hindi maabot na server mula sa pagtanggi ng TLS, tinanggihang pagpili, at tunnel na tumaas nang walang mga rutang kailangan nito.