Настройка VLAN на серверах для сетевой сегментации

Настройка VLAN в Linux: где ломается сегментация

Пока все серверы стоят в одной плоской сети, любой сбой в ней становится общим: широковещательный домен один, и лавина служебных кадров от одной неисправной машины доходит до всех. Раньше это лечили физическим разделением коммутаторов, теперь тот же результат даёт настройка VLAN в Linux — границы сегментов описываются конфигурацией, а не закупкой железа.

Цена плоской сети проявляется не в мирные дни, а в инциденте. Заражённый или просто ошибочно настроенный узел видит соседей напрямую и может перебирать их сервисы без единого барьера — изоляции трафика нет ни на уровне адресации, ни на уровне доступа. Тот же узел, начавший рассылать широковещательные запросы, съедает полосу у всей стойки, и деградируют сервисы, к сбою отношения не имеющие.

Сегментация сети серверов делит контур на управляемые широковещательные домены: база данных, прикладной слой, служебный трафик и администрирование живут отдельно, а переход между ними возможен только через явно описанные правила. На хосте это делается тегированием кадров на интерфейсе и мостами для виртуальных машин — один линк до коммутатора несёт несколько сегментов, а ядро решает, что куда отнести.

Ломается это обычно на стыке: тег не снимается там, где нужно, сегмент управления оказывается доступен из прикладного, а часть виртуальных машин остаётся без метки и уходит в сегмент по умолчанию. Такая ошибка не видна в тестах — она видна в момент отказа. Ниже разбираем, где именно теряется сегментация и как её закрывать конфигурацией.

Что даёт сегментация трафика: эффект в цифрах

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

Время локализации сбоя сокращается за счёт сужения области поиска, а не скорости реакции. Диагностика начинается с границы сегмента: счётчики ошибок и сбросов на магистральном порту, таблица адресов, маршруты между сегментами. Вопрос «где проблема» превращается в «в каком сегменте», и разбор укладывается в минуты вместо часов сплошного перебора узлов.

Изоляция сред даёт предсказуемость. Тестовый контур, нагрузочные прогоны и миграции больше не делят полосу с продуктивными сервисами — трафик стендов не покидает свой сегмент, и всплеск на одном из них не отражается на остальных.

Отказоустойчивость сети держится на привязке сегмента к агрегированному каналу: при отказе одного физического линка трафик переезжает на второй без перенастройки адресации. Связи между сегментами описываются явными правилами — разрешённые пути есть, остальное отбрасывается и логируется, поэтому снижение рисков здесь измеримо: видно, кто и куда ходит.

В Linux схема собирается штатными средствами ядра: vlan-aware bridge и агрегация интерфейсов описываются декларативно, конфигурация хранится в репозитории и разворачивается воспроизводимо. Новая среда добавляется как отдельный сегмент, а не как ещё один узел в общей сети.

Режимы VLAN: порты доступа, транк и маршрутизация

Режим порта на коммутаторе определяет, уходит кадр с тегом или без и сколько сегментов он несёт. Порты доступа отдают нетегированный трафик строго в один сегмент — так подключают серверы и гостевые системы, которые о тегировании кадров ничего не знают. Транк между коммутаторами и аплинк гипервизора передаёт по одному линку тегированный трафик сразу нескольких сегментов.

Между сегментами обмен сам не появится: его нужно маршрутизировать — на L3-коммутаторе или отдельном узле, где правила обмена задаются явно. Без этого сегменты останутся изолированными, а служебный обмен — резервное копирование, обновления, мониторинг — придётся собирать вручную.

Варианты организации

На практике режим выбирают под задачу: доступ — для конечных систем, транк — для магистралей и виртуализации, маршрутизация — там, где обмен между сегментами нужен, но должен быть ограничен правилами.

Как проходит внедрение сегментации: этапы работ

Внедрение сегментации начинается не с правки конфигураций, а с инвентаризации того, что уже работает. Сначала нужно понять, какие сервисы обмениваются трафиком постоянно, какие обращения единичны, а какие вообще не должны проходить. Без этой картины любое разделение на подсети ломает работающие связи, и откат занимает больше времени, чем сам проект.

Порядок работ выглядит так:

