OpenVPN на сервере: частые ошибки и решения

MAATRIX

OpenVPN редко ломается сам по себе, но легко перестаёт работать из-за мелочей: закрытого порта, съехавшего времени, устаревшего конфига или забытого NAT. Ниже — частые ошибки OpenVPN на сервере, разобранные по симптомам: что видно в логе, где искать причину и какими командами чинить, не переустанавливая всё заново.

Где смотреть, что случилось

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

systemctl status openvpn-server@server
journalctl -u openvpn-server@server -n 60 --no-pager

Ключевые строки, на которые смотрят: TLS handshake failed говорит о том, что клиент не достучался или не прошёл проверку сертификатов; AUTH_FAILED — о проблеме с логином, паролем или отозванным сертификатом; Initialization Sequence Completed на стороне клиента, наоборот, означает, что канал поднялся и дальше надо искать проблему в маршрутизации. Приучитесь читать лог с конца: последняя осмысленная строка перед разрывом обычно и указывает на причину. Держите две сессии — одну с логом сервера, вторую с логом клиента, тогда картина складывается сразу с обеих сторон.

TLS handshake failed

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

ss -lunp | grep 1194
ufw allow 1194/udp

Если клиент настроен на UDP, а сервер слушает TCP (или наоборот) — handshake не состоится никогда, сколько ни перезапускай. Сверьте строку proto в серверном и клиентском конфигах. Вторая причина — внешний фаервол облака: правило для порта надо добавить и в security groups панели провайдера, а не только в ufw. Третья — сервер за NAT без проброса порта. Если всё это в порядке, а handshake всё равно молчит, попробуйте временно перевести сервер на TCP-порт 443: в сетях с глубокой фильтрацией стандартные VPN-порты режут, а 443 выглядит как обычный HTTPS и проходит.

AUTH_FAILED при подключении

Здесь проблема уже не в сети — клиент дошёл до сервера, но не прошёл аутентификацию. Частые причины: сертификат клиента отозван (проверьте список отзыва CRL), истёк срок действия сертификата, либо на сервере включена парольная аутентификация, а клиент её не передаёт. Проверьте срок годности сертификата и, если он истёк, перевыпустите профиль. Ещё одна коварная причина — рассинхрон часов: если системное время сервера ушло, проверка валидности сертификата проваливается. Убедитесь, что время корректно:

timedatectl
timedatectl set-ntp true

Если вы недавно пересоздавали PKI или переустанавливали сервер, старые клиентские профили перестают работать — их нужно выдать заново, потому что они подписаны прежним центром сертификации. Отдельно стоит проверить журнал на строку VERIFY ERROR: она прямо указывает, что клиент не доверяет сертификату сервера, — обычно это следствие того, что профиль собран под другой CA. В такой ситуации не пытайтесь чинить старый .ovpn вручную, быстрее и надёжнее сгенерировать новый профиль тем же скриптом или средствами easy-rsa.

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

Подключился, но интернета нет

Клиент видит Initialization Sequence Completed, получил адрес в туннеле, а сайты не открываются. Значит сервер не маскирует трафик наружу. Нужны IP-форвардинг и правило NAT на внешнем интерфейсе:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Подставьте имя своего внешнего интерфейса — узнать его можно через ip route get 8.8.8.8, оно указано после dev. Частая ошибка — правило написано для eth0, а интерфейс называется ens3, и masquerade не срабатывает. Если наружу не идёт вообще ничего, проверьте также, что серверный конфиг раздаёт клиенту маршрут по умолчанию строкой push "redirect-gateway def1 bypass-dhcp". Без неё через туннель пойдёт только трафик до подсети сервера, а не весь интернет.

Если masquerade вроде бы на месте, а наружу всё равно ничего не уходит, проверьте порядок и таблицу правил iptables -t nat -L -n -v — счётчик пакетов на правиле POSTROUTING должен расти при попытках выйти в сеть. Нулевой счётчик означает, что трафик до правила просто не доходит: либо не тот интерфейс, либо не та исходная подсеть в -s. Ещё одна тонкая причина — включённый, но не настроенный firewalld или сторонний фаервол, который тихо режет форвардинг; на серверах с ним правила OpenVPN нужно заводить его средствами, а не голым iptables, иначе они конфликтуют.

Работает, но по именам сайты не открываются

Если по IP всё доступно, а по доменам нет, клиент не получил рабочий DNS. В серверном конфиге должны быть строки вида push "dhcp-option DNS 1.1.1.1". На Windows дополнительно помогает block-outside-dns — иначе система продолжает спрашивать имена у провайдерского резолвера в обход туннеля, и это же выдаёт DNS-утечку в тестах. Проверьте на клиенте, какой DNS реально используется, и при утечке задайте резолвер явно в настройках сетевого адаптера.

Обрывы и нестабильность

Если соединение периодически рвётся, первым делом посмотрите на транспорт. UDP чувствителен к потерям пакетов: на плохом мобильном канале TCP-режим (порт 443) держится заметно стабильнее, хоть и медленнее. Параметры keepalive 10 120 в серверном конфиге заставляют OpenVPN пинговать клиента и переустанавливать мёртвые сессии — убедитесь, что они на месте. Если рвётся под нагрузкой при тяжёлых загрузках, а мелочь ходит нормально, добавьте tun-mtu 1400 и mssfix — это лечит фрагментацию. И помните, что часть обрывов — не про конфиг, а про качество ноды: на перегруженном сервере с плавающей полосой стабильности не добиться. Под постоянный VPN берите VPS с гарантированными ресурсами и чистым IP — например, у MAATRIX, где сервер в США или Европе можно оплатить из России картой, СБП или криптой.

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