Скрыпт OpenVPN auth-user-pass-verify: як правільна вяртаць код выхаду

OpenVPN дзейнічае роўна па адным выхадзе свайго скрыпта ўваходу: па статусе выхаду. Усё астатняе, што робіць скрыпт, — гэта ўпрыгожванне. Хук можа дасягнуць патрэбнага правяральніка, разабраць адказ і надрукаваць прыязны радок, але вярнуць статус, які азначае процілеглае задуманаму аўтарам. Спачатку прачытайце кантракт і напішыце адаптар вакол яго — і ўвесь гэты клас памылак знікне.

Кантракт невялікі: вызначце ўліковы запіс, які быў адпраўлены, задайце зацверджанаму правяральніку мэтавае пытанне і прымайце толькі дакументаваны станоўчы вынік гэтага правяральніка для гэтага запыту. Усё астатняе — інфраструктура.

Тры статусы, якія можа вярнуць хук

Для auth-user-pass-verify, кіраўніцтва OpenVPN 2.6 вызначае код выхаду 0 як прыняцце, 1 як адмову, а 2 як адкладзеную аўтэнтыфікацыю. Гэта адзіныя тры адказы, якія разумее сервер, і кожны з іх мае розныя наступствы для злучэння. Скрыпт, які выходзіць са статусам апошняй каманды, фактычна дазваляе выкліку лагавання або кроку ачысткі прагаласаваць. Запісвайце статус яўна ў кожнай галіне, уключаючы галіны, якія так і не дайшлі да правяральніка.

Поспех HTTP і поспех аўтэнтыфікацыі — гэта розныя ўзроўні, і іх змешванне — самая распаўсюджаная прычына памылак гэтага хука. Адказ 202 азначае, што запыт прыняты да апрацоўкі, а не што пароль быў правераны. Вызначце чаканы статус, форму адказу і канчатковы вердыкт з кантракта API, які вам далі, і не выдумляйце назву поля, бо яна выглядае праўдападобна.

Калі адказ сапраўды прыйдзе пазней, гэта адкладзены шлях, і яго трэба будаваць менавіта так. Адкладзеная спроба, якая ніколі не завяршаецца, трымае рэсурсы да сканчэння тайм-аўту.

Чытайце файл уліковых даных дакладна так, як ён запісаны

Пры дакументаваным метадзе праз файл сервер запісвае імя карыстальніка і пароль першымі двума радкамі часовага файла, перадае гэты шлях скрыпту і выдаляе файл, калі скрыпт вяртаецца. Чытайце гэтыя два радкі як даныя: ніколі не падключайце файл праз source, не выконвайце яго і не ўстаўляйце яго змест у камандны радок, дзе яго ўбачыць табліца працэсаў. Захоўвайце пароль байт за байтам, бо нармалізацыя, якую вы маглі б прымяніць да імені карыстальніка, ціха змяняе ўліковыя даныя. Каталог для гэтага часовага файла — рашэнне аб разгортванні, таму пераканайцеся, што ён існуе і не чытаецца ўсімі на хаспе.

Трымайце ўласныя ўліковыя даныя правяральніка асобна ад карыстальніцкіх: яны належаць інтэграцыі шлюза, жывуць у сховішчы сакрэтаў платформы і патрабуюць толькі дазволу на праверку, таму не з’яўляюцца доказам таго, што аўтэнтыфікаваўся пэўны чалавек. Не дазваляйце хуку стаць другім правяральнікам пароляў. Перапісванне параўнання хэшаў уручную не робіцца бяспечным праз аптымізацыю цыкла, а суправаджаны правяральнік ужо разумее салёную і дарагую схему сховішча ўліковых запісаў.

Вызначце, што азначае адказ, які немагчыма класіфікаваць

Тайм-аўты, памылкі транспарту, скажоныя адказы і недаступны бэкенд маюць адну ўласцівасць: ні адзін з іх не з’яўляецца станоўчай праверкай. Хук павінен закрывацца пры кожным з іх і запісваць прычыну, на якую можа рэагаваць аператар. Гэтая прычына належыць абароненаму логу, а не паведамленню, якое вяртаюць чалавеку, што спрабуе падключыцца.

Будзьце гэтак жа ўважлівыя да шляхоў, якія зусім не дасягаюць правяральніка. Адсутнае значэнне канфігурацыі, нечытальны сакрэт або незаўсталяваная залежнасць павінны даваць адмову з асобным аперацыйным маркерам, а не выпадковае прыняцце. Тэстуйце гэтыя галіны, выдаляючы залежнасць у лабараторыі, а не разважаючы пра іх. Там, дзе збой лагавання можа змяніць статус выхаду, лагаванне становіцца часткай рашэння і павінна стаць бясшкодным.

Канфігурацыя сервера тут таксама важная: скрыпты, вызначаныя карыстальнікам, улічваюцца толькі тады, калі бягучая канфігурацыя дазваляе іх на патрэбным узроўні бяспекі, і гэтая налада — свядомы выбар, а не значэнне па змаўчанні, якое трэба падвысіць.

Правярайце вердыкт, а не надрукаваны радок

Пабудуйце тэст, які непасрэдна правярае статус выхаду. Запішыце ўзорны файл уліковых даных, запусціце хук супраць яго з заведама добрым і заведама дрэнным уліковым запісам і чытайце статус, які паведамляе абалонка, а не тэкст, які друкуе скрыпт. Гэтая адна праверка ловіць большасць памылак кантракта яшчэ да таго, як кліент падключыцца.

Затым прагоньце тыя ж выпадкі праз рэальнага кліента супраць невытворчага слухача і пацвердзіце, што сервер запісаў: прынята, адхілена або адкладзена. Ахапіце адключаны ўліковы запіс, няправільны пароль, скажоны адказ правяральніка, тайм-аўт і недасяжны правяральнік. Калі які-небудзь выпадак трапляе ў стан, які вы не можаце назваць, адаптар не завершаны.

Трымайце адпаведнасць паміж вынікам правяральніка і статусам выхаду побач са скрыптам у рэпазіторыі, каб наступны інжынер мог прачытаць кантракт без зваротнай распрацоўкі кода.