Відмова в з'єднанні — не проблема сертифіката: настанови з 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, або той, що минув до підключення клієнта, дає помилки перевірки, які не мають нічого спільного з власним сертифікатом клієнта.

Короткі настанови на наступний раз

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

Запишіть транспорт, розв'язане призначення, порт і точний текст помилки. Перевстановлення клієнта знищує ці докази й зазвичай нічого не змінює.