Маршрутизация между VLAN на Linux-сервере в 2026: пошаговая настройка

Linux-сервер может работать маршрутизатором между несколькими VLAN, если коммутатор передает по trunk-порту кадры 802.1Q, на сервере созданы VLAN-интерфейсы с адресами шлюзов, включен IPv4 forwarding и разрешен транзит в цепочке forward. В этой схеме хосты из VLAN 10 используют шлюз 192.168.10.1, хосты из VLAN 20, шлюз 192.168.20.1.

В примере физический интерфейс сервера называется eth0. На нем создаются eth0.10 и eth0.20. VLAN 10 предназначен для пользователей и использует подсеть 192.168.10.0/24, VLAN 20 предназначен для серверов и использует 192.168.20.0/24. Порты коммутатора для конечных устройств работают в режиме access, а порт к Linux-серверу пропускает VLAN 10 и VLAN 20 в режиме trunk.

Минимальная последовательность выглядит так:

sudo ip link set dev eth0 up
sudo ip link add link eth0 name eth0.10 type vlan id 10
sudo ip link add link eth0 name eth0.20 type vlan id 20
sudo ip addr add 192.168.10.1/24 dev eth0.10
sudo ip addr add 192.168.20.1/24 dev eth0.20
sudo ip link set dev eth0.10 up
sudo ip link set dev eth0.20 up
sudo sysctl -w net.ipv4.ip_forward=1
ip route show

Эти команды меняют конфигурацию только до перезагрузки. Ниже приведены варианты сохранения настроек через NetworkManager, systemd-networkd и Netplan, пример фильтрации nftables и алгоритм поиска неисправностей.

Маршрутизация между VLAN на Linux: краткий сценарий настройки

Linux получает кадр из trunk на VLAN-интерфейсе, например eth0.10. Ядро видит адрес назначения в другой подсети, выбирает connected route через eth0.20 и отправляет пакет с тегом VLAN 20. Для успешного обмена нужны четыре условия: коммутатор пропускает оба VLAN, IP-подсети не пересекаются, включен net.ipv4.ip_forward, а firewall разрешает нужное направление в цепочке forward.

Если нужен вариант Router-on-a-Stick с классическими саб-интерфейсами и фильтрацией iptables, полезно сверить его с практической инструкцией по маршрутизации между VLAN на Linux. В этой статье основной сценарий использует nftables и стандартный iproute2.

Тестовая топология и соглашения статьи

Если eth0 используется только как родительский интерфейс для VLAN, обычный IP-адрес на нем не нужен. IP-адреса шлюзов назначаются на eth0.10 и eth0.20. Имена интерфейсов, VLAN ID и подсети замените на значения своей схемы.

Для лаборатории Linux-узел можно разместить на облачном сервере Timeweb Cloud, но перед настройкой проверьте поддержку trunk и передачи 802.1Q. Многие виртуальные сети провайдера изолируют гостевые интерфейсы и не позволяют передавать произвольные VLAN-теги.

Как устроен inter-VLAN routing через Linux-сервер

VLAN разделяет коммутируемую сеть на отдельные broadcast domains. Коммутатор доставляет кадр внутри одного VLAN, но сам по себе не переносит IPv4-пакет между разными подсетями. Для связи VLAN 10 и VLAN 20 нужен L3-маршрутизатор, в нашем случае Linux-сервер.

Путь пакета выглядит так:

1. Хост в VLAN 10 проверяет адрес назначения и видит, что 192.168.20.10 находится в другой подсети.
2. Хост отправляет кадр на MAC-адрес шлюза 192.168.10.1.
3. Коммутатор помещает кадр в VLAN 10 и передает его по trunk с тегом 802.1Q.
4. Linux принимает пакет через eth0.10, проверяет таблицу маршрутизации и forwarding.
5. Linux отправляет пакет через eth0.20, а коммутатор передает его на access-порт VLAN 20.

