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

Проверяйте отрицательные случаи так же тщательно, как положительный. Профиль, показывающий приглашение для пароля, доказывает лишь то, что клиент умеет рисовать приглашение, а сервер, принимающий неверный пароль, доказывает нечто куда худшее. Добавьте в набор тестов отключённую учётную запись и просроченные учётные данные, а не только плохой пароль.

Меняйте политику, профиль и сопоставление вместе

Согласуйте три вещи: директиву сервера, профиль клиента и сопоставление идентичности для каждого клиента. Измените их по отдельности, и клиенты будут отказывать до проверки или подключаться под именем, которого администратор не ожидал, а это хуже, потому что выглядит как успех. Соединение, которое удаётся под неверной идентичностью, заметить труднее, чем то, которое терпит неудачу.

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

Запишите, какие методы аутентификации сервер действительно принимает, а не какие предлагает профиль. Эта запись отвечает на вопрос, который люди постоянно задают, а именно кто может подключиться к этому сервису. Она также переживёт следующего администратора, который иначе заново обнаружит её из перехвата пакетов.