Порт VPN молчит? Слушатель, адрес привязки или межсетевой экран хоста

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

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

Существует ли сокет вообще

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

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

Список сокетов — это факт, на котором держится остальная диагностика. Читайте столбец локального адреса, а не только порт, потому что именно в этом столбце видны привязки к loopback и привязки к неверному интерфейсу. Слушатель, существующий на 127.0.0.1, работает безупречно и всё равно невидим для вашего ноутбука.

На каком адресе и в каком семействе отвечает сокет

Две ошибки выглядят со стороны клиента одинаково и объясняют большинство сообщений «недоступно». Сервер, привязанный к адресу loopback, никогда не принимает трафик с другой машины, а сервер, привязанный только к адресу IPv4, никогда не отвечает клиенту, который набирает адрес IPv6 того же хоста. Сравните адрес в таблице сокетов с адресом, который клиент действительно набирает, символ за символом, прежде чем что-либо предполагать о политике.

Если ограничить список одним портом, он остаётся читаемым, когда хост запускает несколько служб. Фильтр sport берёт порт вместе с транспортом, который вы проверяете:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

Столбец протокола меняет весь ответ

Таблица сокетов индексируется и по протоколу, и по порту, и это две независимые записи. Служба, отвечающая по TCP на 1194, ничего не говорит о том, слушает ли что-нибудь UDP 1194, а клиент всегда будет использовать только один из них. Убедитесь, какой транспорт выбирает конфигурация сервера и какой отправляет профиль клиента, а затем ищите именно эту строку.

У UDP есть второй нюанс: неаутентифицированный зонд — не ошибка, на которую служба обязана отвечать. Сканирование, сообщающее, что порт молчит, измерило сдержанность службы, а не её доступность, поэтому проверяйте настоящим клиентом и профилем.

Одна попытка, три места, куда смотреть

С разрешённого клиента сделайте ровно одну попытку и запишите время с точностью до секунды. Затем прочитайте три источника за это окно: сетевое правило или консоль провайдера, счётчики или журнал межсетевого экрана хоста и собственный журнал службы. Однократное выполнение делает три свидетельства сравнимыми и стоит меньше, чем повтор попытки, время которой никто не записал.

Два исхода указывают в противоположные стороны. Если ни один пакет не дошёл до хоста, путь его отбрасывает, и слушатель неважен. Если пакет дошёл до сокета, а служба его отклонила, путь в порядке, и ответ лежит в протоколе, криптографии или учётных данных. Открытие порта для службы, которая уже приняла соединение, делает следующую диагностику сложнее, а не проще.

Назовите этап, прежде чем менять правило

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

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