Чому ваш VPN-сенсор ніколи не бачить VLAN-мітку філії

Сенсор на боці VPN бачить дві VLAN філій як звичайний IP-трафік, а мітка, яка ідентифікувала кожну філію на її власному дроті, зникла. Саме це робить маршрутизований тунель: він відновлює пакети, а не кадри Ethernet, які їх доставили. Чи має значення відсутня мітка, повністю залежить від питання, яке ви ставите сенсору. Виконайте чотири перевірки нижче по порядку, і ви знатимете, яка точка спостереження може на нього відповісти.

По-перше: визначте, що відновлює ваш тунель

Інтерфейс TUN передає IP-пакети, тому заголовок VLAN кадру філії зупиняється на маршрутизаторі, який заштовхнув трафік у тунель. Інтерфейс TAP передає кадри Ethernet, а це означає, що мітки можуть зберігатися, коли міст і правила допуску VLAN їх пропускають. Прочитайте тип інтерфейсу, перш ніж міркувати, що має містити запис.

Жоден із варіантів не є дефектом. Два проєкти відповідають на різні питання і залишають мітку в різних місцях.

Перевірте інтерфейс самі, а не робіть висновок із назви продукту. Відомості про з’єднання називають тип пристрою і показують чинні прапорці, а запис, зроблений на пристрої TUN, не отримає заголовка Ethernet лише тому, що ви про нього попросили. Якщо мітки все ж з’являться в записі TUN, ви майже напевно читаєте інший інтерфейс або тунель, який несе кадри всередині свого корисного навантаження. Перш ніж продовжувати, позначте, який це випадок.

По-друге: поставте сенсор там, де об’єкт ще існує

Три позиції охоплюють більшість маршрутизованих проєктів: сегмент Ethernet філії, зовнішня мережа між кінцями тунелю і шлях після обробки тунелю. Кожна бачить свій об’єкт, і мітка існує лише в першій. Вибір позиції сенсора — це рішення про те, який об’єкт потрібен політиці, а не питання зручності.

Сформулюйте питання політики в термінах, на які таблиця може відповісти, і воно зазвичай вирішується саме. Якщо правилу потрібно знати, з якої філії прийшов пакет, зіставлення префіксів нижче може бути достатнім, але лише поки це зіставлення точне й однозначне. Якщо правилу потрібно знати, на який порт прийшов кадр, потрібна перша позиція, бо ніщо нижче не може це відтворити. Сенсори, розміщені за звичкою, а не за питанням, — причина, чому команди зрештою вимагають поле, якого проєкт ніколи не ніс.

Тунель, що несе Ethernet, — інший проєкт, і йому потрібна власна перевірка того, що кінці зберігають або переписують. Вибір лише TAP і досі не визначає міст, правила допуску VLAN чи політику інспекції.

По-третє: заслужіть контекст джерела, а не довіряйте йому

Один діапазон адрес на філію — звична заміна ідентичності VLAN, і він діє лише поки зіставлення залишається один до одного. Перекриті префікси, трансляція та спільний шлюз кожен по-своєму ламають це припущення так, що це виглядає проблемою якості даних, а не проєкту. Запишіть зіставлення з його межами і скажіть, що відбувається з пакетом, який збігається з двома рядками. Префікс, що з’являється у двох філіях, має бути помилкою, яку ви виявляєте, а не кидком монети, який ви приймаєте.

Контекст, наданий клієнтом, не є доказом членства. Це твердження, і його місце в іншому стовпці.

Там, де відмінність важлива, використовуйте дані зв’язку, які ви контролюєте: який примірник тунелю прийняв з’єднання, на який інтерфейс прийшли пакети, що каже локальна таблиця маршрутів про того партнера. Мітка, надана клієнтом, — корисна підказка і марний вхід для авторизації. Якщо сенсор не може встановити зв’язок зі свого боку, політиці потрібне ширше правило, а не впевнене припущення.

По-четверте: підтвердьте шлях відповіді й те, що пропускає розшифрування

Сенсор, що бачить лише один напрямок, усе ще може виглядати здоровим, бо запити продовжують надходити за розкладом. Перевірте шлях відповіді явно і перевірте його для того самого потоку, а не для загальної доступності. Напівдуплексна видимість стає тихою прогалиною в кожному висновку з урахуванням стану, який ви з неї робите.

Відновлення внутрішнього IP-трафіку — це теж не те саме, що бачити застосунок усередині нього, бо TLS, який переноситься тунелем, залишається TLS.

ip -d link show tun0
tcpdump -i tun0 -n -e -c 5

Ці дві команди відповідають на питання про інтерфейс і показують, що насправді містить запис, і це швидше, ніж сперечатися про архітектуру. Підставте назву інтерфейсу, яку використовує ваш проєкт, і запустіть запис, поки потрібний вам потік активний. Коли на пристрої TUN не з’являється жодної мітки, висновок полягає в тому, що проєкт маршрутизував, а не мостив, а не в тому, що сенсор втратив дані. Потім або перемістіть сенсор у позицію, яка бачить мітку, або перепишіть правило в термінах, які може підтримати поточна позиція.