1. Аудит сети. Собираем инвентарь коммутаторов, гипервизоров, физических интерфейсов и текущих подсетей. Отдельно фиксируем карту связей между сервисами и внешними потребителями — она станет основой для правил.
2. Схема адресации. Закрепляем за каждым сегментом свою подсеть, имена интерфейсов и маршрутизацию между ними. Здесь же решаем, какие сервисы остаются в общем сегменте и почему.
3. Проектирование схемы VLAN. Размечаем порты под тегированный и нетегированный трафик, согласуем разметку с виртуализацией, чтобы правила одинаково работали и на физических узлах, и на виртуальных.
4. Сборка на тестовом контуре. Переносим одну группу сервисов, проверяем маршрутизацию и поведение при отказе отдельного сегмента.
5. Проверка изоляции. Сканируем из каждого сегмента: запрещённые связи не проходят, разрешённые отвечают. Фиксируем результат как эталон перед переносом боевых сервисов.
6. Поэтапный перенос. Переводим рабочие сервисы группами, с окнами обслуживания и планом отката на каждом шаге.
7. Передача в эксплуатацию. Отдаём схему адресации, конфигурации, регламент подключения новых узлов и инструкцию по восстановлению — чтобы изменения дальше вносила ваша команда.

Финальный шаг — контрольный прогон проверок изоляции на боевом контуре через несколько дней после переноса: он показывает, не появилось ли обходных связей, которые обычно всплывают уже в работе.

Схемы адресации, конфигурации и регламенты доступа

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

• Конфигурации коммутаторов — выгрузки фактических настроек целиком, а не только изменённых строк: порты, теги, транковые и абонентские интерфейсы.
• Карта сети — схема в редактируемом исходнике: какие сегменты существуют, что в них входит, где сходятся маршруты.
• Матрица доступов — таблица «сегмент → ресурс → разрешено или закрыто», из которой видно назначение каждого правила.
• Схема адресации — планы подсетей, шлюзы, диапазоны и блоки, зарезервированные под рост.
• Регламент изменений — кто согласует правку, где лежит эталон конфигурации, как выполняется возврат к предыдущему состоянию.
• Документация по сети — описание логики: почему границы сегментов проведены именно так и какие правила оставлены намеренно узкими.
• Порядок проверки — контрольный список действий после правки и точка возврата, к которой можно откатиться.

Конфигурации хранятся с историей правок, поэтому любое изменение можно сравнить с предыдущим и отменить. Раз в квартал мы сверяем карту и матрицу доступов с фактическим состоянием коммутаторов: расхождения устраняются раньше, чем становятся причиной сбоя.

Кейс: разделение парка серверов без остановки сервисов

До: одна плоская сеть на весь парк

К нам пришёл заказчик с парком около 120 серверов на трёх площадках, объединённых в одну плоскую сеть. Каждый узел видел всех остальных: тестовый стенд мог занять адрес боевого сервиса, а сбойная сетевая карта одного сервера генерировала широковещательный шторм на весь парк. Поиск источника проблемы занимал часы, потому что трафик ничем не был ограничен, и отключить подозрительный узел можно было только вслепую.

Что изменили

Разбили парк на сегменты по назначению: управление, боевой контур, база данных, тестовые стенды, рабочая среда разработки. Между сегментами оставили только явно разрешённые потоки, остальное отсекается на шлюзе. Конфигурацию портов и меток держим в репозитории и применяем через Ansible — изменение проходит проверку до выката, а не вносится руками на коммутаторе.

После: показатели

Широковещательный трафик в боевом контуре сократился примерно в шесть раз — сетевые карты и коммутаторы перестали разносить чужой шум. Поиск источника проблемы занимает теперь десятки минут вместо часов: видно, из какого сегмента идёт аномалия. Число конфликтов адресов упало до нуля, потому что диапазоны больше не пересекаются между стендами и боем.

Миграцию провели без остановки сервисов: переводили группы серверов по очереди, каждое переключение — с быстрым откатом на прежнюю схему. Новый сегмент поднимается правкой в репозитории и занимает минуты, а не согласованием изменений на живом оборудовании.

Чем отличается тегирование от физического разделения сетей?