Для обратного ответа сервер в VLAN 20 должен использовать 192.168.20.1 как default gateway. Если конечный хост имеет другой шлюз или неправильную маску, запрос может дойти до сервера, но ответ не вернется по нужному пути.

Архитектурные отличия Router-on-a-Stick, L3-коммутатора и Linux-маршрутизатора разобраны в сравнении схем маршрутизации между VLAN.

Какие адреса назначаются VLAN-интерфейсам

Каждая VLAN-подсеть получает собственный адрес шлюза:

Клиент VLAN 10 может иметь адрес 192.168.10.10/24, а его default gateway должен указывать на 192.168.10.1. Клиент VLAN 20 может иметь адрес 192.168.20.10/24 и шлюз 192.168.20.1. Подсети должны быть уникальными и не пересекаться с адресами других интерфейсов Linux или соседних маршрутизаторов.

Когда нужен bridge, а когда достаточно VLAN subinterface

Для обычной маршрутизации достаточно VLAN subinterface поверх физического интерфейса. Схема состоит из eth0, eth0.10, eth0.20, IP-адресов и forwarding.

Bridge нужен, когда требуется прозрачное L2-соединение, передача сети виртуальным машинам, контейнерам или объединение портов в один коммутируемый домен. В таком случае появляются br0, bridge ports и, при необходимости, bridge VLAN filtering. Добавление bridge без архитектурной причины усложняет диагностику: IP-адреса должны находиться на bridge или VLAN-интерфейсе над bridge, а не одновременно на физическом порту и его участнике.

Подготовка trunk-подключения и проверка условий

Проверяйте физический линк и коммутатор до создания VLAN. Если кадры не доходят до сервера, команды Linux создадут интерфейсы, но шлюзы не будут отвечать.

Изменение удаленной сетевой конфигурации может оборвать SSH. Подготовьте консольный доступ, IPMI, виртуальную консоль или другой out-of-band канал. Для первых тестов сохраняйте открытую сессию и применяйте изменения небольшими шагами.

Проверка физического интерфейса Linux

Сначала найдите имя физического интерфейса и отличите его от VLAN, bridge или bond:

ip -br link
ip link show
ip addr show dev eth0
ip link show dev eth0
sudo ethtool eth0
cat /sys/class/net/eth0/carrier

В выводе ip link ожидается состояние UP. Значение 1 в файле carrier показывает, что физический линк поднят. В ethtool проверьте Link detected: yes, скорость, duplex и MTU.

Если сервер использует предсказуемые имена, интерфейс может называться ens160, enp1s0 или иначе. Замените eth0 во всех командах на реальное имя. Нельзя создавать VLAN на интерфейсе, который уже входит в bridge или bond, если схема не предусматривает VLAN поверх этого агрегата.

MTU должно совпадать на сервере, коммутаторе и промежуточных устройствах. Не меняйте его вслепую: сначала проверьте фактическое значение командой ip link show dev eth0 и документацию своей платформы.

Что проверить на коммутаторе

• Порт Linux работает в режиме trunk, а не access.
• VLAN 10 и VLAN 20 добавлены в список разрешенных VLAN на trunk.
• VLAN ID совпадает с идентификаторами в командах ip link add.
• Native VLAN или untagged VLAN согласованы на обоих концах либо не используются.
• Порт клиента VLAN 10 назначен в access VLAN 10.
• Порт клиента VLAN 20 назначен в access VLAN 20.
• Порт не заблокирован STP, контролем доступа или защитой от неизвестных MAC-адресов.
• Счетчики входящих и исходящих кадров увеличиваются при тесте.

Native VLAN mismatch часто приводит к смешению тегированного и нетегированного трафика. Для базовой схемы удобнее передавать VLAN 10 и VLAN 20 тегированными и не использовать обычный IP-адрес на родительском интерфейсе Linux.

Настройка VLAN-интерфейсов Linux и IP-адресов

