Настройка маршрутизации между подсетями: пошаговое руководство

Как настроить маршрутизацию между подсетями: рабочий алгоритм

Сервер сможет маршрутизировать трафик между подсетями, если он подключен к обоим сегментам, интерфейсы имеют корректные IP-адреса и маски, включена пересылка IPv4-пакетов, а firewall разрешает транзит. На клиентах и промежуточных маршрутизаторах должны существовать маршруты в прямом и обратном направлениях.

Рабочий порядок выглядит так: описать топологию, выбрать непересекающиеся подсети, настроить интерфейсы, включить IP forwarding, разрешить цепочку FORWARD, добавить маршруты к удаленным сетям, проверить шлюзы и убедиться, что ответы возвращаются через правильный next hop. Если сервер подключен к сетям напрямую, ядро Linux обычно создает connected routes автоматически.

Ниже используется схема с сервером R1, двумя интерфейсами и клиентами в разных сегментах. Она подходит для лабораторной сети, небольшого офиса и отдельных серверных зон. Для рабочего изменения заранее сохраните текущие настройки и подготовьте консольный доступ к серверу.

Когда сервер может выполнять роль маршрутизатора

Два сетевых интерфейса сами по себе не превращают Linux-сервер в маршрутизатор. R1 должен иметь адрес в каждой подключенной подсети, видеть соседние узлы через ARP или neighbor discovery и пересылать пакеты между интерфейсами.

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

Проверка роли маршрутизатора сводится к четырем условиям:

• на сервере есть путь к подсети источника и подсети назначения;
• интерфейсы подняты, подключены к правильным сегментам и имеют уникальные адреса;
• параметр net.ipv4.ip_forward имеет значение 1;
• firewall разрешает транзит в обоих направлениях с учетом состояния соединения.

Пример схемы с двумя подсетями

Клиент A отправляет пакет на 192.168.20.10 через шлюз 192.168.10.1. R1 принимает пакет на eth0, выбирает connected route к 192.168.20.0/24 и отправляет его через eth1. Клиент B формирует ответ для 192.168.10.10 через шлюз 192.168.20.1. Такой путь работает без ручного маршрута на R1, поскольку обе сети подключены непосредственно.

Если на R1 появляется сеть 192.168.30.0/24 за шлюзом 192.168.20.254, серверу уже нужен отдельный статический маршрут. На стороне сети назначения при этом должен существовать обратный путь к сети источника.

Планирование IP-адресации для подсетей

Ошибки адресного плана часто маскируются под проблемы firewall или маршрутизации. До выполнения команд зафиксируйте network prefix, CIDR, VLAN ID, физический или виртуальный интерфейс, шлюз и назначение каждого сегмента.

Подсети должны быть непересекающимися. Если два интерфейса используют диапазоны, которые частично совпадают, узел может считать удаленный адрес локальным и отправлять ARP вместо передачи пакета шлюзу. Одинаковые адресные пространства нельзя корректно связать обычными статическими маршрутами. Потребуется перенумерация или NAT, причем NAT усложнит журналирование и контроль доступа.

Инвентаризация интерфейсов и сегментов

Сначала составьте перечень физических портов, bond-интерфейсов, bridge, VLAN-подинтерфейсов и виртуальных сетей. Для каждого порта укажите, подключен ли он к access-сегменту или к trunk.

• Проверьте имя интерфейса в ОС: например, eth0, ens18 или enp1s0.
• Зафиксируйте link state, скорость и MTU.
• Укажите VLAN ID и список разрешенных VLAN на trunk-порте.
• Запишите существующие L3-шлюзы и маршруты по умолчанию.
• Проверьте правила firewall, зоны firewalld, политики UFW и фильтрацию на коммутаторе.

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

Пример адресного плана

В этой схеме R1 знает сети 192.168.10.0/24 и 192.168.20.0/24 через собственные интерфейсы. Для 192.168.30.0/24 маршрут пройдет через 192.168.20.254 по eth1. Сам next hop должен находиться в непосредственно доступной сети, иначе ядро не сможет доставить ему пакет.

Выбор шлюза для клиентов

Есть два рабочих варианта настройки:

• R1 становится шлюзом по умолчанию для подсети. Клиенты отправляют через него весь трафик, который не относится к локальной сети.
• R1 используется для отдельных удаленных сетей. На клиентах или их основном шлюзе добавляют маршрут только к нужному prefix.

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

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

