Трябват ли на два обекта еднакви VLAN ID за VPN между обекти?

Еднаквите VLAN номера в два офиса изглеждат така, сякаш би трябвало да помогнат на тунел между обекти, а не променят нищо от това, което тунелът пренася. VLAN ID маркира Ethernet домейн за broadcast в една сграда; тунелът препредава IP пакети между шлюзовете. Два обекта могат да използват напълно различна VLAN номерация и пак да маршрутизират един към друг, а два обекта могат да използват еднаква VLAN номерация и пак да не могат да се достигнат. Променливата, която решава достъпността, е планът на адресите.

Митът: еднакви VLAN ID в двата края

Вярата идва от разумно място. В една сграда два порта в един и същ VLAN могат да си говорят, а два порта в различни VLAN не могат, затова VLAN номерът изглежда като нещото, което дава свързаност. През маршрутизиран тунел няма споделен Ethernet сегмент, който тагът да опише, и шлюзовете никога не разменят VLAN тагове.

На тунела са нужни два адресни обхвата, които не се припокриват, и политика, която разрешава трафика между тях. Сменете VLAN в който и да е офис и тунелът продължава да работи, защото нищо в конфигурацията на тунела не го е реферирало. Това е тестът, който решава спора: преномерирайте VLAN, оставете адресите непокътнати и наблюдавайте дали тунелът остава активен.

Обратният тест е също толкова показателен. Дайте на двата офиса една и съща подмрежа и никакво количество еднакви VLAN номера няма да направи адреса еднозначен.

Какво всъщност пренася тунелът

IPsec защитава IP пакетите според политика, изразена в адреси, протоколи и портове. Архитектурата на IPsec описва тези селектори на IP слоя, който е няколко слоя над всичко, което описва един суич таг. Когато пакет влезе в тунела, той вече е напуснал VLAN; тагът е изразходван от локалния суич.

Дизайните, базирани на политика и на маршрути, се различават по това как избират тунела, а не по това какво могат да пренасят. Пир, базиран на политика, съпоставя селекторите на трафика и изпраща съвпадащите пакети в тунела. Пир, базиран на маршрути, маршрутизира трафика на тунелен интерфейс и оставя таблицата за маршрутизация да реши. И двата все още договарят обхват на защита, затова маршрут, който сочи към тунела, не разширява това, което пировете са се съгласили да защитават.

Това разграничение обяснява често срещан половин провал: маршрутът съществува, пакетите влизат в тунела, а далечната страна ги изхвърля, защото договорените селектори никога не са включвали този префикс. Четенето на инсталираните политики показва кой обхват всъщност е влязъл в сила.

ip xfrm policy
ip route show
swanctl --list-sas

Припокриването, което наистина чупи

Два офиса с различни подмрежи се маршрутизират чисто през тунел и VLAN номерата им са без значение. Два офиса с една и съща подмрежа не, защото заявка за даден адрес има две възможни значения и таблицата за маршрутизация може да избере само едно. Преномерирането на един обект е чистото решение и обикновено е по-евтино от алтернативите, след като се отчетат промените в DNS и защитната стена.

Когато преномерирането е невъзможно, умишлен дизайн на транслация може да представи различни изгледи на адресите на всяка страна. Това означава съпоставяне едно към едно, съвпадащи селектори, DNS записи, които отразяват транслирания изглед, и обратна маршрутизация, която оцелява след пренаписването. Това е поддържан дизайн с реална оперативна цена и не е това, което прави смяната на VLAN ID.

Еднаквите VLAN номера в двата края понякога са съвпадение от споделен шаблон и третирането на това съвпадение като причина за работещ тунел води до грешната промяна, когато нещо по-късно се счупи.

Една задача на слой, записана

Локалният суич решава кои портове споделят домейн за broadcast и неговата VLAN номерация е локално счетоводство, което никой друг обект не трябва да знае. Шлюзът удостоверява пира и налага договорения обхват на защита. Таблицата за маршрутизация решава накъде отива дешифрираният пакет след това, а политиката за достъп решава дали този пакет е трябвало да бъде разрешен изобщо.

Разделянето на тези задачи е това, което прави промените безопасни. Преномериране на VLAN в един офис засяга локалния суич, DHCP обхвата и вероятно зона на защитната стена, и не засяга тунела. Промяна на префикс засяга селекторите на тунела, маршрутите от двете страни и политиката за достъп, и не засяга таговете на суича.

Обратните маршрути, частният DNS и изискванията за идентичност на приложенията са отново отделни задачи и нито една от тях не идва чрез копиране на VLAN номер от другия обект. Проектен документ, който изброява достижимите префикси и разрешените услуги, оцелява след подмяна на суич; такъв, който изброява VLAN номера, не.

Потвърдете локалната картина с bridge инструментите, преди да предположите, че тагът достига до тунела.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Когато разширяването на layer-2 е истинското изискване

Някои дизайни наистина се нуждаят от Ethernet поведение между обекти: наследено приложение, което разчита на broadcast откриване, миграция, която трябва да запази адрес, докато машина се мести, или протокол, който вгражда layer-2 предположения. Тези случаи изискват overlay или мостово обслужване, което пренася кадрите, и тогава членството във VLAN, предотвратяването на цикли и обработката на откази стават задачи от край до край.

Това е много по-голям домейн на откази и трябва да бъде съзнателен избор, а не случайният резултат от опит да се подкара споделяне на файлове. Обикновен файлов сървър, база данни или уеб приложение се нуждае от оторизиран IP път и ще е по-щастливо без разтегнат broadcast домейн под него.

Запишете VPN договора като достижими префикси плюс разрешени услуги и записвайте VLAN тага само там, където местните операции се нуждаят от него. Тогава всеки офис може да преномерира собствената си комутация, без да превръща всяка промяна в препроектиране на тунела.