OpenVPN подключается, но ничего не идёт: найдите уровень, на котором теряется пакет

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

Сокет либо привязан, либо нет

Служба, которая сообщает об активности, всё ещё может быть привязана к адресу или транспорту, которых вы не предполагали. Спросите сам сокет: ss -lunp перечисляет UDP-слушателей, а ss -ltnp перечисляет TCP, и столбец, который стоит читать, это локальный адрес, а не состояние.

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

ss -lunp | grep 1194
ss -ltnp | grep 1194

Директива local прибивает слушателя к одному адресу, поэтому клиент, нацеленный в другое место на том же хосте, получает отказ, тогда как служба снаружи всё ещё выглядит здоровой. Имя экземпляра тоже может указывать на файл, который вы никогда не правили, что бывает на хостах с двумя профилями рядом.

Перехватите внешний пакет, а не туннель

Фильтруйте на физическом интерфейсе и настоящем порту, подставив свой интерфейс: tcpdump -ni eth0 udp port 1194. Исходящие пакеты, на которые ничего не возвращается, указывают на то, что выше: фильтрация провайдера, устройство NAT или удалённый адрес, который не тот, что вы думаете. Тишина в обе стороны указывает на маршрутизацию клиента или локальный межсетевой экран. Ответы, приходящие без продвижения туннеля, указывают на канал управления, то есть на несовпадение ключа или шифра, а не на фильтрацию.

Перехватите оба направления и держите файл коротким. Долгий перехват хоронит интересные три секунды, и ответ почти всегда в первом обмене.

Сначала счётчики, трассировка только когда они лгут

Начните со счётчиков, потому что они ничего не стоят. Либо nft list ruleset, либо iptables -L -n -v отвечает на единственный важный здесь вопрос: совпало ли правило? Порядок решает исход, потому что первое совпадение побеждает, поэтому широкий DROP перед более поздним ACCEPT оставляет этот ACCEPT мёртвым и поэтому добавление правила так редко что-то исправляет.

Принадлежность тоже сбивает людей с толку. Ядро приписывает локально созданные пакеты процессу, который открыл сокет, а OpenVPN обычно работает как root, поэтому правило, привязанное к обычному ID пользователя, никогда не видит трафик самого туннеля. Проверьте UID владельца, прежде чем решить, что правило неверно.

Только когда счётчики остаются неоднозначными, журнал стоит шума, и то лишь для узкого среза: правило iptables, которое ограничивает скорость и добавляет префикс к своим строкам, или правило nftables с meta nftrace set 1 при работающем nft monitor trace. Трассировка называет цепочку и правило, которое приняло или отбросило пакет. После этого уберите и то и другое и держите журналирование полезной нагрузки в стороне.

Проверьте и транспорт. Служба межсетевого экрана, ограниченная TCP, ничего не говорит о UDP-слушателе на этом номере, поэтому правильно прочитанное правило всё равно может отбрасывать каждый пакет.

Маршрутизация и обратный путь

Принятый пакет, который всё же исчезает, требует проверки пути к месту назначения. ip route get сообщает маршрут, выбранный для одного адреса, а фильтрация обратного пути может отбросить ответ, приходящий через интерфейс, который основная таблица никогда бы не выбрала. Симптом выглядит точно как отбрасывание межсетевым экраном, поэтому эта проверка идёт перед очередным правилом NAT.

На шлюзе проверяйте пересылку и цепочку forward, а не цепочку input. Затем убедитесь, что удалённая сторона знает, как достичь адреса источника, ведь работающий исходящий путь без ничего в ответ это тишина в обоих случаях.

Что должна сказать запись

Для каждого изменения записывайте проверенный этап, прочитанное доказательство и значение счётчика с обеих сторон. Именно эта запись делает "сейчас работает" живучим на следующем обзоре.

Два сокращения держат запись честной. Пакет, который никогда не покидал хост, не мог быть отброшен правилом где-то ещё, как бы убедительно ни выглядела конфигурация удалённой стороны. Пакет, который ушёл и вернулся, переносит вопрос выше сетевого уровня, где счётчикам межсетевого экрана уже нечего вам сказать.