Сервер как маршрутизатор между сетями: IP forwarding и firewall

Основной сценарий ниже использует Linux и iproute2. Настройка состоит из трех независимых частей: адреса интерфейсов, пересылка IPv4 и фильтрация транзитного трафика. Корректная таблица маршрутизации не отменяет запрет firewall.

Для готовой топологии с Ubuntu и Debian полезно сверить команды с руководством по маршрутизации между подсетями на Linux-сервере. Здесь акцент сделан на логике проверки и обратных маршрутах.

Проверка адресов интерфейсов сервера

Проверьте состояние интерфейсов, адреса и маски:

ip link show
ip addr show
ip -br addr

В выводе должны присутствовать адрес 192.168.10.1/24 на интерфейсе eth0 и адрес 192.168.20.1/24 на eth1. Интерфейс должен иметь состояние UP, а физический линк, если он нужен, должен быть активен.

Проверьте соседей и локальные шлюзы:

ip neigh show dev eth0
ip neigh show dev eth1
ping -I 192.168.10.1 192.168.10.10
ping -I 192.168.20.1 192.168.20.10

Если сосед не появляется в таблице, сначала проверяйте кабель, порт коммутатора, VLAN, ARP-фильтрацию и маску. Добавление маршрута не исправит проблему канального уровня.

Включение IP forwarding в Linux

Посмотрите текущее значение:

sysctl net.ipv4.ip_forward

Временное включение действует до перезагрузки:

sudo sysctl -w net.ipv4.ip_forward=1

Для постоянной настройки создайте файл /etc/sysctl.d/99-router.conf со строкой:

net.ipv4.ip_forward=1

Примените конфигурацию и проверьте результат:

sudo sysctl --system
sysctl net.ipv4.ip_forward

Ожидаемое значение равно 1. После перезагрузки повторите проверку, иначе временно рабочая схема снова перестанет пересылать пакеты.

Разрешение транзитного трафика в firewall

Для пакета, который проходит через сервер, используется цепочка FORWARD. Правила INPUT и OUTPUT управляют трафиком самого сервера и не заменяют разрешение транзита.

Пример для iptables с сохранением обратных пакетов через conntrack:

sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o eth1 -s 192.168.10.0/24 -d 192.168.20.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth1 -o eth0 -s 192.168.20.0/24 -d 192.168.10.0/24 -j ACCEPT

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

sudo iptables -L FORWARD -n -v

В nftables логика та же: создайте правила для входящего интерфейса eth0 и исходящего eth1, разрешите установленные соединения и добавьте обратное направление. В firewalld проверьте зоны обоих интерфейсов и разрешение forwarding между ними. В UFW для маршрутизируемого трафика используется политика route, а не обычное правило для входящего порта.

Для подробной настройки policy routing, ip rule, нескольких таблиц и проверки через tcpdump пригодится руководство по policy routing в Linux. Этот механизм нужен при нескольких провайдерах, асимметричных путях или отдельных таблицах маршрутов.

В Windows Server роль маршрутизатора обычно настраивают через RRAS. Для отдельных сценариев можно включить forwarding на нужных интерфейсах средствами PowerShell, добавить постоянные маршруты и проверить правила Windows Firewall. Команды и названия компонентов зависят от редакции и версии Windows Server, поэтому перед изменением проверьте, какой интерфейс назначен внутренним, а какой внешним.

Маршрутизация между VLAN: особенности схемы

VLAN разделяет широковещательные домены на втором уровне. IP-маршрут начинает работать только после того, как коммутатор и сервер правильно передают кадры с тегами 802.1Q. Ошибка trunk часто выглядит как отсутствие маршрута, хотя проблема возникает до IP.

Для каждого VLAN нужна собственная подсеть и IP-адрес L3-шлюза. Например, VLAN 10 может использовать 192.168.10.0/24, а VLAN 20, 192.168.20.0/24. Один адрес нельзя назначить сразу нескольким VLAN.

Router-on-a-stick через сервер

В схеме router-on-a-stick один физический интерфейс сервера подключен к trunk-порту коммутатора. На сервере создаются VLAN-подинтерфейсы, например eth0.10 и eth0.20. Каждый подинтерфейс получает адрес шлюза своего VLAN.

Пример временной настройки через iproute2:

sudo ip link add link eth0 name eth0.10 type vlan id 10
sudo ip addr add 192.168.10.1/24 dev eth0.10
sudo ip link set eth0.10 up

sudo ip link add link eth0 name eth0.20 type vlan id 20
sudo ip addr add 192.168.20.1/24 dev eth0.20
sudo ip link set eth0.20 up

В NetworkManager подинтерфейсы можно создать так:

sudo nmcli con add type vlan con-name vlan10 ifname eth0.10 dev eth0 id 10 ipv4.method manual ipv4.addresses 192.168.10.1/24
sudo nmcli con add type vlan con-name vlan20 ifname eth0.20 dev eth0 id 20 ipv4.method manual ipv4.addresses 192.168.20.1/24
sudo nmcli con up vlan10
sudo nmcli con up vlan20

На коммутаторе порт к серверу должен работать как trunk с разрешенными VLAN 10 и 20. Порты клиентов обычно работают как access-порты соответствующего VLAN. Проверьте native VLAN и MTU, поскольку несовпадение этих параметров приводит к потере кадров или фрагментации.

Маршрутизация на L3-коммутаторе

Если коммутатор поддерживает L3-маршрутизацию, он может создать SVI для каждого VLAN и стать default gateway. В таком случае серверу не нужны отдельные VLAN-подинтерфейсы для транзита между сетями, которыми уже управляет коммутатор.

Серверу понадобятся маршруты только к сетям, находящимся за ним. Например, L3-коммутатор может быть шлюзом для 192.168.10.0/24 и 192.168.20.0/24, а R1 будет обслуживать 192.168.30.0/24. Тогда на коммутаторе нужен маршрут к 192.168.30.0/24 через адрес R1 в общей транзитной сети.

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

Проверка VLAN до диагностики IP-маршрутов

• Проверьте, что trunk поднят и VLAN 10, 20 разрешены.
• Убедитесь, что access-порт клиента назначен нужному VLAN.
• Сверьте native VLAN на коммутаторе и сервере.
• Проверьте наличие тегов 802.1Q на серверном интерфейсе.
• Посмотрите neighbor для IP-адреса шлюза каждого VLAN.
• Сопоставьте MTU на физическом интерфейсе, trunk и подинтерфейсах.

Если eth0.10 поднят, но 192.168.10.1 не отвечает клиенту, проверяйте tagging и порт коммутатора. Если шлюз отвечает, но трафик между VLAN не проходит, переходите к IP forwarding и правилам firewall.

Как добавить статический маршрут на сервере

Статический маршрут нужен для сети, которую сервер не видит напрямую и которая находится за промежуточным маршрутизатором. Connected route к сети, назначенной на локальный интерфейс, ядро создает само.

Синтаксис и особенности постоянного хранения команд собраны в руководстве по таблицам маршрутизации и ip route.

Маршрут к напрямую подключенной сети

После назначения 192.168.20.1/24 на eth1 Linux обычно добавляет маршрут 192.168.20.0/24 dev eth1. Проверьте это так:

ip route show
ip route get 192.168.20.10

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

Маршрут через next hop

Для сети 192.168.30.0/24 за шлюзом 192.168.20.254 добавьте маршрут так:

sudo ip route add 192.168.30.0/24 via 192.168.20.254 dev eth1
ip route get 192.168.30.10

Проверка должна показать next hop 192.168.20.254 и интерфейс eth1. Шлюз должен быть достижим через 192.168.20.0/24. Нельзя указывать в качестве next hop адрес из недоступной сети или сам адрес назначения.

Для замены существующей записи используйте:

sudo ip route replace 192.168.30.0/24 via 192.168.20.254 dev eth1
sudo ip route del 192.168.30.0/24 via 192.168.20.254 dev eth1

Параметр metric помогает выбрать маршрут при наличии нескольких записей к одному prefix. Сначала проверьте более специфичный маршрут, default route и policy routing, поскольку они могут изменить ожидаемый выбор ядра.

Сохранение маршрута после перезагрузки

Команда ip route add меняет runtime-конфигурацию. После перезапуска сервера запись пропадет, если ее не сохранить в используемом сетевом менеджере.

В NetworkManager маршрут можно добавить к профилю:

sudo nmcli connection modify eth1 +ipv4.routes 192.168.30.0/24 192.168.20.254
sudo nmcli connection up eth1

