Де спостерігати трафік клієнта 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 зберігає власний захист незалежно від тунелю. Повідомляйте, що ви спостерігали, з якої точки спостереження і в який час.