Где смотреть трафик клиента OpenVPN на шлюзе

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

Определите, какую схему вы видите

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

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

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

Сначала привяжите адрес к сеансу

Начните с состояния сеансов сервера и определите текущий внутренний адрес клиента. Адреса из пула переиспользуются, поэтому адрес сам по себе — это аренда, а не человек.

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

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

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

Читайте таблицу потоков на маршрутизирующем шлюзе

Когда адрес и интервал установлены, список отслеживаемых соединений только для чтения показывает, что шлюз пересылает для него. Фильтруйте по исходному источнику, чтобы не читать всю таблицу.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Каждая запись содержит два кортежа, исходный и ответный, которые являются двумя направлениями одного потока, а не двумя приложениями. На пути с трансляцией источника исходный кортеж сохраняет адрес туннеля, а сторона ответа показывает транслированный адрес шлюза, и именно поэтому вывод на первый взгляд выглядит неверным.

Относитесь к списку как к живому состоянию, а не как к истории. Короткие потоки могли уже истечь, неотслеживаемый трафик никогда не появляется, а другое сетевое пространство имён показывает другую таблицу. Справочник по conntrack описывает фильтры и двунаправленный вывод.

Один ограниченный перехват для подтверждения прочитанного

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

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

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

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

Логи прокси и границы увиденного

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

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

Наконец, будьте точны в отношении охвата. Адрес назначения и порт — это метаданные, а не URL и не содержимое страницы, потому что внутренний сеанс HTTPS сохраняет свою собственную защиту независимо от туннеля. Сообщайте, что вы наблюдали, из какой точки наблюдения и в какое время.