OpenVPN: TLS handshake failed — решение

MAATRIX

Если в логе OpenVPN вы видите строку TLS Error: TLS handshake failed, а подключение не поднимается — не спешите переустанавливать сервер. Это не одна конкретная поломка, а общий сигнал «клиент и сервер не смогли договориться о защищённом канале», и причин у него ровно четыре: рассинхрон времени, проблема с сертификатами, несовпадение версии TLS или заблокированный порт. Ниже — как отличить одно от другого по конкретным строкам в логе.

Как посмотреть лог и что вообще значат эти строки

Если вы никогда не открывали лог сервера — это просто текстовый файл, куда программа построчно записывает всё, что с ней происходит: что она пытается сделать, что получилось, а что нет. Чтобы посмотреть последние записи лога OpenVPN на сервере с Ubuntu/Debian, подключитесь по SSH и выполните команду:

journalctl -u openvpn-server@server -n 80 --no-pager

Разберём команду. journalctl — программа, которая показывает системный журнал всех сервисов. Флаг -u openvpn-server@server говорит «покажи только записи сервиса OpenVPN» (имя после @ — название вашего конфига, если оно другое, замените на своё; список активных юнитов покажет systemctl list-units | grep openvpn). Флаг -n 80 означает «последние 80 строк», а --no-pager — «вывести всё сразу, без постраничного просмотра». В ответ вы увидите строки с датой, временем и текстом сообщения — это история попыток подключения.

Читать лог нужно снизу вверх: последняя строка перед разрывом обычно и есть причина. Если OpenVPN у вас запускается вручную командой openvpn --config client.ovpn, тот же текст будет просто печататься прямо в окне терминала.

Если OpenVPN у вас ещё не установлен, сначала посмотрите пошаговую установку OpenVPN на VPS — эта статья разбирает уже готовую, но не работающую установку.

Причина 1: время на клиенте и сервере разошлось

Это самая частая причина ошибки TLS handshake failed, и она же самая обидная — конфиг и сертификаты в полном порядке, просто у одной из машин съехали системные часы. TLS-сертификаты содержат срок действия («годен с… по…»), и если системное время устройства выходит за эти рамки хотя бы на несколько минут, проверка подлинности проваливается ещё до реального обмена данными.

В логе рассинхрон времени обычно выглядит так:

VERIFY ERROR: depth=0, error=certificate is not yet valid: C=RU, ST=..., CN=client1
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed

Строка certificate is not yet valid означает, что с точки зрения машины сертификат ещё не начал действовать — локальное время отстаёт от реального. Обратный вариант, certificate has expired при живом (не истёкшем на самом деле) сертификате, говорит, что время, наоборот, убежало вперёд. Часто это случается на свежих VPS с часами, сбившимися при старте, либо на ПК с отключённой автосинхронизацией времени.

Проверить текущее время и статус синхронизации на сервере:

timedatectl

Эта команда выводит текущую дату, часовой пояс и — что важно — строку System clock synchronized: yes/no. Если там no, время не подтягивается автоматически. Включить синхронизацию через встроенный в systemd сервис (он есть почти на всех современных Ubuntu/Debian):

timedatectl set-ntp true
systemctl restart systemd-timesyncd

Если после этого System clock synchronized всё ещё no, можно принудительно подтянуть время одной командой через ntpdate (на новых системах её иногда нужно доустановить: apt install ntpdate):

ntpdate pool.ntp.org

Эта команда один раз спрашивает точное время у публичного NTP-сервера и сразу выставляет его на машине — быстрый способ «руками» поправить часы, если ждать автоматической синхронизации некогда. После этого проверьте timedatectl ещё раз и перезапустите OpenVPN:

systemctl restart openvpn-server@server

Не забудьте проверить время не только на сервере, но и на клиентском устройстве — рассинхрон одинаково ломает handshake с любой стороны.

Причина 2: сертификат неверный, просроченный или от чужого CA

Если время в порядке, а строка VERIFY ERROR в логе всё равно есть — дело в самом сертификате. Здесь возможны три разных сообщения, и они указывают на разные проблемы:

VERIFY ERROR: depth=0, error=certificate has expired: CN=client1
VERIFY ERROR: depth=1, error=unable to get local issuer certificate: CN=Easy-RSA CA
TLS_ERROR: BIO read tls_read_plaintext error: error:0A000418:SSL routines::tlsv1 alert unknown ca

Первая строка — сертификат реально истёк по сроку действия (не путайте с рассинхроном времени из предыдущего пункта: тут время верное, а сам сертификат старый). Проверить срок действия конкретного сертификата можно так:

openssl x509 -enddate -noout -in /etc/openvpn/easy-rsa/pki/issued/client1.crt

Команда openssl x509 читает файл сертификата, -enddate просит показать только дату окончания срока, -noout — не выводить сам сертификат целиком, -in указывает путь к файлу. В ответ вы увидите строку вида notAfter=Aug 20 10:00:00 2026 GMT — если дата уже прошла, сертификат просрочен и его нужно перевыпустить.

Вторая строка, unable to get local issuer certificate, значит, что машина не доверяет центру сертификации (CA), которым подписан сертификат собеседника. Обычно это случается, если сервер переустанавливали или пересоздавали PKI через easy-rsa, а старые клиентские .ovpn-профили остались подписаны прежним CA. Решение одно — не чинить старый профиль, а выпустить клиенту новый сертификат под текущим CA:

cd /etc/openvpn/easy-rsa
./easyrsa build-client-full client1 nopass

Третья строка, unknown ca, — то же самое сообщение с другой стороны: собеседник получил чужой сертификат и не смог его проверить. Также стоит свериться со списком отозванных сертификатов (CRL): если сертификат клиента отозвали вручную (увольнение сотрудника, утечка ключа), handshake падает даже при верном времени и живом сроке. Обновить CRL на сервере:

./easyrsa gen-crl
cp pki/crl.pem /etc/openvpn/server/

Причина 3: не совпадает версия протокола TLS

Более редкая, но реальная причина — сервер и клиент используют разные минимальные версии TLS и не могут договориться о протоколе. Встречается, если на сервере задан tls-version-min 1.2 (это правильно с точки зрения безопасности), а клиент — старая версия OpenVPN или прошивка роутера — умеет только TLS 1.0/1.1. В логе это выглядит иначе, чем ошибка сертификата: сообщение приходит от библиотеки OpenSSL, а не от логики проверки сертификата OpenVPN:

TLS_ERROR: BIO read tls_read_plaintext error
OpenSSL: error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
TLS Error: TLS handshake failed

Ключевая строка тут — tlsv1 alert protocol version: это буквально ответ одной стороны «я не поддерживаю версию TLS, которую ты предлагаешь». Похожий по смыслу вариант — конфликт набора шифров, а не версии, тогда в логе будет no shared cipher вместо protocol version; лечится это так же — приведением настроек TLS к общему знаменателю.

Проверить, что задано на сервере, можно посмотрев конфиг:

grep -i "tls-version-min\|tls-cipher" /etc/openvpn/server/server.conf

Команда grep ищет в файле строки с указанным текстом, флаг -i делает поиск нечувствительным к регистру. Если сервер требует tls-version-min 1.2, а клиент старый, есть два варианта: обновить клиентское приложение OpenVPN (правильный путь — старые версии и сами по себе небезопасны) либо временно смягчить требование на сервере:

tls-version-min 1.0

Это компромисс ради совместимости, а не практика на постоянной основе — верните tls-version-min 1.2 или выше, как только обновите клиентские устройства. Точные версии OpenVPN и OpenSSL, при которых возникает такой конфликт, отличаются от системы к системе — сверяйтесь со своим openvpn --version на обеих сторонах, а не с цифрами из этой статьи.

Причина 4: порт заблокирован фаерволом или провайдером

Здесь самая коварная ситуация: ошибка в логе выглядит точь-в-точь как проблема с сертификатами, хотя дело вообще не в TLS — трафик клиента до сервера просто не доходит. На стороне клиента вы увидите не мгновенный отказ, а повторяющуюся попытку, растянутую на минуту:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed

Отличительный признак — цифра «60 seconds» и то, что строка повторяется раз за разом без изменений. Так выглядит не отказ TLS, а тайм-аут ожидания: клиент пытался начать разговор, но ни один пакет от сервера не вернулся. Типичные причины: порт закрыт в фаерволе на сервере, не открыт в security group облачного провайдера (отдельная настройка снаружи ОС, про неё часто забывают), либо оператор связи режет нестандартные VPN-порты у клиента.

Проверить на сервере, что порт вообще слушается нужным протоколом:

ss -lunp | grep 1194

Команда ss показывает список слушающих сетевых портов: -l — только слушающие, -u — протокол UDP (для TCP используйте -t), -n — номера портов без определения имён, -p — какой процесс держит порт. grep 1194 оставляет только строки с портом 1194 (стандартный порт OpenVPN, поменяйте на свой). Пустой ответ значит, что сервис не запущен либо слушает другой протокол или порт.

Если сервис слушает порт правильно, а снаружи всё равно тишина — проверьте фаервол на самом сервере:

ufw status
ufw allow 1194/udp

И отдельно проверьте правило в панели облачного провайдера (security group / firewall rules) — это настройка на уровне виртуализации, отдельная от ufw внутри ОС, добавлять правило нужно в обоих местах. Если порт открыт везде, а провайдер клиента всё равно режет нестандартные VPN-порты (частая ситуация в мобильных сетях и офисном Wi-Fi), самое надёжное решение — перевести сервер на TCP-порт 443: это порт обычного HTTPS-сайта, его почти никогда не блокируют. Подробнее про фаервол — в статье про UFW: частые ошибки и решения.

Пошаговый алгоритм: как быстро найти свою причину

Чтобы не перебирать все четыре варианта наугад, идите по порядку — это займёт меньше времени, чем кажется:

1. Откройте лог (journalctl -u openvpn-server@server -n 80 --no-pager) и найдите последнюю осмысленную строку перед разрывом.
2. Если видите TLS key negotiation failed to occur within 60 seconds — это про сеть, а не про сертификаты. Идите сразу к причине 4 (порт).
3. Если видите VERIFY ERROR — проверьте сначала время (timedatectl) на обеих машинах, потом срок сертификата (openssl x509 -enddate).
4. Если видите alert protocol version или no shared cipher от OpenSSL — сверьте tls-version-min в конфиге сервера с версией клиента.
5. Если лог вообще пустой или новых строк не появляется при попытке подключения — сначала убедитесь, что сервис запущен (systemctl status openvpn-server@server), и только потом ищите проблему в TLS.

Частые вопросы