В netplan маршрут описывают в YAML-конфигурации конкретного интерфейса. В systemd-networkd используют секцию [Route] в файле .network. В ifupdown маршрут добавляют в параметры соответствующего интерфейса. Формат зависит от дистрибутива и способа управления сетью, поэтому после применения проверяйте ядро, а не только текстовый файл.

ip route show
ip route get 192.168.30.10

Для Windows постоянный маршрут добавляют с административными правами:

route -p add 192.168.30.0 mask 255.255.255.0 192.168.20.254
route print
Get-NetRoute -DestinationPrefix 192.168.30.0/24

Статические маршруты на клиентских устройствах

Маршрут на R1 не заставляет клиента использовать R1. Конечное устройство само выбирает gateway по своей таблице. Если клиент A отправляет трафик к 192.168.20.10 через другой маршрутизатор, пакет может вообще не попасть на R1.

Маршрут на Linux-клиенте

Для клиента A временный маршрут к сети B выглядит так:

sudo ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0
ip route get 192.168.20.10

Вывод должен указывать шлюз 192.168.10.1 и интерфейс eth0. Если клиент сам использует 192.168.10.1 как default gateway, отдельная запись к 192.168.20.0/24 не нужна. Постоянный маршрут добавьте в профиль NetworkManager, netplan, systemd-networkd или другой менеджер, который управляет сетью клиента.

Маршрут на Windows-клиенте

В Windows откройте командную строку или PowerShell с административными правами:

route -p add 192.168.20.0 mask 255.255.255.0 192.168.10.1
route print
Get-NetRoute -DestinationPrefix 192.168.20.0/24

Если у устройства несколько интерфейсов, зафиксируйте интерфейс параметром IF после определения его номера в route print. В PowerShell можно использовать New-NetRoute, указав DestinationPrefix, NextHop и InterfaceIndex.

Маршрут на шлюзе вместо маршрута на каждом клиенте

При большом количестве устройств маршрут лучше добавить на их общий default gateway. Шлюз должен знать, что сеть 192.168.20.0/24 доступна через 192.168.10.1, а R1 должен знать обратный путь к сети клиентов.

Для автоматической выдачи classless static routes можно использовать DHCP option 121, если этот вариант поддерживают DHCP-сервер и клиенты. Централизованная настройка уменьшает количество ручных изменений и снижает риск расхождения таблиц маршрутов.

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

Обратные маршруты: почему ответы не возвращаются

Односторонняя связность обычно означает, что прямой путь настроен, а обратный отсутствует или проходит через другой шлюз. Запрос от 192.168.10.10 может попасть на 192.168.20.10 через R1, но клиент B отправит ответ через свой старый default gateway. Этот шлюз может не знать сеть 192.168.10.0/24.

Как выглядит прямой и обратный путь

Ping с самого R1 подтверждает только доступность адресов с маршрутизатора. Он не доказывает, что клиент A и клиент B правильно выбрали шлюзы и что firewall пропускает транзит в обоих направлениях.

Для каждого направления проверьте источник, prefix, next hop и интерфейс. В сложной сети запишите путь каждого промежуточного маршрутизатора, включая L3-коммутатор и основной шлюз.

Где добавлять обратный маршрут

Если сеть назначения подключена к R1 напрямую, клиент B может использовать 192.168.20.1 как default gateway или получить точечный маршрут к 192.168.10.0/24 через этот адрес.

Если сеть B находится за отдельным маршрутизатором R2, маршрут к сети A нужно добавить на R2:

ip route add 192.168.10.0/24 via 192.168.20.1

Вместо ручной записи на R2 можно настроить его default gateway через R1, если это соответствует архитектуре. При нескольких промежуточных узлах маршрут проверяют на каждом узле. Один пропущенный обратный prefix достаточно, чтобы TCP-соединение не установилось.

Почему NAT не является заменой маршрутизации

SNAT или MASQUERADE подменяет исходный адрес. Если R1 отправляет пакет от клиента A к клиенту B с адресом источника 192.168.20.1, B вернет ответ непосредственно R1. Это может скрыть отсутствие обратного маршрута к 192.168.10.0/24.

Для внутренних подсетей такой подход обычно создает лишние ограничения:

• сервер назначения видит адрес маршрутизатора вместо реального клиента;
• журналы теряют исходный IP без дополнительного учета соединений;
• появляются отдельные правила firewall и состояния conntrack;
• диагностика становится сложнее, поскольку рабочая схема зависит от трансляции.

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

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

Проверка таблицы маршрутизации и двусторонней связности

Диагностируйте сеть по слоям. Сначала проверьте link state и адреса, затем таблицу маршрутизации, локальный шлюз, транзит через R1, обратный путь, firewall и прикладной порт. Такой порядок быстро показывает, на каком участке появляется отказ.

Проверка таблицы маршрутизации

На Linux выполните:

ip addr show
ip route show
ip route get 192.168.20.10
ip route get 192.168.30.10
ip neigh show

Сверьте prefix, metric, gateway, интерфейс и source address с адресным планом. Для клиента A результат ip route get 192.168.20.10 должен указывать 192.168.10.1 или корректный шлюз, который знает маршрут к сети B.

На Windows используйте:

route print
Get-NetRoute
Get-NetIPConfiguration
Test-NetConnection -ComputerName 192.168.20.10 -Port 443

Проверьте несколько default route и метрики. Более длинный prefix имеет приоритет над менее специфичным маршрутом, поэтому запись /25 может перехватить адрес, который вы ожидали отправить через маршрут /24.

Проверка пути с помощью ping и traceroute

Проверяйте адреса в фиксированном порядке:

1. локальный IP-адрес и состояние интерфейса;
2. шлюз собственной подсети, например 192.168.10.1;
3. второй интерфейс R1, например 192.168.20.1;
4. удаленный клиент 192.168.20.10;
5. нужный TCP-порт на удаленном клиенте.

Для трассировки в Linux используйте числовой вывод:

traceroute -n 192.168.20.10

В Windows:

tracert 192.168.20.10

ICMP может быть запрещен на хосте или промежуточном устройстве, поэтому пропущенный hop не всегда означает отказ маршрутизации. Успешный ping тоже не гарантирует доступность сервиса на TCP или UDP-порту.

Захват пакетов на сервере

Запустите захват на обоих интерфейсах R1 и повторите один тест с клиента A:

sudo tcpdump -ni eth0 host 192.168.10.10 and host 192.168.20.10
sudo tcpdump -ni eth1 host 192.168.10.10 and host 192.168.20.10

Интерпретируйте результат по месту появления пакетов:

• пакет виден только на eth0, значит проверяйте IP forwarding, цепочку FORWARD и policy firewall;
• пакет виден на eth0 и eth1, но ответа нет, значит проверяйте клиент B, его firewall и обратный маршрут;
• ответ приходит на eth1, но не появляется на eth0, значит проверяйте обратное правило firewall, conntrack и rp_filter;
• пакеты проходят в обоих направлениях, но приложение недоступно, значит проверяйте сервис, порт и локальный firewall хоста.

Фильтр host сокращает объем вывода. Для TCP-порта можно добавить условие port 443 или нужный номер порта. Снимок трафика на входящем и исходящем интерфейсах дает больше информации, чем отдельный ping с самого маршрутизатора.

Проверка TCP-порта и DNS отдельно от маршрутизации

После проверки IP-адреса проверьте прикладной порт. В Windows подойдет:

Test-NetConnection -ComputerName 192.168.20.10 -Port 443

В Linux используйте:

nc -vz 192.168.20.10 443
curl -v http://192.168.20.10:8080

Сначала подключайтесь к IP-адресу, затем проверяйте DNS-имя через dig, nslookup или getent hosts. Если IP доступен, а имя не разрешается, проблема находится в DNS, а не в маршрутизации.

Типичные ошибки при настройке маршрутизации между подсетями

Неверная маска или пересекающиеся подсети

Маска определяет, какие адреса узел считает локальными. Например, при ошибочном использовании /16 вместо /24 хост может пытаться найти 192.168.20.10 через ARP в локальном сегменте, хотя этот адрес находится за R1.

Сверьте CIDR на всех интерфейсах и клиентах:

ip -br addr
ip route get 192.168.20.10

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

Маршрут есть, но firewall блокирует транзит

Проверьте политику FORWARD, зоны firewalld, правила nftables или iptables, счетчики совпадений и логирование отброшенных пакетов. Убедитесь, что разрешены оба направления и состояние ESTABLISHED,RELATED для ответного трафика.

