Трафик на eth0 не означает, что туннель VPN протекает
Публичные адреса на физическом адаптере обычно и есть собственная оболочка туннеля. Сравните интерфейсы, а затем спросите у ядра, какое устройство оно выбирает.
Видеть публичные адреса на eth0, пока туннель поднят, кажется доказательством того, что что-то утекло. Обычно всё наоборот: собственные пакеты туннеля должны пересечь этот адаптер, чтобы дойти до сервера, и они выглядят как обычные потоки UDP или TCP. Внутренний пакет появляется только на устройстве туннеля. Различить эти два случая — вопрос чтения оболочки, а не доверия к числу байтов.
Каждый пакет туннеля всё равно пересекает провод
Туннель — это интерфейс, а не провод. Клиент берёт внутренний пакет, заворачивает его и отправляет результат на адрес и порт сервера из профиля. На физическом адаптере вы видите обёртку; на устройстве туннеля вы видите то, что было завёрнуто.
В режиме UDP внешний поток — это одна пара адреса и порта в каждом направлении, поэтому здоровый туннель выглядит на eth0 почти скучно. Именно эту единственную пару и нужно искать в первую очередь.
Захватывайте по одному интерфейсу за раз
Захватывайте по одному интерфейсу за раз, если собираетесь сравнивать счётчики. Псевдоинтерфейс any собирает все устройства сразу, поэтому пересланный пакет появляется на входе и выходе, а локально созданный — дважды в двух разных видах. Равные числа пакетов при неравных числах байтов нормальны, ведь обёртка больше того, что она несёт. ARP, DHCP и объявления маршрутизатора IPv6 относятся к локальному каналу и ничего не говорят о вашем приложении.
sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194Замените адрес и порт значениями из самого профиля. Если этот поток стабилен, туннель что-то несёт.
Спросите у ядра, какое устройство оно выберет
Спросите у ядра, какое устройство оно выбрало бы, а затем подтвердите на проводе. Поиск маршрута — это решение, а захват — доказательство того, что решению последовали. Они отвечают на разные вопросы, и вам нужны оба.
ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111Разделённый результат — обычная находка: IPv4 идёт в туннель, а IPv6 идёт на физический адаптер, потому что профиль протолкнул только маршруты IPv4. Это настоящая утечка, и она невидима в захвате только по IPv4. Отфильтруйте IPv6 и следите за адресами, которые не являются сервером и не являются link-local.
Выполните оба поиска до подключения и после него, чтобы увидеть, что клиент действительно изменил. Разница между двумя запусками и есть реальный эффект клиента.
Когда захват действительно является утечкой
Иногда захват говорит правду. Более узкий маршрут, который отправляет один префикс в обход туннеля, подсеть, которую клиенту велели исключить, или разрешающее правило брандмауэра, срабатывающее до политики туннеля, всё это может вывести трафик на провод открытым. Правило, совпадающее с группой процессов, тоже может быть намеренным исключением. Прочитайте его интерфейс и область назначения, прежде чем называть это дефектом.
Исправьте маршрут или исключение, а не брандмауэр. Затем снова захватите из нового соединения и проверьте IPv4 и IPv6 по отдельности, ведь исправление одного ничего не говорит о другом. руководство по tcpdump описывает селекторы интерфейса и направления, использованные выше.