OpenConnect-aanmelding beland op die verkeerde bladsy? Kontroleer eers die pad
Die volledige VPN-URL dra ’n pad wat die aanmeldpunt kies. Hou dit apart van die vormgroep en kontroleer die herleiding voordat jy die profiel wysig.
Jy plak die adres uit die verwelkomings-e-pos, die kliënt bereik die poort, en die aanmeldvorm wat verskyn is die algemene portaal eerder as die vennootportaal wat die operateur beskryf het. Niks gee ’n fout nie, en dit is juis wat dit verwarrend maak: die tonnel kan selfs opkom, net agter die verkeerde toegangspunt. Die pad in daardie URL het werk gedoen, en wat dit ook al vervang het, het die werk laat val.
Skei twee dinge wat as een string in ’n kaartjie aankom: die adres wat die diens bereik, en die invoer wat besluit waar verifikasie begin. Om die eerste reg te maak en die tweede te ignoreer, is hoe ’n korrekte gasheernaam steeds die verkeerde aanmelding lewer.
Wat die kliënt stuur voordat jy ’n vorm sien
Met ’n adres soos https://vpn.example.net/partners is die kliënt se eerste daad ’n HTTPS-versoek na daardie pad eerder as na die kaal gasheer. Wat terugkom, is gewoonlik ’n herleiding na die aanmeldpunt, of die vorm self. ’n Kliënt wat net vpn.example.net kry, begin by wat die verstek-landingsbladsy ook al is, wat ’n ander portaal, ’n ander groeplijst of ’n bladsy kan wees wat ’n heel ander protokol verwag. Die verskil is lank voordat enige geloofsbrief getik word in die antwoordkoppe sigbaar.
Dit is waarom ’n werkende blaaier-oortjie en ’n falende kliëntprofiel dieselfde poort kan noem en steeds verskil. Die blaaier het die pad gevolg; die profiel het dit nooit gehad nie.
Twee invoere wat uitruilbaar lyk en dit nie is nie
OpenConnect stel die aanvanklike HTTPS-pad beskikbaar as --usergroup, en die handleiding behandel ’n volledige URL met daardie pad as dieselfde versoek, anders geskryf. --authgroup is ’n aparte opsie: dit kies ’n inskrywing uit die lys wat die poort binne die aanmeldvorm aanbied. Sommige protokolle noem daardie inskrywing ’n groep, ander ’n domein of ’n poort, en dit is presies waar die twee vlae verwar word.
’n Diens kan wettig albei nodig hê. Die pad kan jou na die regte portaal bring terwyl die vorm jou steeds vra om tussen groepe daarbinne te kies. Om die portaalnaam as die groepnaam te gee, of omgekeerd, lewer ’n aanmelding wat aanvaar lyk en dan nie magtig nie, omdat die waarde sintakties geldig en semantics verkeerd was.
Vra die operateur vir elke waarde op sy eie reël: toegangspad, vormkeuse, en of albei nodig is. Moenie een van die ander aflei omdat die etikette soortgelyk klink nie.
Waarom die pad inkort die uitkoms verander
Kliënte wat net ’n gasheer en poort aanvaar, sal dikwels steeds konnekteer, so die simptoom is selde ’n harde fout. In plaas daarvan kry jy die verkeerde aanmeldbladsy, ’n leë groeplijst, ’n sertifikaatnaam wat nie meer ooreenstem met wat die operateur gepubliseer het nie, of ’n tonnel wat opkom sonder ’n roete na die diens wat jy wou hê. Elkeen daarvan sit op ’n ander laag, en nie een word herstel deur ’n langer string in ’n veld te plak wat as gasheernaam gedokumenteer is nie. Twee daarvan is ook van buite nie onderskeibaar nie, want albei kom as ’n aanmeldvorm wat eenvoudig nie voortgaan nie.
Om die gasheernaam met ’n IP-adres te vervang is ’n aparte fout wat dikwels saam met hierdie een reis. Naamgebaseerde dienskeuse en sertifikaatvalidering hang albei van die naam af, so ’n numeriese adres kan ’n padformaat-probleem in ’n TLS-fout omskep.
Blaaier-adresse dra ook meer as net paaie. Sessie-identifiseerders, herleidingsteikens, taalvoorvoegsels en tydelike aanmeldparameters verskyn almal in die adresbalk, en nie een daarvan hoort in ’n gestoorde kliëntprofiel nie.
Bevestig die toegangspunt voordat jy enigiets anders wysig
Lees die koppe vir die pad wat jy gekry het. ’n Versoek soos curl -sS -o /dev/null -D - https://vpn.example.net/partners druk die statuslyn en enige Location-kop sonder om die herleiding te volg. ’n 302 wat na ’n benoemde aanmeldpunt wys, bevestig dat die pad bestaan en wys waar dit heen gaan; ’n 404 beteken die operateur se adres is verouderd.
Reproduseer dan dieselfde toegangspunt in die goedgekeurde kliënt, byvoorbeeld openconnect --usergroup=partners vpn.example.net, en kyk watter vorm verskyn. As die vorm korrek is en die tonnel steeds faal, was die pad nooit die probleem nie en is die volgende stop beleid of roetering.
Teken gasheernaam, poort, protokol, toegangspad en vormkeuse as vyf aparte velde in die kaartjie aan. Daardie lys is wat die volgende ingenieur in staat stel om ’n onbereikbare bediener te onderskei van ’n TLS-weiering, ’n geweierde keuse, en ’n tonnel wat opgekom het sonder die roetes wat dit nodig gehad het.