Почему ваш VPN-сенсор никогда не видит VLAN-метку филиала
Маршрутизируемый туннель восстанавливает пакеты, а не кадры, которые их доставили. Четыре проверки: тип интерфейса, положение сенсора, контекст источника и путь ответа.
Сенсор на стороне VPN видит две VLAN филиалов как обычный IP-трафик, а метка, которая идентифицировала каждый филиал на его собственном проводе, исчезла. Именно это и делает маршрутизируемый туннель: он восстанавливает пакеты, а не кадры Ethernet, которые их доставили. Важна ли отсутствующая метка, полностью зависит от вопроса, который вы задаёте сенсору. Выполните четыре проверки ниже по порядку, и вы узнаете, какая точка наблюдения может на него ответить.
Во-первых: определите, что восстанавливает ваш туннель
Интерфейс TUN передаёт IP-пакеты, поэтому заголовок VLAN кадра филиала останавливается на маршрутизаторе, который затолкнул трафик в туннель. Интерфейс TAP передаёт кадры Ethernet, а значит, метки могут сохраняться, когда мост и правила допуска VLAN пропускают их. Прочитайте тип интерфейса, прежде чем рассуждать о том, что должна содержать запись.
Ни один из вариантов не является дефектом. Два проекта отвечают на разные вопросы и оставляют метку в разных местах.
Убедитесь в типе интерфейса сами, а не выводите его из названия продукта. Сведения о соединении называют тип устройства и показывают действующие флаги, а запись, сделанная на устройстве TUN, не обзаведётся заголовком Ethernet только потому, что вы о нём попросили. Если метки всё же появятся в записи TUN, вы почти наверняка читаете другой интерфейс или туннель, который несёт кадры внутри своей полезной нагрузки. Прежде чем продолжать, отметьте, какой это случай.
Во-вторых: поставьте сенсор туда, где объект ещё существует
Три позиции охватывают большинство маршрутизируемых проектов: сегмент Ethernet филиала, внешняя сеть между концами туннеля и путь после обработки туннеля. Каждая видит свой объект, и метка есть только в первой. Выбор позиции сенсора — это решение о том, какой объект нужен политике, а не вопрос удобства.
| Observation point | What is actually there | Question it can answer |
|---|---|---|
| Branch Ethernet segment | Tagged frames on the local wire | Which VLAN carried this frame here |
| Outer tunnel network | The protected carrier between endpoints | Which endpoints are exchanging traffic |
| After tunnel processing | Recovered IP packets | Which branch prefix the packet claims |
Сформулируйте вопрос политики в терминах, на которые таблица может ответить, и он обычно решается сам. Если правилу нужно знать, из какого филиала пришёл пакет, сопоставления префиксов ниже может хватить, но только пока это сопоставление точное и однозначное. Если правилу нужно знать, на какой порт пришёл кадр, нужна первая позиция, потому что ничто ниже не может это восстановить. Сенсоры, размещённые по привычке, а не по вопросу, — причина, по которой команды в итоге требуют поле, которого проект никогда не нёс.
Туннель, несущий Ethernet, — другой проект, и ему нужна собственная проверка того, что концы сохраняют или переписывают. Выбор одного лишь TAP по-прежнему не определяет мост, правила допуска VLAN или политику инспекции.
В-третьих: заслужите контекст источника, а не доверяйте ему
Один диапазон адресов на филиал — обычная замена идентичности VLAN, и он действует только пока сопоставление остаётся один к одному. Перекрывающиеся префиксы, трансляция и общий шлюз каждый по-своему ломают это допущение так, что это выглядит проблемой качества данных, а не проекта. Запишите сопоставление с его границами и скажите, что происходит с пакетом, который совпадает с двумя строками. Префикс, появляющийся в двух филиалах, должен быть ошибкой, которую вы обнаруживаете, а не броском монеты, который вы принимаете.
Контекст, предоставленный клиентом, не является доказательством членства. Это утверждение, и его место в другой колонке.
Там, где различие важно, используйте данные связи, которые вы контролируете: какой экземпляр туннеля принял соединение, на какой интерфейс пришли пакеты, что говорит локальная таблица маршрутов об этом партнёре. Метка, предоставленная клиентом, — полезная подсказка и бесполезный вход для авторизации. Если сенсор не может установить связь со своей стороны, политике нужно более широкое правило, а не уверенное предположение.
В-четвёртых: подтвердите путь ответа и то, что пропускает расшифровка
Сенсор, видящий только одно направление, всё ещё может выглядеть здоровым, потому что запросы продолжают приходить по расписанию. Проверьте путь ответа явно и проверьте его для того же потока, а не для общей доступности. Полудуплексная видимость становится тихим пробелом в любом выводе с учётом состояния, который вы из неё делаете.
Восстановление внутреннего IP-трафика — это тоже не то же самое, что видеть приложение внутри него, потому что TLS, переносимый через туннель, остаётся TLS.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5Эти две команды отвечают на вопрос об интерфейсе и показывают, что на самом деле содержит запись, и это быстрее, чем спорить об архитектуре. Подставьте имя интерфейса, которое использует ваш проект, и запустите запись, пока нужный вам поток активен. Когда на устройстве TUN не появляется ни одной метки, вывод состоит в том, что проект маршрутизировал, а не мостил, а не в том, что сенсор потерял данные. Затем либо переместите сенсор в позицию, которая видит метку, либо перепишите правило в терминах, которые может поддержать текущая позиция.