Короткий ответ
В OpenVPN 2.6 смотрите лог с --verb 4, не иконку трея. Сначала: доходит ли UDP (часто 1194) до vpn.example.com, затем TLS (CA, время, tls-crypt/tls-auth), затем согласование data-ciphers, затем user/pass (AUTH_FAILED). Не ставьте remote-cert-tls в игнор и не выключайте verify-x509-name. Cipher в 2.6 задаётся через data-ciphers, старый --cipher без NCP ломает пару 2.4↔2.6.
Сохраните 50–100 строк лога вокруг первой ошибки. Одна строка TLS Error без контекста бесполезна.
Симптомы и как отличить
- GUI: Connecting → timeout.
- Лог:
TLS Error: TLS key negotiation failed to occur within 60 seconds. - Или
VERIFY ERROR,certificate has expired,AUTH_FAILED. - Windows: OpenVPN GUI / Community client, это не
Get-VpnConnection(RAS).
Отличия:
- RAS L2TP/IKEv2 — другие статьи IPsec/L2TP.
- Туннель CONNECTED, LAN нет — LAN.
- CONNECTED, сайты тупят — MTU.
Возможные причины
- UDP до endpoint не доходит (порт не 1194 — смотрите
remote vpn.example.com <port>в ovpn). remotehostname резолвится не туда.- Клиент и сервер: разный
proto udp/tcp, разный порт. - Неверный CA, просроченный серверный сертификат, часы клиента.
tls-cryptvstls-auth/ неверный static key.data-ciphersсервера не пересекаются с клиентом 2.6 (AES-GCM vs устаревший BF-CBC only).AUTH_FAILED: логин,auth-user-pass-verify, сертификат клиента revoked.--dev tunотсутствует, нет TAP-драйвера на Windows (для tap-профиля).
Диагностика
1. Лог, не GUI
openvpn --config /etc/openvpn/client/office.ovpn --verb 4Windows (пример пути Community client):
& 'C:\Program Files\OpenVPN\bin\openvpn.exe' --config 'C:\Program Files\OpenVPN\config\office.ovpn' --verb 4Ищите первую фатальную строку.
2. Сеть до remote
getent hosts vpn.example.com
tcpdump -n -i any udp port 1194На сервере — тот же tcpdump на WAN. Тишина при старте клиента = сеть. Порт возьмите из remote, не из памяти.
Resolve-DnsName vpn.example.com
Get-VpnConnection | Format-List Name, TunnelTypeGet-VpnConnection здесь для контроля, что вы не смотрите не тот клиент.
3. TLS и CA
openssl x509 -in ca.crt -noout -dates -subject
openssl x509 -in client.crt -noout -dates -issuerНа сервере: remote-cert-tls client, срок server.crt. Часы:
timedatectl4. Cipher 2.6
В логе NCP: Data Channel: using negotiated cipher. Если failed to negotiate cipher — сверьте data-ciphers / data-ciphers-fallback на сервере и клиенте. В 2.6 Blowfish по умолчанию нет.
Решение
Сценарий A. 60 seconds TLS timeout, tcpdump пуст
Откройте тот UDP/TCP порт, что в remote. Проверьте proto. Если сервер за DNAT — DNAT UDP, не TCP (если proto udp). Клиентскому NAT ничего открывать не нужно.
Сценарий B. VERIFY ERROR / expired
Обновите ca.crt на клиенте из той же CA, что подписала сервер. Замените просроченный server.crt. Выровняйте NTP. Не ставьте verify-hash в ноль.
Сценарий C. tls-crypt mismatch
Одинаковый ключ, одинаковая директива (tls-crypt vs tls-auth + direction). После замены ключа обновите все клиенты, иначе получите массовый timeout.
Сценарий D. data-ciphers
Сервер OpenVPN 2.6 (пример согласованной политики):
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
data-ciphers-fallback AES-256-GCMКлиент 2.6 без устаревшего --cipher BF-CBC. Старым 2.4 оставьте fallback только если они ещё существуют, и запланируйте апгрейд.
Сценарий E. AUTH_FAILED
Сверьте логин (не сертификат). Смотрите лог openvpn-auth / PAM / verify script. Блокировка AD после N попыток — не «сломан OpenVPN». Сертификат+пароль: оба должны пройти.
Сценарий F. Windows TAP/TUN
Для dev tun Community-клиент использует wintun/ovpn-dco при наличии, иначе tap. Установите драйвер из инсталлятора OpenVPN, не сторонний «fix tap». После установки — повтор --verb 4.
Стенд: 2.4-сервер и клиент 2.6
Сервер на старом cipher AES-256-CBC без data-ciphers, клиент OpenVPN 2.6 с дефолтным GCM-only. Лог клиента: negotiation cipher failed / нет TLS timeout, а более поздний обрыв data channel. Это не CA. На сервере 2.6 задайте явный список GCM и запланируйте апгрейд; на время — data-ciphers-fallback только если ещё живы 2.4, с датой выключения.
Второй стенд: tls-crypt на сервере, у клиента старый tls-auth и key-direction 1. Симптом неотличим от «UDP не доходит», пока не включите --verb 4 и не увидите TLS Error сразу после появления пакетов в tcpdump.
grep -E '^(remote|proto|port|data-ciphers|tls-crypt|tls-auth|auth-user-pass)' office.ovpn
ss -ulnp | grep -E '1194|443'Windows: не чините это через Get-VpnConnection — RAS не читает ovpn. Если параллельно поднят IKEv2, маршруты двух клиентов конфликтуют; отключите лишний профиль на время теста TLS.
Не ставьте remote-cert-tls server в комментарий «для проверки». На стенде используйте отдельный CA.
Как проверить, что проблема устранена
В логе: Initialization Sequence Completed. Затем:
ip addr show tun0
ping -c 2 10.8.0.1
ping -c 2 10.0.10.10Windows: адаптер OpenVPN с адресом из пула, Test-NetConnection 10.0.10.10. DNS — по необходимости DNS.
Если не помогло
- TLS есть, виснет на больших пакетах — MTU
tun-mtu/mssfix, статья MTU. - Регулярные
Inactivity timeout— keepaliveping/ping-restartна обеих сторонах, разрывы. - TCP OpenVPN поверх плохого канала — медленно и обрывисто; UDP предпочтителен.
- Сравните, не проще ли WireGuard для новых клиентов.
Профилактика
- Централизованная выдача ovpn (PKI), отзыв через CRL, не шаринг одного client.crt.
- Сервер 2.6, явный
data-ciphers. - Мониторинг: число клиентов, TLS errors, срок CA/server cert.
--verb 3в проде достаточно;verb 4— на время инцидента.
FAQ
Почему GUI зелёный, а ping нет?
Тогда клиент подключился. Эта статья про Connect. Дальше маршруты/LAN.
Можно ли tls-verify отключить для теста?
На проде нет. На стенде — отдельный CA, не боевой сервер с verify off.
Порт 443/tcp спасёт корпоративный фильтр?
Иногда, ценой TCP-over-TCP. Это костыль. Предпочтительнее разрешить UDP явно.
community vs Access Server
Директивы похожи, но лицензия и веб-GUI AS — другой продукт. Лог всё равно читаете тот же стиль TLS.
Get-VpnConnection не показывает OpenVPN
Ожидаемо. RAS ≠ OpenVPN. Не чините не тот стек.