Ниже используется стандартный iproute2. Такой способ удобен для первичной проверки 802.1Q, но сам по себе не сохраняет изменения после перезагрузки.

Создание VLAN-интерфейсов через iproute2

Проверьте поддержку VLAN-модуля и поднимите физический интерфейс:

sudo modprobe 8021q
sudo ip link set dev eth0 up
ip link show type vlan

Создайте два саб-интерфейса:

sudo ip link add link eth0 name eth0.10 type vlan id 10
sudo ip link add link eth0 name eth0.20 type vlan id 20
sudo ip link set dev eth0.10 up
sudo ip link set dev eth0.20 up

Команда link eth0 задает родительский интерфейс, а id 10 или id 20, тег 802.1Q. Если имя eth0.10 уже занято, не создавайте второй интерфейс с тем же именем. Проверьте существующую конфигурацию:

ip -d link show dev eth0.10
ip -d link show dev eth0.20

В выводе должны присутствовать тип vlan, протокол 802.1Q, родительский интерфейс и правильный идентификатор VLAN. Наличие интерфейса в выводе не подтверждает прохождение кадров через коммутатор, поэтому позже понадобится tcpdump.

Назначение адресов шлюзов и проверка состояния

Назначьте IP-адреса на VLAN-интерфейсы:

sudo ip addr add 192.168.10.1/24 dev eth0.10
sudo ip addr add 192.168.20.1/24 dev eth0.20
ip -br addr show dev eth0.10
ip -br addr show dev eth0.20

Ожидаемый результат содержит 192.168.10.1/24 на eth0.10 и 192.168.20.1/24 на eth0.20. При повторном применении вместо add можно использовать replace, чтобы команда не завершалась ошибкой из-за уже существующего адреса:

sudo ip addr replace 192.168.10.1/24 dev eth0.10
sudo ip addr replace 192.168.20.1/24 dev eth0.20

С клиента VLAN 10 проверьте шлюз:

ping -c 3 192.168.10.1

С клиента VLAN 20 выполните аналогичную проверку для 192.168.20.1. На Linux-сервере параллельно смотрите соседей:

ip neigh show dev eth0.10
ip neigh show dev eth0.20

Состояние REACHABLE или STALE показывает, что ARP-сосед обнаружен. Отсутствие записи после попытки ping указывает на проблему L2, trunk, access VLAN, маски или адресации. До проверки forwarding нужно добиться ответа каждого шлюза из своей VLAN.

Включение IPv4 forwarding и проверка таблицы маршрутизации

Linux принимает IP-пакет на одном интерфейсе и передает его через другой только при включенном IPv4 forwarding. Адреса на двух VLAN-интерфейсах сами по себе не превращают сервер в маршрутизатор.

Временное и постоянное включение forwarding

Для теста включите пересылку до перезагрузки:

sudo sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Ожидаемый результат, net.ipv4.ip_forward = 1. Чтобы сохранить параметр, создайте отдельный файл:

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-router.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Параметр IPv4 не включает forwarding для IPv6. Если в сети используются IPv6-адреса, настройте отдельную политику пересылки и фильтрации. Если IPv6 не используется, проверьте, что RA, адреса и маршруты не создают обход IPv4-политики.

Проверка маршрутов и выбор исходящего интерфейса

После назначения адресов ядро автоматически добавляет connected routes:

ip route show table main

В выводе должны быть строки, близкие к этим:

192.168.10.0/24 dev eth0.10 proto kernel scope link src 192.168.10.1
192.168.20.0/24 dev eth0.20 proto kernel scope link src 192.168.20.1

Отдельные статические маршруты между этими подсетями не нужны, потому что обе сети непосредственно подключены к серверу. Проверьте конкретный выбор маршрута:

ip route get 192.168.20.10 from 192.168.10.10
ip route get 192.168.10.10 from 192.168.20.10

