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 често се вклучува покрај него, и го менува идентитетот што го гледаат подоцнежните повратни повици и конфигурациските датотеки по клиент. Тој не проверува лозинка и не прави неподобна сметка подобна. Тоа се одделни работи, и нивното мешање е начинот на кој една миграција го поминува тестот за среќен пат и не успева во својот прв вистински инцидент.

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

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

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

Држете две тест-сметки за овој пат, една важечка и една познато лоша, и користете ги двете по секоја промена на проверувачот. Важечката сметка го докажува среќниот пат и мапирањето на идентитетот; лошата докажува дека одбивањето и понатаму работи. Ниту еден тест не ви кажува ништо за правилата за подобност, затоа додајте сметка што треба да биде одбиена од политички причини ако распоредувањето ги има. Извршете ги сите три по секоја промена, затоа што проверувач што почнува да прифаќа сето изгледа точно како работна најава.

Запишете кои методи на автентикација серверот навистина ги прифаќа, а не кои ги предлага профилот. Тој запис одговара на прашањето што луѓето постојано го поставуваат, а тоа е кој може да се поврзе со оваа услуга. Тој исто така го надживува следниот администратор, кој инаку повторно би го открил од фаќање пакети.