Чи потрібні двом майданчикам однакові VLAN ID для VPN між майданчиками?

Однакові номери VLAN у двох офісах виглядають так, ніби мають допомогти тунелю між майданчиками, і вони нічого не змінюють у тому, що тунель передає. VLAN ID позначає широкомовний домен Ethernet усередині однієї будівлі; тунель пересилає 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 на обох кінцях іноді випадковість спільного шаблону, і ставлення до цієї випадковості як до причини працюючого тунелю веде до неправильної зміни, коли щось згодом ламається.

Одне завдання на рівень, записане

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

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

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

Підтвердьте локальну картину інструментами bridge, перш ніж припускати, що тег доходить до тунелю.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Коли розширення layer-2 — це справжня вимога

Деякі проєкти справді потребують поведінки Ethernet між майданчиками: застарілий застосунок, що покладається на широкомовне виявлення, міграція, за якої адреса має зберегтися, поки машина переміщується, або протокол, що вбудовує припущення layer-2. Такі випадки вимагають overlay або мостової служби, що переносить кадри, і тоді членство у VLAN, запобігання петлям і обробка відмов стають наскрізними питаннями.

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

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