В результате проверяйте поле dev и исходный адрес. Для назначения в подсети VLAN 20 должен выбираться eth0.20, для назначения в VLAN 10, eth0.10. Default route нужна для внешних сетей, но она не заменяет шлюзы и connected routes локальных VLAN.

Параметры reverse path filtering

Reverse path filtering проверяет, соответствует ли обратный маршрут адресу источника входящего пакета. В простой симметричной схеме этот механизм обычно не мешает работе. Проблемы появляются при асимметричной маршрутизации, policy routing, нескольких uplink или сложных VPN.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth0.10.rp_filter
sysctl net.ipv4.conf.eth0.20.rp_filter

Значение 0 отключает проверку, 1 включает строгий режим, 2 использует свободную проверку. Не меняйте rp_filter как универсальное средство исправления. Сначала подтвердите проблему через маршруты, tcpdump и журналы firewall, затем выберите значение с учетом политики безопасности дистрибутива.

Фильтрация трафика между VLAN через nftables

Forwarding разрешает ядру пересылать пакеты, но firewall может остановить их в цепочке forward. Политика drop требует явных разрешений. Для транзитного трафика нужны правила forward, а для доступа к самому Linux-серверу, например SSH и ping шлюза, правила input.

Минимальная политика для проверки маршрутизации

Для первичной проверки можно временно разрешить ICMP между VLAN и обратные пакеты по состоянию соединения. Перед загрузкой правил по удаленному SSH убедитесь, что цепочка input сохраняет доступ с доверенного адреса.

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" counter accept
        ct state invalid counter drop
        ct state established,related counter accept
        iifname "eth0.10" ip protocol icmp counter accept
        iifname "eth0.20" ip protocol icmp counter accept
        iifname "eth0.10" ip saddr 192.168.10.0/24 tcp dport 22 counter accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state invalid counter drop
        ct state established,related counter accept
        iifname "eth0.10" oifname "eth0.20" ip protocol icmp counter accept
        iifname "eth0.20" oifname "eth0.10" ip protocol icmp counter accept
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Правила с iifname и oifname фиксируют направление на уровне интерфейсов. Это снижает риск случайно открыть такой же доступ через другой uplink. После проверки ICMP замените широкие разрешения на конкретные сервисы и адреса.

Правила доступа между Users и Servers

Предположим, пользователи из VLAN 10 должны обращаться к серверу 192.168.20.10 по HTTPS и SSH, а новые соединения из VLAN 20 в VLAN 10 запрещены. Цепочка forward может содержать такие правила:

chain forward {
    type filter hook forward priority 0; policy drop;
    ct state invalid counter drop
    ct state established,related counter accept
    iifname "eth0.10" oifname "eth0.20" ip daddr 192.168.20.10 tcp dport { 443, 22 } counter accept
}

Ответы сервера попадут под ct state established,related. Правило не открывает весь VLAN 20, а разрешает два TCP-порта одного адреса. Для группы серверов можно использовать set адресов или отдельные правила с понятными счетчиками.

Если пользователям нужен DNS, добавьте разрешения к конкретному DNS-серверу и портам 53 TCP/UDP. Если требуется мониторинг, ограничьте источники адресами системы мониторинга. ICMP оставляйте для диагностики в согласованном объеме: полный запрет усложняет проверку MTU, маршрута и доступности.

Проверка и сохранение правил nftables

Сохраните конфигурацию, например, в /etc/nftables.conf, проверьте синтаксис и только затем загрузите правила:

sudo nft -c -f /etc/nftables.conf
sudo nft -f /etc/nftables.conf
sudo nft list ruleset
sudo nft list chain inet filter forward

Счетчики после тестового ping должны увеличиваться на соответствующем правиле. Если счетчик разрешения не меняется, пакет не дошел до Linux, пришел через другой интерфейс или не совпал с адресом и протоколом. Команда nft list ruleset показывает фактическую активную конфигурацию, а не содержимое файла на диске.

