Защо редактирането на .ovpn файл не може да включи MFA на сървъра

Добавяте auth-user-pass към профил, свързвате се отново и клиентът иска потребителско име и парола. Изглежда, че MFA е включен. След това въвеждате код от грешен акаунт или код, изтекъл преди десет минути, и тунелът все още се вдига. Това е симптомът: клиентът се е променил, сървърът — не. Еднократната парола е фактор само когато проверяващ на сървъра решава дали е валидна за идентичността, която я заявява.

Подканата доказва само, че клиентът е попитал, нищо повече

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

Инсталирането на приложение за удостоверяване на телефон също не създава тази връзка. Проектът Google Authenticator PAM е компонент за проверка на OTP, който може да стои зад OpenVPN; той не е начин да прикачите влизането в Google акаунт към импортиран профил.

Регистрацията е частта, която профилът не може да направи

TOTP се нуждае от регистрационен материал, споделен между приложението за удостоверяване и неговия проверяващ. Шестте цифри на телефона са резултат; семето зад тях е тайната и принадлежи на една идентичност.

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

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

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

Прочетете PAM стека, за да разберете какво наистина се изисква

Ред като account required pam_permit.so не реализира право на акаунт и не добавя фактор. Той разрешава този етап на управление на акаунти в PAM, което е твърдение за етап, а не за вашите потребители.

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

Съобразете взаимодействието на клиента с дизайна на сървъра

auth-user-pass

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

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

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

Повторни връзки, токени и тестът, който решава въпроса

Планирайте какво се случва след първото успешно влизане. Предишен приет код може да е изтекъл или да бъде отхвърлен като повторение при следващото удостоверяване. auth-nocache контролира задържането на идентификационни данни и не инсталира MFA, а reneg-sec 0 не е определение за поддръжка на TOTP, колкото и често да се появява във форумни теми.

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

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