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 часта ўключаюць побач, і ён змяняе ідэнтыфікатар, які бачаць пазнейшыя звароты і файлы канфігурацыі асобнага кліента. Ён не правярае пароль і не робіць неадпаведны ўліковы запіс адпаведным. Гэта асобныя задачы, і менавіта іх блытаніна прыводзіць да таго, што міграцыя праходзіць тэст шчаслівага шляху і правальваецца на першым рэальным інцыдэнце.

Тэстуйце адмоўныя выпадкі так жа старанна, як станоўчы. Профіль, які паказвае запыт пароля, даказвае толькі тое, што кліент можа намаляваць запыт, а сервер, які прымае няправільны пароль, даказвае нешта значна горшае. Дадайце ў набор тэстаў адключаны ўліковы запіс і састарэлыя ўліковыя даныя, а не толькі дрэнны пароль.

Змяняйце палітыку, профіль і адлюстраванне разам

Узгадніце тры рэчы: дырэктыву сервера, кліенцкі профіль і адлюстраванне ідэнтычнасці для кожнага кліента. Змяніце іх паасобку, і кліенты не праходзяць праверку або падключаюцца пад імем, якога адміністратар не чакаў, што горш, бо выглядае як поспех. Злучэнне, якое ўдаецца пад няправільнай ідэнтычнасцю, заўважыць цяжэй, чым тое, якое не ўдаецца.

Трымайце два тэставыя ўліковыя запісы для гэтага шляху, адзін сапраўдны і адзін вядома дрэнны, і выкарыстоўвайце абодва пасля любой змены ў вэрыфікатары. Сапраўдны запіс даказвае шчаслівы шлях і адлюстраванне ідэнтычнасці; дрэнны даказвае, што адхіленне ўсё яшчэ працуе. Ніводзін тэст не кажа вам нічога пра правілы адпаведнасці, таму дадайце запіс, які павінен быць адхілены па палітычных прычынах, калі разгортванне іх мае. Запускайце ўсе тры пасля кожнай змены, бо вэрыфікатар, які пачынае прымаць усё, выглядае дакладна як працоўны ўваход.

Запішыце, якія метады аўтэнтыфікацыі сервер фактычна прымае, а не якія прапануе профіль. Гэты запіс адказвае на пытанне, якое людзі ўвесь час ставяць: хто можа падключыцца да гэтай паслугі. Ён таксама перажывае наступнага адміністратара, які інакш зноў выявіць яго з перахопу пакетаў.