Для загрузки после перезагрузки включите сервис nftables, если он присутствует в вашем дистрибутиве:

sudo systemctl enable nftables
sudo systemctl restart nftables
sudo systemctl status nftables

Название пакета и unit может отличаться. После перезапуска проверьте, что сеть уже поднята, правила загрузились, а SSH-доступ не заблокирован.

Сохранение VLAN-конфигурации после перезагрузки

Runtime-команды через iproute2 подходят для эксперимента. Для постоянной работы сохраните VLAN-интерфейсы, IP-адреса, автозапуск и sysctl в одном выбранном сетевом менеджере.

NetworkManager: VLAN-профили и адреса

Создайте два VLAN-профиля через nmcli:

sudo nmcli connection add type vlan con-name vlan10 ifname eth0.10 dev eth0 id 10 ipv4.method manual ipv4.addresses 192.168.10.1/24 ipv6.method disabled connection.autoconnect yes
sudo nmcli connection add type vlan con-name vlan20 ifname eth0.20 dev eth0 id 20 ipv4.method manual ipv4.addresses 192.168.20.1/24 ipv6.method disabled connection.autoconnect yes
sudo nmcli connection up vlan10
sudo nmcli connection up vlan20
nmcli connection show
nmcli device status

Проверьте, что eth0 не получает DHCP-адрес и не имеет лишнего default route, если он служит только родителем VLAN. Посмотрите параметры профилей:

nmcli connection show vlan10
nmcli connection show vlan20

Удаленное изменение профиля выполняйте с консольным доступом или с заранее подготовленным способом отката. NetworkManager, systemd-networkd и Netplan не должны одновременно управлять одним и тем же интерфейсом.

systemd-networkd и Netplan

Для systemd-networkd создайте netdev-файлы VLAN. Пример для VLAN 10:

[NetDev]
Name=eth0.10
Kind=vlan

[VLAN]
Id=10

Сохраните его как /etc/systemd/network/20-vlan10.netdev. Аналогичный файл для VLAN 20 должен содержать Name=eth0.20 и Id=20. Привяжите VLAN к физическому интерфейсу в файле /etc/systemd/network/10-eth0.network:

[Match]
Name=eth0

[Network]
VLAN=eth0.10
VLAN=eth0.20

Для адресов создайте отдельные network-файлы:

[Match]
Name=eth0.10

[Network]
Address=192.168.10.1/24

Для eth0.20 используйте отдельный файл с адресом 192.168.20.1/24. После изменения проверьте статус:

sudo systemctl restart systemd-networkd
networkctl status eth0
networkctl status eth0.10
networkctl status eth0.20

Пример Netplan выглядит так:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      optional: true
  vlans:
    eth0.10:
      id: 10
      link: eth0
      addresses:
        - 192.168.10.1/24
    eth0.20:
      id: 20
      link: eth0
      addresses:
        - 192.168.20.1/24

Перед применением проверьте YAML и используйте безопасный режим:

sudo netplan try
sudo netplan apply
ip -br addr
ip route show

netplan try дает возможность подтвердить конфигурацию и вернуть прежнее состояние при потере удаленного доступа. Конкретный порядок зависит от версии дистрибутива и выбранного renderer.

Контроль после перезагрузки

Перезагрузка проверяет не отдельную команду, а весь порядок запуска служб:

ip link show type vlan
ip addr show dev eth0.10
ip addr show dev eth0.20
ip route show
sysctl net.ipv4.ip_forward
sudo nft list ruleset

После проверки интерфейсов выполните ping шлюзов, межсегментный ping и тест разрешенного TCP-сервиса. Если firewall стартует раньше сетевых профилей, убедитесь, что правила используют имена интерфейсов, которые появляются с ожидаемыми параметрами, и что сервисы запускаются без ошибки.

Проверка работоспособности inter-VLAN routing

