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. Мора да одбија неважеће акредитиве, одбија онемогућене или неподобне налоге и затворено се прекида кад не може да достигне свој backend. username-as-common-name се често укључује уз то и мења идентитет који виде каснији повратни позиви и конфигурационе датотеке појединачног клијента. Не проверава лозинку и не чини неподобан налог подобним. То су одвојени послови, а њихово мешање је начин на који миграција прође тест срећног пута и падне на првом стварном инциденту.

Тестирајте негативне случајеве једнако пажљиво као позитивни. Профил који приказује упит за лозинку доказује само да клијент може да нацрта упит, док сервер који прихвати погрешну лозинку доказује нешто знатно горе. Додајте онемогућен налог и истекле акредитиве у тестни скуп, а не само лошу лозинку.

Мењајте политику, профил и мапирање заједно

Ускладите три ствари: серверску директиву, клијентски профил и мапирање идентитета по клијенту. Мењајте их одвојено па клијенти падну пре верификације или се повежу под именом које администратор није очекивао, што је горе јер изгледа као успех. Веза која успе под погрешним идентитетом теже се примећује од оне која падне.

Држите два тестна налога за тај пут, један ваљан и један познато лош, и користите оба након сваке промене верификатора. Ваљан налог доказује срећан пут и мапирање идентитета; лош доказује да одбијање још ради. Ниједан тест не говори ништа о правилима подобности, па додајте налог који би требало да буде одбијен из политичких разлога ако их имплементација има. Покрените сва три након сваке промене, јер верификатор који почне да прихвата све изгледа тачно као радна пријава.

Забележите које методе аутентикације сервер заиста прихвата, а не које профил предлаже. Тај запис одговара на питање које људи стално постављају, а то је ко може да се повеже на ову услугу. Он надживљава и следећег администратора, који би га иначе поново открио из снимања пакета.