OpenVPN без клиентски сертификат: сървърна политика, а не профил

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

Профилът не е политиката

Community OpenVPN 2.6 се доставя със задължителни клиентски сертификати, защото verify-client-cert по подразбиране е require. Задаването на none е това, което спира изискването за сертификат и предава автентикацията на клиента на каквато и подредба за потребителско име и парола сървърът вече използва. По-старите ръководства посягат към client-cert-not-required, остарялото изписване на същата идея, затова използвайте директивата, която вашата инсталирана версия документира. Във всеки случай промяната се извършва на сървъра и никой клиентски профил не може да я извърши.

Фрагментът по-долу е цялата промяна от страна на сървъра и сам по себе си не е работеща конфигурация за автентикация. verify-client-cert none премахва изискването за сертификат, а username-as-common-name прави името на акаунта идентичността, която виждат по-късните обратни извиквания и файловете за отделен клиент. Нито един от редовете не проверява парола, така че все още трябва да съществува верификатор.

verify-client-cert none
username-as-common-name

Този верификатор е плъгин или скрипт, управляван от auth-user-pass-verify, и трябва да е на място, преди някой от двата реда по-горе да означава нещо. Обръщането на реда ви дава прозорец, в който сървърът не иска сертификат и не проверява акаунт.

Какво все още проверява сървъра

Премахването на клиентския сертификат не премахва TLS. Сървърът запазва своя сертификат и ключ, а клиентът запазва доверието към CA и проверките на името на хоста, които му пречат да говори с измамник. Премахването на remote-cert-tls server или на CA пакета, защото клиентът вече няма сертификат, е често срещано и сериозно погрешно разчитане, а справката за 2.6 е категорична, че двете посоки са независими. Едната доказва сървъра пред клиента; другата доказва клиента пред сървъра.

Профилът може също да носи блок tls-auth или tls-crypt. Това е споделен ключ за контролния канал със свой собствен цикъл на разпространение и ротация, така че файл без редове за сертификат или ключ не е автоматично безопасен за публикуване. Отнасяйте се към него като към тайна, докато не го прочетете.

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

Какво трябва да прави верификаторът

След премахването на изискването за сертификат всичко почива на верификатора: плъгин или скрипт, управляван от auth-user-pass-verify. Той трябва да отхвърля невалидни идентификационни данни, да отхвърля деактивирани или неподходящи акаунти и да се проваля затворено, когато не може да достигне своя бекенд. username-as-common-name често се включва заедно и променя идентичността, която виждат по-късните обратни извиквания и конфигурационните файлове за отделен клиент. Той не проверява парола и не прави неподходящ акаунт подходящ. Това са отделни задачи и объркването им е начинът, по който една миграция минава теста за щастлив път и се проваля при първия си реален инцидент.

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

Променете политиката, профила и съпоставянето заедно

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

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

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