Диагностику выполняйте снизу вверх: физический линк, VLAN-теги, IP-адреса, ARP, connected routes, forwarding, firewall, обратный маршрут и приложение. Такой порядок сокращает число одновременных гипотез.

Проверка VLAN-тегов через tcpdump

На родительском интерфейсе посмотрите кадры 802.1Q:

sudo tcpdump -eni eth0 vlan
sudo tcpdump -eni eth0 'vlan 10 or vlan 20'

При ping шлюза из VLAN 10 должны появиться ARP-запросы или ICMP-кадры с тегом 10. Для VLAN 20 ожидается тег 20. Отсутствие кадров означает, что проблема находится между клиентом, access-портом, trunk или физическим линком.

На VLAN-интерфейсах анализируйте уже дек encapsulated IP-трафик:

sudo tcpdump -ni eth0.10 'arp or icmp'
sudo tcpdump -ni eth0.20 'arp or icmp'

На некоторых NIC часть обработки VLAN выполняет аппаратно, поэтому вид тегов на eth0 может зависеть от offload. Сверяйте захват с аппаратными счетчиками и выводом ip -s link show.

Проверка шлюзов и ARP

Сначала проверяйте адрес шлюза своей VLAN:

ping -c 3 192.168.10.1
ping -c 3 192.168.20.1

На Linux-сервере смотрите соседей и статистику интерфейсов:

ip neigh show
ip neigh show dev eth0.10
ip neigh show dev eth0.20
ip -s link show dev eth0.10
ip -s link show dev eth0.20

Если шлюз не отвечает, проверяйте trunk, разрешенный список VLAN, access VLAN, IP-адрес и маску. Правила маршрутизации между подсетями на этом этапе не имеют значения, потому что клиент еще не может достичь локального шлюза.

Устаревшую neighbor-запись можно очистить и повторить тест:

sudo ip neigh flush dev eth0.10
sudo ip neigh flush dev eth0.20

Проверка маршрута от клиента до другой VLAN

После успешного ping шлюзов проверьте межсегментный обмен. Например, клиент 192.168.10.10 обращается к серверу 192.168.20.10:

ping -c 3 192.168.20.10
tracepath 192.168.20.10
ip route get 192.168.20.10 from 192.168.10.10

На Linux параллельно запустите захват на обоих интерфейсах:

sudo tcpdump -ni eth0.10 host 192.168.10.10
sudo tcpdump -ni eth0.20 host 192.168.20.10

Если запрос виден на eth0.10, но не появляется на eth0.20, проверьте forwarding, маршрут и цепочку forward. Если запрос выходит через eth0.20, но ответа нет, проверьте firewall конечного сервера, его default gateway и обратный маршрут.

Подробный набор команд для проверки маршрутов, ARP, MTU, сокетов и nftables собран в шпаргалке по диагностике Linux-маршрутизатора.

Диагностика типичных ошибок на коммутаторе, Linux и клиентах

Симптом указывает на уровень проблемы. Ниже приведены проверки, которые помогают быстро сузить поиск.

VLAN-интерфейс отсутствует или имеет неправильный ID

Проверьте тип и параметры интерфейса:

ip -d link show dev eth0.10
ip -d link show dev eth0.20
ip link show type vlan

В выводе должны совпадать родительский интерфейс, протокол 802.1Q и VLAN ID. Если интерфейс создан вручную, но NetworkManager или networkd сразу удаляет его, найдите конфликтующий профиль. Если VLAN работает внутри виртуальной машины или контейнера, проверьте network namespace и передачу тегов через гипервизор.

Linux-шлюз недоступен из VLAN

Проверьте физический carrier, состояние eth0.10 или eth0.20, наличие IP-адреса и ARP. Если на eth0 нет кадров с нужным тегом, исправляйте коммутатор. Если кадр приходит, но Linux не отвечает, проверьте адрес, маску и цепочку input.