Физическое разделение сетей означает отдельный порт коммутатора, кабель и сетевой адаптер под каждый сегмент. Отказ одного контура не задевает остальные, поведение предсказуемо и не зависит от конфигурации соседей, зато каждый новый сегмент требует железа и монтажа — стоимость владения сетью растёт линейно вместе с их числом.

Тегирование трафика переносит изоляцию сегментов внутрь кадра: коммутатор и ядро помечают пакет идентификатором VLAN, а принимающая сторона раскладывает его в отдельный виртуальный интерфейс. Один физический канал несёт трафик десятков сетей, и новый сегмент заводится правкой конфигурации, а не прокладкой кабеля.

Гибкость схемы — главное отличие. При физическом разделении перенос сегмента между стойками означает перекоммутацию, при тегировании — смену тега на порту и обновление профиля интерфейса. Обратная сторона: сегменты делят общий транспорт, поэтому ошибка на магистральном порту открывает сразу все сети, а разбор сбоя требует чтения таблиц коммутации, а не прозвонки кабеля.

Поэтому на практике оба подхода комбинируют. Физически разносят контуры с разным уровнем доверия, например управление и публичные сервисы, а внутри контура делают настройку VLAN в Linux: виртуальные интерфейсы поверх общего канала, отдельные таблицы маршрутизации и правила фильтрации между ними. Гибрид даёт предсказуемую границу отказов и гибкость внутри периметра — выбирать между схемами стоит по числу сегментов и требуемой частоте их изменений, а не по привычке.

Сомнения по совместимости, петлям и откату изменений

Совместимость редко становится стоп-фактором: тегирование кадров поддерживает практически любой управляемый коммутатор актуальной ветки, а узкое место обычно в неуправляемых моделях на периферии. Их не обязательно менять — такой участок остаётся внутри одного сегмента, а разграничение доступа делается на стороне хостов средствами операционной системы. Перед работами мы сверяем матрицу портов и режимы транковых линков с текущей схемой, чтобы не переводить в тегирование то, что физически к этому не готово.

Изменения в сети делаем поэтапно, с сохранением резервного пути: пока новый сегмент не проверен, трафик продолжает идти по прежнему маршруту, и переключение происходит после контрольных проверок. Конфигурации перед правкой снимаются и хранятся отдельно, поэтому возврат к исходному состоянию — это применение заранее подготовленного набора, а не восстановление по памяти.

Как вы страхуетесь от сетевых петель?

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

Можно ли вернуть прежнюю схему, если что-то пойдёт не так?

Да, откат планируется до начала работ. Снимаем конфигурации, фиксируем порядок обратных действий и держим прежний путь передачи трафика рабочим до подтверждения результата. Если проверки на новом сегменте не проходят, возврат занимает минуты и не требует повторного проектирования сети.

Обсудим вашу схему сегментации — вернёмся с планом

Универсальной схемы сегментации не существует: она зависит от того, какие интерфейсы уже заняты, где проходит маршрутизация между сегментами и как устроена адресация. Чтобы оценка работ была точной, а не примерной вилкой, мы разбираем вашу текущую конфигурацию до начала настройки VLAN на Linux-серверах. Опишите задачу словами — к описанию приложите то, что уже есть в инфраструктуре.

• общая схема сети: коммутаторы, гипервизоры, физические серверы и точки маршрутизации между сегментами;
• выгрузка конфигураций интерфейсов и таблиц маршрутизации — текстом или экспортом из системы управления;
• текущее деление по VLAN: номера, назначение, подсети и шлюзы на каждом;
• схема адресации и разрешения имён: кто выдаёт адреса, где ведутся записи;
• требования к изоляции: какие сервисы обязаны видеть друг друга, какие — не должны в принципе;
• окна обслуживания и порядок согласования изменений, наличие резервных каналов;
• ограничения: оборудование, которое нельзя перенастраивать, внешние подрядчики, требования аудита.

В ответ вы получаете план внедрения с этапами, порядком переключений и точками отката на каждом шаге, а также сроки работ, привязанные к вашим окнам обслуживания.

Опишите задачу в свободной форме — вернёмся с оценкой и планом.