OpenVPN: ошибка аутентификации — решение

MAATRIX

Вы пытаетесь подключиться к OpenVPN, а вместо «Connected» видите в клиенте AUTH_FAILED — и соединение тут же обрывается. Клиент почти ничего не объясняет, а сервер, к которому у вас, возможно, есть только SSH-доступ, кажется чёрным ящиком. Разберём по шагам, где искать настоящую причину и как её устранить — без предположения, что вы уже когда-то копались в логах сервера.

Почему клиент молчит, а сервер — говорит

AUTH_FAILED — универсальная фраза OpenVPN, означающая буквально «сервер отказал в доступе». Причин отказа минимум пять, и приложение на вашем телефоне или ноутбуке не может знать точную — сервер ей просто не сообщает подробностей. Это сделано намеренно: если бы сервер отвечал «неверный пароль» или «сертификат просрочен» прямо любому, кто стучится в дверь, злоумышленнику было бы проще перебирать варианты.

Зато сервер честно пишет причину в свой лог-файл — тот, что виден только тому, у кого есть доступ к самой машине. С него и начнём. Если сервер настраивался «с нуля» по инструкции, для общего контекста пригодится статья про установку OpenVPN на VPS — там описана структура файлов, на которую мы будем ссылаться ниже.

Как посмотреть точную причину в логе сервера

Подключитесь к серверу по SSH: откройте терминал на своём компьютере и наберите ssh root@ваш_ip_адрес, введите пароль или используйте ключ — так же, как подключались раньше.

Если OpenVPN запущен через systemd (стандартный способ управления сервисами в Ubuntu/Debian), логи читаются через journalctl:

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

journalctl — программа для чтения системного журнала. -u openvpn-server@server — показать записи только этого сервиса (имя иногда другое, openvpn@server — если команда выдаст «не найдено», попробуйте так). -n 100 — последние 100 строк. --no-pager — вывести всё сразу, не открывая постраничный просмотр.

Чтобы смотреть лог в реальном времени прямо в момент подключения:

journalctl -u openvpn-server@server -f

-f («follow») держит окно открытым и показывает новые строки по мере появления. Оставьте терминал открытым и на клиенте попробуйте подключиться ещё раз — в момент неудачи появится несколько новых строк с ответом. Остановить просмотр — Ctrl+C.

Если OpenVPN настроен через отдельный файл (без systemd), лог обычно лежит в /var/log/openvpn/openvpn.log:

tail -f /var/log/openvpn/openvpn.log

tail показывает конец файла, а не весь текст целиком; -f работает так же, как в journalctl.

Если строк мало и они ничего не объясняют, поднимите уровень подробности. В конфиге сервера (/etc/openvpn/server/server.conf или /etc/openvpn/server.conf) найдите строку verb и временно поставьте:

verb 4

Стандартное значение — 3, оно даёт минимум деталей. После правки перезапустите сервис: systemctl restart openvpn-server@server. Не забудьте вернуть verb 3 обратно, когда разберётесь — подробные логи быстро растут в размере.

Причина: неверный логин или пароль (auth-user-pass)

Если аутентификация идёт по логину и паролю (директива auth-user-pass в конфиге клиента), в логе сервера будет:

TLS: Username/Password authentication failed for username 'ivan'

Это самая понятная ошибка — сервер прямо называет имя пользователя. Если имя вообще не то, что вы ожидали, — в файле с учётными данными на клиенте опечатка или устаревшие данные.

Что проверить:

• Раскладку клавиатуры при ручном вводе — кириллица вместо латиницы или незамеченный Caps Lock портят пароль незаметно для глаза.
• Файл с логином и паролем на клиенте (обычно две строки — логин и пароль). Откройте текстовым редактором, убедитесь, что нет лишнего пробела или пустой строки в конце.
• Срок действия системного аккаунта, если пользователи хранятся через PAM: chage -l ivan покажет дату истечения.
• Отдельный файл с парами логин:пароль (например, /etc/openvpn/psw-file) — убедитесь, что строка для нужного пользователя там есть и оформлена правильно.

Сбросить пароль: passwd ivan — система попросит ввести новый пароль дважды. После смены обновите пароль и в конфигурации клиента, иначе ошибка повторится.

Причина: сертификат клиента просрочен или отозван

При аутентификации по сертификатам (более распространённая и безопасная схема) ошибка в логе сервера выглядит иначе:

VERIFY ERROR: depth=0, error=certificate has expired

или error=certificate revoked. Первая — у клиентского сертификата вышел срок действия: сертификаты OpenVPN выпускаются на определённый срок (часто 1–3 года при стандартных настройках Easy-RSA) и потом перестают приниматься — это защита, а не баг.

Проверить срок действия сертификата (файл .crt у клиента или в pki/issued/ на сервере):

openssl x509 -in client1.crt -noout -enddate

