Отказ в соединении — не проблема сертификата: руководство по VPN

Клиент сообщает об отказе в соединении сразу после того, как вы пересоздали CRL, поэтому CRL выглядит виноватым. Это не так. Отказ — ответ транспортного уровня, а проверка сертификата происходит позже, внутри рукопожатия туннеля. Совпадение по времени — это контекст, а не доказательство.

Две проверки разделяют случаи меньше чем за минуту, и ни одна из них не трогает настройки доверия.

Читайте ошибку на том уровне, который её создал

ECONNREFUSED от connect означает, что попытка транспорта была отклонена: что-то ответило reset, либо стек сообщил о недоступном порте. Проблема сертификата не может дать такую ошибку, потому что рукопожатие TLS никогда не начинается без транспортного соединения. Если вы видите отказ, клиент так и не дошёл до предъявления сертификата. Этот единственный факт исключает отзыв как причину.

Верно и обратное. Отозванный сертификат даёт завершённое TCP-соединение и неудачное рукопожатие, которое на сервере записывается как ошибка проверки.

Отказ TCP: никто не слушает

Для TCP проверьте, запущен ли нужный экземпляр и привязан ли он к адресу и порту из профиля. ss -lntp показывает слушателей, и их отсутствие — обычное объяснение. Межсетевой экран, который отклоняет, а не отбрасывает, даёт то же сообщение на стороне клиента, поэтому проверяют и то и другое.

Проверьте и семейство адресов. Служба, привязанная к 127.0.0.1 или только к IPv6, откажет клиенту, который разрешается в другой адрес.

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

У UDP нет рукопожатия, которое можно отклонить

OpenVPN через UDP не устанавливает соединение в смысле TCP, поэтому в момент connect отклонять нечего. В Linux ошибка, показанная UDP-сокетом, может происходить от ICMP port-unreachable, сгенерированного более ранней датаграммой. страница руководства udp(7) описывает такое асинхронное поведение.

Поэтому UDP-клиент может вывести отказ, когда процесс сервера работает, но не привязан к ожидаемому адресу.

Где на самом деле проверяется CRL

CRL запрашивается во время рукопожатия TLS, после того как противоположная сторона предъявит свой сертификат, и только если конфигурация сервера это разрешает. Опция OpenVPN crl-verify указывает на файл, а сбой появляется в журнале сервера как ошибка проверки с указанием сертификата.

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

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

Короткое руководство на следующий раз

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

Запишите транспорт, разрешённый адрес назначения, порт и точный текст ошибки. Переустановка клиента уничтожает эти доказательства и обычно ничего не меняет.