Почему захват в маршрутизируемом VPN никогда не показывает VLAN-тег филиала

Захваты, сделанные на интерфейсе туннеля, никогда не покажут VLAN ID филиала, и это свойство архитектуры, а не пробел в инструменте. Маршрутизируемый туннель TUN передаёт IP-пакеты, поэтому помеченный кадр Ethernet, который нёс их на линии филиала, заканчивается на маршрутизаторе, который их маршрутизировал. Если вопрос вашей политики касается сегментов, позицию сенсора нужно выбрать для этого вопроса до начала захвата. Поле VLAN, которого вы ожидали, должно быть заменено контекстом, который вы можете защитить.

Посмотрите, что на самом деле передаёт интерфейс туннеля

TUN доставляет IP-пакеты хосту; TAP доставляет кадры Ethernet. Маршрутизируемая схема использует первое, а значит, у пакета, приходящего после расшифровки, вообще нет заголовка канального уровня, и поэтому нет тега 802.1Q для чтения. В пути ничего не снималось, потому что тег никогда не попадал в туннель. Внутренний пакет начинается со своего IP-заголовка, поэтому каждое поле, которого ожидает правило с учётом VLAN, просто отсутствует.

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

ip -d link show tun0
tcpdump -i tun0 -nn -e -c 20

Первая команда печатает тип устройства и его флаги. Вторая печатает заголовки канального уровня для первых двадцати пакетов, и на устройстве TUN вывод начинается с IP без блока Ethernet, что и есть всё объяснение на одном экране.

Выбор TAP тоже не восстанавливает тег. Устройство TAP передаёт кадры мосту, и то, что происходит с тегом, зависит от VLAN-фильтрации моста и настроенного членства порта. Это отдельное проектное решение со своими режимами отказа.

Встаньте в одном из трёх мест и примите то, что оно может видеть

На сегменте Ethernet филиала тег присутствует, но сенсор видит только локальный трафик на этом сегменте. Во внешней сети VPN трафик защищён, поэтому наблюдатель узнаёт конечные точки и объём и ничего о внутреннем пакете. На пути TUN после расшифровки внутренний IP-пакет доступен вместе с его адресацией и портами и без кадра филиала. Поэтому захват на транке и маршрутизируемый захват одного и того же потока выглядят как два разных разговора.

Эти три позиции отвечают на три разных вопроса, и один захват не может быть всеми сразу.

tcpdump -i eth0 -nn -e 'vlan' -c 10
tcpdump -i tun0 -nn -c 10

Запустите пару и сравните. Первая показывает помеченные кадры и их VLAN ID там, где линия филиала подключена транком к хосту; вторая показывает тот же разговор как обычный IP после маршрутизации. Если первая вообще ничего не вернёт, проверьте, является ли порт хоста портом доступа, потому что тогда тег уже удалён коммутатором и никакой захват на хосте его никогда не покажет.

Замените отсутствующий тег сопоставлением, которое вы можете защитить

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

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

ip route get 10.20.30.40
ip -br addr show

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

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

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

Восстановление внутреннего IP-пакета также не расшифровывает сеанс HTTPS внутри него. Если вопрос политики касается содержимого, а не потоков, позицию сенсора нужно снова сдвинуть, и это решение относится к тому же проектному документу.

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