Защо вашият 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 устройство не се появи таг, заключението е, че дизайнът е маршрутизирал вместо да мостове, а не че сензорът е изпуснал данни. След това или преместете сензора на позиция, която може да види тага, или препишете правилото в термини, които текущата позиция може да подкрепи.