Скриптът auth-user-pass-verify на OpenVPN: как да върнете правилния код на изход

OpenVPN действа въз основа на точно един изход от скрипта за вход: статуса на изход. Всичко останало, което скриптът прави, е декорация. Куката може да стигне до правилния проверяващ, да анализира отговора и да отпечата приятелски ред, а да върне статус, който означава обратното на замисленото от автора. Прочетете договора първо и напишете адаптера около него и целият този клас грешки изчезва.

Договорът е малък: идентифицирайте подадения акаунт, задайте на одобрения проверяващ предвидения въпрос и приемайте само документирания положителен резултат на този проверяващ за тази заявка. Всичко останало е инфраструктура.

Трите статуса, които куката може да върне

За auth-user-pass-verify, ръководството на OpenVPN 2.6 определя код на изход 0 като приемане, 1 като отказ и 2 като отложена автентикация. Това са единствените три отговора, които сървърът разбира, и всеки от тях има различно последствие за връзката. Скрипт, който излиза със статуса на последната си команда, на практика е оставил извикване за журнал или стъпка за почистване да гласува. Записвайте статуса изрично във всеки клон, включително в клоните, които никога не са стигнали до проверяващия.

Успехът на HTTP и успехът на автентикацията са отделни слоеве и смесването им е най-честата причина тази кука да се обърка. Отговор 202 означава, че заявката е приета за обработка, а не че паролата е проверена. Дефинирайте очаквания статус, формата на отговора и крайната присъда от API договора, който ви е даден, и не измисляйте име на поле, защото изглежда правдоподобно.

Ако отговорът наистина пристигне по-късно, това е отложеният път и той трябва да бъде изграден като такъв. Отложен опит, който никога не завършва, задържа ресурси, докато изтече времето за изчакване.

Четете файла с идентификационни данни точно както е записан

При документирания метод чрез файл сървърът записва потребителското име и паролата като първите два реда на временен файл, подава този път на скрипта и изтрива файла, когато скриптът се върне. Четете тези два реда като данни: никога не включвайте файла чрез source, никога не го оценявайте и никога не поставяйте съдържанието му в команден ред, където таблицата на процесите може да го види. Запазете паролата байт по байт, защото нормализирането ѝ, както бихте нормализирали потребителско име, тихо променя идентификационните данни. Директорията за този временен файл е решение за внедряване, затова потвърдете, че съществува и не е четлива от всички на хоста.

Пазете собствените идентификационни данни на проверяващия отделно от тези на потребителя: те принадлежат на интеграцията с шлюза, живеят в хранилището за тайни на платформата и се нуждаят само от разрешение за проверка, така че не са доказателство, че конкретно лице се е автентикирало. Не позволявайте на куката да стане втори проверяващ на пароли. Ръчното преписване на сравнение на хеш не става безопасно чрез оптимизиране на цикъла, а поддържаният проверяващ вече разбира осолената и скъпа схема на хранилището на акаунти.

Решете какво означава некласифицируем отговор

Изтичанията на време, транспортните грешки, деформираните отговори и недостъпният бекенд споделят едно свойство: нито едно от тях не е положителна проверка. Куката трябва да се затваря при всяко от тях и да записва причина, по която операторът да действа. Тази причина принадлежи в защитен журнал, а не в съобщение, върнато на човека, който се опитва да се свърже.

Бъдете еднакво внимателни с пътищата, които изобщо не стигат до проверяващия. Липсваща стойност на конфигурацията, нечетима тайна или неинсталирана зависимост трябва да дават отказ с отделен оперативен маркер, а не случайно приемане. Тествайте тези клонове, като премахнете зависимостта в лаборатория, вместо да разсъждавате за тях. Когато неуспехът да се логне може да промени статуса на изход, логването става част от решението и трябва да бъде направено безвредно.

Конфигурацията на сървъра има значение и тук: дефинираните от потребителя скриптове се зачитат само когато текущата конфигурация ги разрешава при изискваното ниво на сигурност, а тази настройка е съзнателен избор, а не стойност по подразбиране, която да се повишава.

Проверявайте присъдата, а не отпечатания ред

Изградете тест, който проверява статуса на изход директно. Напишете примерен файл с идентификационни данни, пуснете куката срещу него с известно добър и известно лош акаунт и четете статуса, който шелът съобщава, а не текста, който скриптът отпечатва. Тази единствена проверка хваща повечето грешки в договора, преди клиент изобщо да се свърже.

След това пуснете същите случаи през реален клиент срещу неработен слушател и потвърдете какво е записал сървърът: приет, отказан или отложен. Покрийте деактивиран акаунт, грешна парола, деформиран отговор от проверяващия, изтичане на време и недостъпен проверяващ. Ако някой случай попадне в състояние, което не можете да назовете, адаптерът не е завършен.

Дръжте съпоставката между резултата на проверяващия и статуса на изход до скрипта в хранилището, така че следващият инженер да може да прочете договора, без да реконструира кода.