Налаштування VLAN у Linux: де ламається сегментація
Поки всі сервери стоять в одній плоскій мережі, будь-який збій у ній стає спільним: широкомовний домен один, і лавина службових кадрів від однієї несправної машини доходить до всіх.
Раніше це лікували фізичним розділенням комутаторів, тепер той самий результат дає налаштування VLAN у Linux — межі сегментів описуються конфігурацією, а не закупівлею заліза.
Ціна плоскої мережі проявляється не в мирні дні, а в інциденті. Заражений або просто помилково налаштований вузол бачить сусідів напряму й може перебирати їхні сервіси без жодного бар’єра — ізоляції трафіку немає ні на рівні адресації, ні на рівні доступу.
Той самий вузол, що почав розсилати широкомовні запити, з’їдає смугу в усієї стійки, і деградують сервіси, які до збою не мають відношення.
Сегментація мережі серверів ділить контур на керовані широкомовні домени: база даних, прикладний шар, службовий трафік і адміністрування живуть окремо, а перехід між ними можливий лише через явно описані правила.
На хості це робиться тегуванням кадрів на інтерфейсі та мостами для віртуальних машин — один лінк до комутатора несе кілька сегментів, а ядро вирішує, що куди віднести.
Ламається це зазвичай на стику: тег не знімається там, де потрібно, сегмент управління виявляється доступним із прикладного, а частина віртуальних машин залишається без мітки й потрапляє в сегмент за замовчуванням. Така помилка не видна в тестах — вона видна в момент відмови. Нижче розбираємо, де саме втрачається сегментація і як її закривати конфігурацією.
Що дає сегментація трафіку: ефект у цифрах
Сегментація трафіку прибирає цілий клас відмов. У плоскій мережі аварійний потік від одного вузла розходиться по всіх портах, і падіння одного навантаження тягне за собою сусідів — у момент збою ураженими виявляються майже всі сервіси. Після розділення на VLAN зона ураження обмежена сегментом, а решта контурів продовжують працювати.
Час локалізації збою скорочується за рахунок звуження області пошуку, а не швидкості реакції. Діагностика починається з межі сегмента: лічильники помилок і скидів на магістральному порту, таблиця адрес, маршрути між сегментами.
Питання «де проблема» перетворюється на «у якому сегменті», і розбір укладається в хвилини замість годин суцільного перебору вузлів.
Ізоляція середовищ дає передбачуваність. Тестовий контур, навантажувальні прогони й міграції більше не ділять смугу з продуктивними сервісами — трафік стендів не покидає свій сегмент, і сплеск на одному з них не відбивається на інших.
Відмовостійкість мережі тримається на прив’язці сегмента до агрегованого каналу: у разі відмови одного фізичного лінка трафік переїжджає на другий без переналаштування адресації.
Зв’язки між сегментами описуються явними правилами — дозволені шляхи є, решту відкидається й логується, тому зниження ризиків тут вимірне: видно, хто й куди ходить.
У Linux схема збирається штатними засобами ядра: vlan-aware bridge та агрегація інтерфейсів описуються декларативно, конфігурація зберігається в репозиторії й розгортається відтворювано. Нове середовище додається як окремий сегмент, а не як ще один вузол у спільній мережі.
Режими VLAN: порти доступу, транк і маршрутизація
Режим порту на комутаторі визначає, чи йде кадр з тегом або без і скільки сегментів він несе. Порти доступу віддають нетегований трафік строго в один сегмент — так підключають сервери й гостьові системи, які про тегування кадрів нічого не знають.
Транк між комутаторами та аплінк гіпервізора передає по одному лінку тегований трафік відразу кількох сегментів.
Між сегментами обмін сам не з’явиться: його потрібно маршрутизувати — на L3-комутаторі або окремому вузлі, де правила обміну задаються явно. Без цього сегменти залишаться ізольованими, а службовий обмін — резервне копіювання, оновлення, моніторинг — доведеться збирати вручну.
Варіанти організації
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Порти доступу | сервери й системи всередині одного сегмента | один сегмент на порт; переведення в інший сегмент — це правка конфігурації порту |
| Транк із тегуванням | магістраль між комутаторами, аплінк гіпервізора із системами в різних сегментах | режим і список тегів узгоджують на обох кінцях; нетегований сегмент за замовчуванням — часте джерело витоків |
| Гібридний порт | один пристрій віддає частину трафіку з тегами, частину без | неочевидна логіка, збій діагностується довше |
| Маршрутизація між сегментами | потрібен контрольований обмін між сегментами | потрібен L3-комутатор або маршрутизатор, правила обміну потрібно вести й перевіряти |
На практиці режим вибирають під задачу: доступ — для кінцевих систем, транк — для магістралей і віртуалізації, маршрутизація — там, де обмін між сегментами потрібен, але має бути обмежений правилами.
Як проходить впровадження сегментації: етапи робіт
Впровадження сегментації починається не з правки конфігурацій, а з інвентаризації того, що вже працює. Спочатку потрібно зрозуміти, які сервіси обмінюються трафіком постійно, які звернення одиничні, а які взагалі не повинні проходити.
Без цієї картини будь-яке розділення на підмережі ламає працюючі зв’язки, і відкат займає більше часу, ніж сам проєкт.
Порядок робіт виглядає так:
- Аудит мережі. Збираємо інвентар комутаторів, гіпервізорів, фізичних інтерфейсів і поточних підмереж. Окремо фіксуємо карту зв’язків між сервісами та зовнішніми споживачами — вона стане основою для правил.
- Схема адресації. Закріплюємо за кожним сегментом свою підмережу, імена інтерфейсів і маршрутизацію між ними. Тут же вирішуємо, які сервіси залишаються в спільному сегменті й чому.
- Проєктування схеми VLAN. Розмічаємо порти під тегований і нетегований трафік, узгоджуємо розмітку з віртуалізацією, щоб правила однаково працювали і на фізичних вузлах, і на віртуальних.
- Складання на тестовому контурі. Переносимо одну групу сервісів, перевіряємо маршрутизацію та поведінку в разі відмови окремого сегмента.
- Перевірка ізоляції. Скануємо з кожного сегмента: заборонені зв’язки не проходять, дозволені відповідають. Фіксуємо результат як еталон перед перенесенням бойових сервісів.
- Поетапне перенесення. Переводимо робочі сервіси групами, з вікнами обслуговування та планом відкату на кожному кроці.
- Передавання в експлуатацію. Віддаємо схему адресації, конфігурації, регламент підключення нових вузлів та інструкцію з відновлення — щоб зміни далі вносила ваша команда.
Фінальний крок — контрольний прогін перевірок ізоляції на бойовому контурі через кілька днів після перенесення: він показує, чи не з’явилося обхідних зв’язків, які зазвичай спливають уже в роботі.
Схеми адресації, конфігурації та регламенти доступу
Сегментація на VLAN живе довше, ніж інженер, який її налаштовував. Тому результат робіт ми фіксуємо в артефактах, за якими мережу можна розвивати й відновлювати без автора: новий адміністратор розбирається в топології за день, а не за тиждень читання робочих конфігурацій.
- Конфігурації комутаторів — вивантаження фактичних налаштувань цілком, а не лише змінених рядків: порти, теги, транкові та абонентські інтерфейси.
- Карта мережі — схема в редагованому вихіднику: які сегменти існують, що до них входить, де сходяться маршрути.
- Матриця доступів — таблиця «сегмент → ресурс → дозволено або закрито», з якої видно призначення кожного правила.
- Схема адресації — плани підмереж, шлюзи, діапазони та блоки, зарезервовані під зростання.
- Регламент змін — хто погоджує правку, де лежить еталон конфігурації, як виконується повернення до попереднього стану.
- Документація по мережі — опис логіки: чому межі сегментів проведені саме так і які правила залишені навмисно вузькими.
- Порядок перевірки — контрольний список дій після правки й точка повернення, до якої можна відкотитися.
Конфігурації зберігаються з історією правок, тому будь-яку зміну можна порівняти з попередньою та скасувати. Раз на квартал ми звіряємо карту й матрицю доступів з фактичним станом комутаторів: розбіжності усуваються раніше, ніж стають причиною збою.
Кейс: розділення парку серверів без зупинки сервісів
До: одна плоска мережа на весь парк
До нас прийшов замовник із парком близько 120 серверів на трьох майданчиках, об’єднаних в одну плоску мережу. Кожен вузол бачив усіх інших: тестовий стенд міг зайняти адресу бойового сервісу, а збійна мережева карта одного сервера генерувала широкомовний шторм на весь парк.
Пошук джерела проблеми займав години, бо трафік нічим не був обмежений, і вимкнути підозрілий вузол можна було лише наосліп.
Що змінили
Розбили парк на сегменти за призначенням: управління, бойовий контур, база даних, тестові стенди, робоче середовище розробки. Між сегментами залишили лише явно дозволені потоки, решту відсікається на шлюзі.
Конфігурацію портів і міток тримаємо в репозиторії та застосовуємо через Ansible — зміна проходить перевірку до викочування, а не вноситься руками на комутаторі.
Після: показники
Широкомовний трафік у бойовому контурі скоротився приблизно в шість разів — мережеві карти й комутатори перестали розносити чужий шум. Пошук джерела проблеми займає тепер десятки хвилин замість годин: видно, з якого сегмента йде аномалія. Число конфліктів адрес упало до нуля, бо діапазони більше не перетинаються між стендами й боєм.
Міграцію провели без зупинки сервісів: переводили групи серверів по черзі, кожне перемикання — зі швидким відкатом на попередню схему. Новий сегмент піднімається правкою в репозиторії й займає хвилини, а не погодженням змін на живому обладнанні.
Чим відрізняється тегування від фізичного розділення мереж?
Фізичне розділення мереж означає окремий порт комутатора, кабель і мережевий адаптер під кожен сегмент.
Відмова одного контуру не зачіпає решту, поведінка передбачувана й не залежить від конфігурації сусідів, зате кожен новий сегмент потребує заліза й монтажу — вартість володіння мережею зростає лінійно разом з їхньою кількістю.
Тегування трафіку переносить ізоляцію сегментів усередину кадру: комутатор і ядро позначають пакет ідентифікатором VLAN, а приймальна сторона розкладає його в окремий віртуальний інтерфейс.
Один фізичний канал несе трафік десятків мереж, і новий сегмент заводиться правкою конфігурації, а не прокладанням кабелю.
Гнучкість схеми — головна відмінність. У разі фізичного розділення перенесення сегмента між стійками означає перекомутацію, у разі тегування — зміну тегу на порту й оновлення профілю інтерфейсу.
Зворотний бік: сегменти ділять спільний транспорт, тому помилка на магістральному порту відкриває відразу всі мережі, а розбір збою потребує читання таблиць комутації, а не продзвонювання кабелю.
Тому на практиці обидва підходи комбінують.
Фізично розносять контури з різним рівнем довіри, наприклад управління та публічні сервіси, а всередині контуру роблять налаштування VLAN у Linux: віртуальні інтерфейси поверх спільного каналу, окремі таблиці маршрутизації та правила фільтрації між ними.
Гібрид дає передбачувану межу відмов і гнучкість усередині периметра — вибирати між схемами варто за кількістю сегментів і потрібною частотою їхніх змін, а не за звичкою.
Сумніви щодо сумісності, петель і відкату змін
Сумісність рідко стає стоп-фактором: тегування кадрів підтримує практично будь-який керований комутатор актуальної гілки, а вузьке місце зазвичай у некерованих моделях на периферії.
Їх не обов’язково міняти — така ділянка залишається всередині одного сегмента, а розмежування доступу робиться на боці хостів засобами операційної системи.
Перед роботами ми звіряємо матрицю портів і режими транкових лінків з поточною схемою, щоб не переводити в тегування те, що фізично до цього не готове.
Зміни в мережі робимо поетапно, зі збереженням резервного шляху: поки новий сегмент не перевірено, трафік продовжує йти за попереднім маршрутом, і перемикання відбувається після контрольних перевірок.
Конфігурації перед правкою знімаються й зберігаються окремо, тому повернення до вихідного стану — це застосування заздалегідь підготовленого набору, а не відновлення з пам’яті.
Що буде, якщо частина обладнання не підтримує тегування?
Ми не переводимо таку ділянку в загальний транк насильно. Він або залишається в окремому сегменті зі своєю адресацією, або розмежування переноситься на рівень хостів і правил фільтрації.
У звіті ви отримуєте карту: що вже готово до сегментації, а що стане наступним кроком при плановій заміні.
Як ви страхуєтеся від мережевих петель?
Петля виникає там, де з’являється другий шлях між комутаторами без узгодженого кістякового дерева. Тому спочатку знімаємо топологію, явно призначаємо кореневий комутатор і перевіряємо, що резервні лінки переходять у блокування, а не в активний обмін. На керованих портах додатково вмикаємо захист від повторного підключення того самого сегмента.
Чи можна повернути попередню схему, якщо щось піде не так?
Так, відкат планується до початку робіт. Знімаємо конфігурації, фіксуємо порядок зворотних дій і тримаємо попередній шлях передавання трафіку робочим до підтвердження результату.
Якщо перевірки на новому сегменті не проходять, повернення займає хвилини й не потребує повторного проєктування мережі.
Обговоримо вашу схему сегментації — повернемося з планом
Універсальної схеми сегментації не існує: вона залежить від того, які інтерфейси вже зайняті, де проходить маршрутизація між сегментами й як влаштована адресація.
Щоб оцінка робіт була точною, а не приблизною вилкою, ми розбираємо вашу поточну конфігурацію до початку налаштування VLAN на Linux-серверах. Опишіть задачу словами — до опису додайте те, що вже є в інфраструктурі.
- загальна схема мережі: комутатори, гіпервізори, фізичні сервери та точки маршрутизації між сегментами;
- вивантаження конфігурацій інтерфейсів і таблиць маршрутизації — текстом або експортом із системи управління;
- поточний поділ за VLAN: номери, призначення, підмережі та шлюзи на кожному;
- схема адресації та розв’язання імен: хто видає адреси, де ведуться записи;
- вимоги до ізоляції: які сервіси зобов’язані бачити одне одного, які — не повинні в принципі;
- вікна обслуговування та порядок погодження змін, наявність резервних каналів;
- обмеження: обладнання, яке не можна переналаштовувати, зовнішні підрядники, вимоги аудиту.
У відповідь ви отримуєте план впровадження з етапами, порядком перемикань і точками відкату на кожному кроці, а також терміни робіт, прив’язані до ваших вікон обслуговування.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом.