Ситуация, когда VLAN 10 работает, а VLAN 20 нет, обычно связана со списком разрешенных VLAN на trunk, неправильным access-портом или ошибкой в команде id 20. Счетчики порта коммутатора и tcpdump дают ответ быстрее, чем повторное создание маршрутов.

Шлюзы доступны, но трафик между VLAN заблокирован

Проверьте forwarding:

sysctl net.ipv4.ip_forward
ip route show
sudo nft list chain inet filter forward

Если forwarding равен 0, включите его и повторите тест. Если forwarding равен 1, смотрите счетчики nftables. Пакет должен увеличивать счетчик правила, разрешающего направление из eth0.10 в eth0.20. Обратный ответ должен попадать под established,related или отдельное разрешение.

Проверьте маски и default gateway на обоих конечных хостах. Адрес 192.168.20.10/16 вместо 192.168.20.10/24 заставит хост считать сеть VLAN 10 локальной и отправлять ARP напрямую, минуя шлюз.

Настройка работает до перезагрузки или пропадает удаленный доступ

Проверьте, какой сервис управляет сетью:

systemctl is-active NetworkManager
systemctl is-active systemd-networkd
nmcli general status
networkctl list

Оставьте один источник конфигурации для eth0 и VLAN-интерфейсов. Sysctl храните в /etc/sysctl.d/, firewall, в конфигурации nftables, а профили VLAN, в NetworkManager, networkd или Netplan.

Перед удаленным применением используйте netplan try, консоль или автоматический откат. Проверяйте доступ к серверу с доверенного management-адреса после каждого изменения input.

Безопасность и эксплуатационные ограничения схемы

VLAN разделяют широковещательные домены, но не задают правила доступа между подсетями. Когда Linux начинает маршрутизировать пакеты, межсегментные соединения нужно описать в firewall и проверить на конечных системах.

Изоляция управляющего и пользовательских VLAN

Выделите management VLAN для SSH, мониторинга и административных интерфейсов. В цепочке input разрешайте SSH только от доверенных адресов, а не от всей пользовательской подсети. Пример логики:

• input управляет доступом к самому Linux-серверу.
• forward управляет транзитом между VLAN.
• output определяет исходящие соединения самого сервера.
• established,related возвращает ответы только для уже разрешенных соединений.
• Политика drop в forward блокирует направления, которые не описаны явно.

Не разрешайте SSH, web-интерфейс и другие административные сервисы из VLAN Users без конкретной причины. Для каждого нового правила фиксируйте источник, назначение, протокол, порт и владельца сервиса. Счетчики nftables помогают увидеть фактическое использование правила, а журналирование стоит включать выборочно, чтобы не заполнить системный журнал большим объемом повторяющихся пакетов.

Что проверить перед вводом в эксплуатацию

1. VLAN ID на коммутаторе и Linux совпадают.
2. Trunk пропускает VLAN 10 и VLAN 20, access-порты назначены корректно.
3. Подсети уникальны, маски и default gateway указаны на конечных хостах.
4. На Linux созданы eth0.10 и eth0.20 с адресами шлюзов.
5. Включен net.ipv4.ip_forward, а connected routes присутствуют в таблице маршрутизации.
6. Правила nftables разрешают только согласованные направления и сервисы.
7. Сохранены VLAN-профили, sysctl и firewall, а конфигурация проверена после перезагрузки.
8. Проверены ARP, ICMP, разрешенные TCP-сервисы и обратные маршруты.
9. IPv6 либо настроен с отдельным forwarding и firewall, либо ограничен явной сетевой политикой.
10. Есть консольный или out-of-band доступ на случай ошибки в trunk, маршруте или firewall.

Один Linux-маршрутизатор создает единую точку отказа. Для высокой доступности понадобятся резервный маршрутизатор, виртуальный IP, синхронизация firewall и механизм динамической маршрутизации или другой способ переключения. До появления такой схемы заранее определите допустимое время простоя и процедуру восстановления конфигурации.