Къде да наблюдаваме трафика на OpenVPN клиент на шлюза

Искате да знаете до кои дестинации достига свързан клиент, затова отваряте шел на VPN сървъра и пишете ss. Нищо полезно не се появява и изводът, че тунелът е счупен, идва малко прекалено лесно. Шлюзът OpenVPN с маршрутизация препраща пакетите на клиента; той не прекратява TCP връзките им и не притежава сокети за тях. Доказателството живее другаде и това къде зависи от начина, по който се обработва трафикът, след като напусне тунела.

Определете коя подредба виждате

Две обичайни форми дават напълно различни доказателства. Маршрутизиращият шлюз декапсулира, препраща и евентуално прави транслация на източника, така че връзката на клиента продължава да съществува от край до край без локален сокет.

Проксито прекратява трафика: приема връзката и след това отваря собствената си връзка нагоре. При тази подредба има две връзки за една заявка и връзката между тях съществува само в собствените записи на проксито. Знанието кое от двете сте внедрили определя дали трябва да четете състоянието на потоците в ядрото, или логовете на приложението.

Повечето объркване идва от догадки. Потвърдете формата, преди да изберете инструмента. Първо прочетете конфигурацията на сървъра за директива за прокси, защото наличието ѝ променя всяка следваща стъпка. Без нея пътят на пакетите е маршрутизация и състоянието на потоците в ядрото е вашето доказателство.

Първо свържете адреса със сесия

Започнете от състоянието на сесиите на сървъра и идентифицирайте текущия вътрешен адрес на клиента. Адресите от пула се преизползват, затова адресът сам по себе си е наем, а не човек.

Запишете времето и удостоверената самоличност заедно и отбележете дали цяла локална мрежа се крие зад този клиент. Ако отдалеченият край маршрутизира подмрежа, вътрешните адреси, които виждате, може да са оригинални хостове или транслатени.

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'

Сравнете времевите марки, протокола и портовете със записа на потока и със заявката, която направихте като тест. Захват, направен след транслация, показва само публичния адрес на шлюза, докато страната на тунела може все още да показва адреса на клиента и тази разлика е информация, а не несъответствие.

Ако интерфейсът не вижда нищо, проверете пътя на данните, преди да заключите, че клиентът е бездеен: трафикът клиент-към-клиент и някои пътища за разтоварване никога не минават през точката, която наблюдавате.

Логове на прокси и границите на това, което сте видели

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

Проверете конфигурацията за логване на внедрената версия, вместо да предполагате, че всяка заявка се логва по подразбиране.

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