Kur OpenVPN prisijungime atsiduria statinio iššūkio kodas

Klientas rodo antrą laukelį po slaptažodžio lauko, jūs įrašote kodą iš aparatinio rakto, o prisijungimas vis tiek nepavyksta su autentifikavimo klaida. Tas laukelis egzistuoja, vadinasi, profilis jo paprašė. Ar serveris kada nors gavo reikšmę tokia forma, kurią supranta, yra kitas klausimas, ir būtent į jį verta atsakyti pirmiausia.

Pradėkite nuo raginimo, kurį jūsų klientas iš tikrųjų rodo

Profilyje gali būti statinio iššūkio direktyva su raginimo eilute ir vėliavėle, kuri valdo, ar atsakymas rodomas rašant. Raginimas yra tai, ką matote dialoge; vėliavėlė yra tos pačios įvesties rodymo nuostata. Nė vienas iš jų nepasako serveriui, kaip ką nors tikrinti.

Suskaičiuokite laukus, kurių iš tikrųjų gavote. Vienas laukas vartotojo vardui ir vienas užmaskuotas laukas yra įprastas prisijungimas slaptažodžiu visai be iššūkio. Antras laukas, pasirodantis po slaptažodžio su savo etikete, yra klientas, įgyvendinantis iššūkio sąveiką.

Jei antras laukelis niekada nepasirodo jūsų naudojamame kliente, tas klientas gali neįgyvendinti sąveikos arba įgyvendinti ją tik per kitą sąsają, pavyzdžiui, valdymo sąsają. Patikrinti klientą pigiau nei perrašyti profilį, ir dažniausiai būtent ten ir slypi neatitikimas.

Ką serveris jau turi palaikyti

Profilis aprašo, ką klientas turi surinkti. Jis neįjungia tikrinimo serveryje, o serveris be atitinkamos autentifikavimo integracijos tiesiog gaus slaptažodį, kurio neatpažįsta. Štai kodėl kai kurie diegimai rodo raginimą ir atmeta kiekvieną kodą, ir štai kodėl operatoriaus atsakymas apie tai, kuris mechanizmas atlieka patikrą, yra tas atsakymas, kuris svarbus.

Paklauskite operatoriaus, kuris mechanizmas atlieka patikrą. Tai gali būti įskiepis, kalbantis su PAM, scenarijaus kablys, tikrinantis atsakymą su žetonų tarnyba, arba valdymu pagrįsta integracija, kuri pati analizuoja suvyniotą reikšmę. Kiekvienas jų tikisi kiek kitokios įvesties.

Čia taip pat reikia sukalibruoti lūkesčius. Antras raginimas yra įvesties mechanizmas, o ne įrodymas, kad antrasis veiksnys taikomas, nes taikymas vyksta serverio pusėje ir pasimato tik bandant neteisingą kodą.

Užkoduotas laukas, kurį siunčia valdymo sąsaja

Kai sąsaja valdo ryšį per valdymo sąsają, slaptažodis ir iššūkio atsakymas prieš siunčiant suvyniojami į vieną reikšmę. Valdymo sąsajos nuoroda dokumentuoja formatą: priešdėlis, tada slaptažodis ir atsakymas kaip atskiri Base64 komponentai.

Base64 yra koduotė, o ne apsauga. Ji nieko neslepia nuo to, kas gali perskaityti lauką, ir nepaverčia vienkartinio kodo kuo nors pakartotinai naudojamu. Suvyniota reikšmė nusipelno tokio paties elgesio kaip slaptažodis: lauk iš bendrų profilių, lauk iš komandų eilučių ir lauk iš diagnostikos žurnalų.

Ši koduotė taip pat yra dažniausia painiavos priežastis, nes dabar yra trys formos, kurios atrodo panašiai ir nėra sukeičiamos. Paprastas prisijungimo duomenų failas laiko slaptažodį. Pažodinis slaptažodžio ir kodo sujungimas laiko kitą eilutę. Valdymo kliento suvyniotas atsakymas laiko trečią. Prieš keisdami lauką vien todėl, kad klaida dingo, patvirtinkite, kurio tikisi jūsų patikros kelias.

Statinis prieš dinaminį: skirtingas laikas

Statinis iššūkis žinomas prieš pateikiant pirmą prisijungimo duomenį, todėl klientas gali jo paklausti iš anksto. Dinaminis iššūkis ateina vėliau, jį siunčia autentifikavimo eiga jau prasidėjus mainams, ir jam reikia kliento, galinčio apdoroti prašymą pokalbio viduryje.

Vieno palaikymas neduoda kito. Profilio direktyva, nustatanti statinį raginimą, neįgyvendina serverio inicijuoto iššūkio, o sąsaja, tvarkanti dinaminius prašymus, vis tiek gali nerodyti statinio. Skaitymas, kuri pusė pradėjo prašymą, yra greičiausias būdas juos atskirti.

Darbas be priežiūros yra vieta, kur tai tampa dizaino, o ne sąsajos klausimu. Išsaugotas kodas nėra ilgalaikis paleidimo prisijungimo duomuo, o prisijungimas iš naujo po kelių valandų pareikalaus naujos įvesties, nebent diegimas palaiko žetonų tvarką, kurią operatorius sąmoningai įjungė.

Tikrinkite ir sėkmę, ir nesėkmę, ne tik dialogą

Atlikite abi testo puses. Teisingi prisijungimo duomenys su galiojančiu atsakymu turėtų pavykti; teisingi prisijungimo duomenys su tyčia neteisingu atsakymu turėtų būti atmesti. Jei pavyksta abu, klientas renka įvestį, kurios niekas netikrina, o dialogas buvo palaikytas valdikliu. Šis vienas testas pagauna daugiau diegimų nei bet kokia profilio peržiūra.

Tada pakartokite ryšį po prisijungimo iš naujo, su paskyra, kuri neužregistruota, ir per tą klientą, kurį jūsų naudotojai iš tikrųjų naudoja. Raginimo pasirodymas yra kliento elgsena; neteisingo kodo atmetimas yra serveris, kuris ką nors taiko.