Если правила ограничивают доступ по портам, проверьте каждый нужный TCP или UDP-порт. Разрешение ICMP не открывает автоматически HTTPS, SSH, DNS или другой сервис.

Пакеты уходят не через тот интерфейс

Причиной могут быть несколько default route, неверные метрики, policy routing или более длинный prefix, который перехватывает адрес. Сравните фактический выбор ядра с ожидаемой схемой:

ip route get 192.168.30.10
ip rule show
ip route show table all

В Windows проверьте Get-NetRoute и значения InterfaceIndex. Маршрут через правильный gateway, но с неправильным интерфейсом, часто приводит к ошибке недостижимого next hop.

Настройка исчезает после перезагрузки

Повторно проверьте постоянность четырех компонентов:

• IP-адресов и масок;
• параметра net.ipv4.ip_forward;
• статических маршрутов и VLAN-подинтерфейсов;
• правил firewall и их автозагрузки.

После перезагрузки выполните ip addr, ip route, sysctl net.ipv4.ip_forward и тесты связности. Запись в конфигурационном файле считается рабочей только после проверки фактического состояния системы.

Симптомы помогают сузить поиск:

Итоговый чек-лист перед вводом схемы в работу

Критерии успешной настройки

Схема готова, когда клиент A устанавливает соединение с клиентом B через ожидаемый сервер или L3-шлюз, ответ возвращается по корректному пути, нужные TCP и UDP-порты доступны, а настройки сохраняются после перезагрузки.

• Подсети не пересекаются.
• IP-адреса, CIDR и интерфейсы совпадают с адресным планом.
• Сервер видит оба сегмента и получает neighbor для локальных шлюзов.
• Включен IPv4 forwarding.
• Connected routes появились автоматически.
• Статические маршруты к удаленным сетям добавлены через достижимый next hop.
• На клиентах или их шлюзах настроены маршруты в прямом направлении.
• На стороне назначения есть обратный маршрут к сети источника.
• Firewall разрешает нужный транзит и обратные состояния conntrack.
• VLAN, trunk, access-порты, tagging и MTU согласованы.
• Проверены ip route get, ping, traceroute или tracert.
• Захват tcpdump подтверждает входящий, исходящий и ответный пакеты.
• Прикладной порт проверен отдельно от ICMP и DNS.

Что проверить после изменения топологии

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

Проверьте правила firewall, VLAN-теги, MTU и доступность прикладных сервисов. Обновите схему адресации и укажите next hop для каждой удаленной сети. Результаты тестов сохраните в рабочей документации, чтобы после следующего изменения можно было сравнить фактический путь с эталонным.

Для лабораторной проверки можно поднять изолированный стенд с двумя VDS и отдельными подсетями в облачной инфраструктуре Timeweb Cloud. Перед проверкой убедитесь, что правила безопасности самого провайдера разрешают нужный транзитный трафик.

Частые вопросы о маршрутизации между подсетями

Нужно ли добавлять статический маршрут, если сервер подключен к обеим подсетям?

Обычно нет. После назначения 192.168.10.1/24 и 192.168.20.1/24 Linux создает connected routes к 192.168.10.0/24 и 192.168.20.0/24. Ручная запись нужна для удаленной сети за next hop, например 192.168.30.0/24 через 192.168.20.254, или для нестандартной policy routing.

Почему сервер видит оба сегмента, а клиенты не видят друг друга?

Проверьте значение net.ipv4.ip_forward, цепочку FORWARD, default gateway клиентов и обратный маршрут на стороне назначения. Затем запустите tcpdump на обоих интерфейсах R1. Если пакет выходит к клиенту B, но ответ не возвращается, проблема находится после R1 или в обратном firewall.

Можно ли маршрутизировать VLAN без отдельного физического интерфейса для каждого VLAN?

Да, если коммутатор поддерживает trunk, сервер принимает 802.1Q, а ОС создает VLAN-подинтерфейсы. Для VLAN 10 и VLAN 20 нужны отдельные подинтерфейсы и адреса шлюзов, например 192.168.10.1/24 и 192.168.20.1/24. Межсегментный транзит должен быть разрешен firewall.

Если маршрутизацию уже выполняет L3-коммутатор с SVI, серверу не требуется обслуживать эти VLAN. Он должен получить маршрут только к сетям, которые находятся за сервером, а default gateway клиентов остается на L3-коммутаторе.