OpenVPN жүйесіне кіруде статикалық сынақ коды қайда орналасады

Клиент құпиясөз өрісінен кейін екінші ұяшықты көрсетеді, сіз аппараттық токеннен кодты тересіз, бірақ кіру аутентификация қатесімен әлі де сәтсіз аяқталады. Бұл ұяшық бар, демек профиль оны сұраған. Сервер мәнді түсінетін пішінде алды ма, жоқ па — бұл басқа мәселе және оған бірінші кезекте жауап беру керек.

Клиентіңіз шын мәнінде көрсететін сұраныстан бастаңыз

Профильде сұраныс мәтіні мен жауаптың теру кезінде көрсетілуін басқаратын жалаушасы бар статикалық сынақ директивасы болуы мүмкін. Сұраныс — диалогта көретін мәтін, ал жалауша — сол енгізудің көрсетілу баптауы. Екеуі де серверге бірдеңені қалай тексеру керегін айтпайды.

Сізге шын мәнінде берілген өрістерді санаңыз. Пайдаланушы атына арналған бір өріс және бір жасырын өріс — ешқандай сынақсыз кәдімгі құпиясөзбен кіру. Құпиясөзден кейін өз белгісімен пайда болатын екінші өріс — клиенттің сынақ өзара әрекетін іске асыруы.

Егер сіз қолданатын клиентте екінші ұяшық ешқашан шықпаса, сол клиент өзара әрекетті іске асырмауы мүмкін немесе оны тек басқару интерфейсі сияқты басқа алдыңғы жақ арқылы ғана іске асыруы мүмкін. Клиентті тексеру профильді қайта жазғаннан арзан, және сәйкессіздік әдетте дәл сонда болады.

Сервер бұрыннан қолдауы тиіс нәрселер

Профиль клиенттің нені жинауы керегін сипаттайды. Ол серверде тексеруді қоспайды, ал тиісті аутентификация интеграциясы жоқ сервер жай ғана өзі танымайтын құпиясөзді алады. Сондықтан кейбір орналастырулар сұранысты көрсетіп, әрбір кодты қабылдамайды, және сондықтан тексеруді қай механизм жасайтыны туралы оператордың жауабы маңызды.

Оператордан тексеруді қай механизм жасайтынын сұраңыз. Бұл PAM-мен сөйлесетін қосымша, жауапты токен қызметіне қарсы тексеретін скрипт ілгегі немесе жиналған мәнді өзі талдайтын басқаруға негізделген интеграция болуы мүмкін. Олардың әрқайсысы сәл басқаша енгізуді күтеді.

Мұнда күтулерді де калибрлеу керек. Екінші сұраныс — енгізу механизмі, ал екінші фактордың қолданылғанының дәлелі емес, өйткені қолдану сервер жағында болады және қате кодты сынағанда ғана көрінеді.

Басқару интерфейсі жіберетін кодталған өріс

Алдыңғы жақ қосылымды басқару интерфейсі арқылы басқарғанда, құпиясөз бен сынақ жауабы жіберілмес бұрын бір мәнге жиналады. Басқару интерфейсінің анықтамасы пішімді сипаттайды: префикс, содан кейін құпиясөз және жауап жеке Base64 құрамдастары ретінде.

Base64 — кодтау, қорғаныс емес. Ол өрісті оқи алатын ешкімнен ештеңе жасырмайды және бірреттік кодты қайта пайдалануға жарамды нәрсеге айналдырмайды. Жиналған мән құпиясөз сияқты қарауды қажет етеді: ортақ профильдерден тыс, пәрмен жолдарынан тыс және диагностикалық журналдардан тыс.

Бұл кодтау сонымен қатар шатасудың ең көп тараған көзі, өйткені қазір ұқсас көрінетін және бірін-бірі алмастырмайтын үш пішін бар. Қарапайым тіркелгі деректері файлы құпиясөзді ұстайды. Құпиясөз бен кодтың тікелей тіркесуі басқа жолды ұстайды. Басқару клиентінің жиналған жауабы үшіншісін ұстайды. Қате жоғалғаны үшін ғана өрісті өзгертуден бұрын тексеру жолыңыз қайсын күтетінін растаңыз.

Статикалық және динамикалық: әртүрлі уақыт

Статикалық сынақ бірінші тіркелгі деректері жіберілмес бұрын белгілі, сондықтан клиент оны алдын ала сұрай алады. Динамикалық сынақ кейінірек келеді, оны аутентификация ағыны алмасу басталғаннан кейін жібереді, және ол әңгіменің ортасындағы сұранысты өңдей алатын клиентті талап етеді.

Бірін қолдау екіншісін бермейді. Статикалық сұранысты орнататын профиль директивасы сервер бастаған сынақты іске асырмайды, ал динамикалық сұраныстарды өңдейтін алдыңғы жақ статикалықты әлі де көрсетпеуі мүмкін. Сұранысты қай тарап бастағанын оқу оларды ажыратудың ең жылдам жолы.

Қадағалаусыз жұмыс — бұл интерфейс емес, дизайн мәселесіне айналатын жер. Сақталған код — жүктелу кезіндегі тұрақты тіркелгі деректері емес, және сағаттардан кейінгі қайта қосылу жаңа енгізуді қажет етеді, егер орналастыру оператор әдейі қосқан токен тәртібін қолдамаса.

Сәттілікті де, сәтсіздікті де сынаңыз, тек диалогты емес

Тесттің екі жартысын да орындаңыз. Дұрыс тіркелгі деректері жарамды жауаппен өтуі керек; дұрыс тіркелгі деректері әдейі қате жауаппен қабылданбауы керек. Егер екеуі де өтсе, клиент ештеңе тексермейтін енгізуді жинап жатыр, ал диалог басқару құралы деп қателесілген. Сол бір тест профильді қараудан гөрі көбірек орналастыруды ұстайды.

Содан кейін қайта қосылғаннан кейін қосылымды тіркелмеген тіркелгімен және пайдаланушыларыңыз шын мәнінде іске қосатын клиент арқылы қайталаңыз. Сұраныстың пайда болуы — клиент мінезі; қате кодтың қабылданбауы — сервердің бірдеңені қолдануы.