openssl x509 работает с сертификатами формата X.509. -in client1.crt — какой файл читать. -noout — не выводить сам сертификат целиком (он нечитаем глазами), только запрошенное. -enddate — вывести дату окончания. Ответ вида notAfter=Mar 12 08:00:00 2026 GMT — если дата уже в прошлом, вот и причина.

Выпустить новый сертификат через Easy-RSA (утилита, которой почти наверняка настраивался сервер):

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

nopass — приватный ключ не будет дополнительно зашифрован паролем (для VPN это обычно приемлемо, ключ и так хранится только у владельца устройства). Новый client1.crt скопируйте на устройство взамен старого.

«certificate revoked» означает, что сертификат отозван вручную — например, командой easyrsa revoke client1, и вы забыли, что это было именно текущее устройство. Отозванные сертификаты попадают в список CRL (crl.pem), который сервер сверяет при каждом подключении. Отменить отзыв нельзя — выход один: выпустить новый сертификат командой выше.

Причина: несовпадение Common Name сертификата

У каждого сертификата есть поле Common Name (CN) — имя, заданное при создании (build-client-full client1 выше как раз задаёт CN равным client1). Сервер может быть настроен на строгую проверку: одно и то же CN не должно использоваться с двух устройств одновременно.

Если у вас несколько устройств (телефон и ноутбук) используют один и тот же файл сертификата — при одновременном подключении сервер обрывает одно из соединений в зависимости от настройки duplicate-cn в конфиге. Решения два:

1. Добавить в конфиг сервера строку duplicate-cn — она разрешает нескольким устройствам подключаться под одним сертификатом одновременно. Быстро, но менее аккуратно: в логах не видно, какое именно устройство сейчас в сети.
2. Выпустить для каждого устройства свой сертификат с уникальным CN (build-client-full phone-ivan nopass, build-client-full laptop-ivan nopass) — тогда в логе всегда видно, какое устройство подключено, и можно отозвать доступ одному, не трогая остальные.

Второй вариант надёжнее, если вы администрируете сервер сами и планируете растить число пользователей.

Причина: рассинхронизация ta.key между клиентом и сервером

Если в конфигурации есть tls-auth (или более новый tls-crypt) — дополнительная защита через общий ключ ta.key, — при несовпадении этого ключа в логе появится:

TLS Error: cannot locate HMAC in the incoming packet from [AF_INET]x.x.x.x

ta.key — не сертификат и не пароль, а файл с общим секретом, который должен быть идентичен на сервере и на клиенте. Он подписывает пакеты ещё до начала обычной TLS-аутентификации — это защита от определённых сетевых атак и способ спрятать сам факт использования OpenVPN от анализа трафика.

Ошибка HMAC почти всегда означает одно из двух:

• На клиенте лежит устаревшая копия ta.key — например, сервер переустанавливали и ключ перегенерировали, а клиентам не разослали новый файл.
• В конфигах указано одинаковое направление ключа вместо противоположного. На сервере: tls-auth ta.key 0, на клиенте: tls-auth ta.key 1 (или наоборот, но обязательно по-разному).

Убедиться, что ta.key на клиенте и на сервере совпадает побайтово, можно контрольной суммой на обеих машинах:

sha256sum ta.key

Если строки-«отпечатки» разные — файлы разные, нужно скопировать актуальный ta.key с сервера на клиент заново безопасным способом (например, через scp по SSH, а не почтой или мессенджером — это секретный ключ). Для tls-crypt логика диагностики та же, разница лишь в том, что он ещё и шифрует управляющий канал целиком.

Подробный разбор прочих типичных сбоев OpenVPN (не только аутентификации) есть в статье про частые ошибки OpenVPN на сервере — пригодится, если проблема окажется смежной.

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

Причина реже приходит в голову новичку, но встречается часто — особенно на VPS, которые долго простаивали или работали в виртуальной машине с «плывущими» часами, либо на старых Android-телефонах и роутерах, где время сбилось после перезагрузки.

Проверка TLS-сертификата сверяет текущее время с полями «действует с» и «действует по». Если время на сервере или клиенте убежало на несколько часов или дней, сертификат может показаться ещё не вступившим в силу или уже истёкшим, даже если по календарю всё в порядке:

VERIFY ERROR: depth=1, error=certificate is not yet valid

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

timedatectl

Команда покажет текущую дату, часовой пояс и строку System clock synchronized: yes/no. Если там no, часы никто не подводит и рано или поздно разъедутся с реальным временем.

Включить синхронизацию:

timedatectl set-ntp true

Если не помогает, поставьте более надёжный chrony:

apt install chrony
systemctl enable --now chrony

apt install chrony ставит программу точной синхронизации времени по сети. systemctl enable --now chrony включает автозапуск при загрузке и сразу запускает службу, не дожидаясь перезагрузки.

На клиенте (телефон, ноутбук) проверьте, что включена автоматическая установка времени по сети в системных настройках даты — ручной перевод времени «на глаз» для другой задачи и забытый обратно автоматический режим — частая причина именно на телефонах.

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