Как настроить маршрутизацию между подсетями на Linux-сервере | AdminWiki
Logo

Как настроить маршрутизацию между подсетями на Linux-сервере

30 августа 2026 11 мин. чтения
Содержание статьи

Linux-сервер может работать маршрутизатором между двумя подсетями, если у него есть сетевые интерфейсы в каждом сегменте, включен IP forwarding, firewall пропускает транзитный трафик, а клиенты знают обратный маршрут. В этой статье используется схема с подсетью A 192.168.10.0/24 и подсетью B 192.168.20.0/24.

Сервер получает адрес 192.168.10.1 в первой сети и 192.168.20.1 во второй. Клиент из подсети A отправляет пакеты на сервер как на шлюз, Linux передает их через второй интерфейс, а узел в подсети B возвращает ответы через маршрут к 192.168.10.0/24. Для связи между управляемыми подсетями NAT обычно не нужен: достаточно корректной маршрутизации в обе стороны.

Быстро сверить команды ip route, правила firewall и policy routing можно в шпаргалке по маршрутизации трафика в Linux. Ниже приведена самостоятельная схема для лабораторной сети, небольшого офиса или тестового стенда.

Рабочая схема маршрутизации между подсетями

Минимальная конфигурация состоит из четырех элементов:

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

Если отсутствует хотя бы один элемент, локальная связь с адресами самого Linux-сервера может работать, а обмен между клиентами останется недоступным.

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

УзелИнтерфейсIP-адресПодсетьШлюз
Linux-серверens18192.168.10.1/24192.168.10.0/24не требуется для связи с подсетью B
Linux-серверens19192.168.20.1/24192.168.20.0/24не требуется для связи с подсетью A
Клиент Aeth0192.168.10.10/24192.168.10.0/24192.168.10.1 для подсети B
Клиент Beth0192.168.20.10/24192.168.20.0/24192.168.20.1 для подсети A

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

Проверьте адреса на сервере:

ip -br addr
ip link
ip route

Ожидаемый результат содержит два подключенных интерфейса и два маршрута с признаком proto kernel, например:

192.168.10.0/24 dev ens18 proto kernel scope link src 192.168.10.1
192.168.20.0/24 dev ens19 proto kernel scope link src 192.168.20.1

Адрес шлюза клиента должен принадлежать его локальной подсети. Клиент с адресом 192.168.10.10/24 использует 192.168.10.1, а клиент с адресом 192.168.20.10/24 использует 192.168.20.1.

Что проверить до настройки

  • Уточните реальные имена интерфейсов командой ip -br link. В разных системах это могут быть ens18, enp1s0, eth0 или VLAN-устройства.
  • Проверьте состояние линка. Интерфейс должен иметь статус UP.
  • Убедитесь, что IP-адреса не повторяются в сети.
  • С Linux-сервера проверьте доступность адресов клиентов и локальных шлюзов.
  • Определите сетевой стек, который управляет конфигурацией: NetworkManager, systemd-networkd, Netplan или другой менеджер.

Команда ip route показывает маршруты самого сервера, но не конфигурацию клиентов. Наличие двух connected-маршрутов на Linux еще не означает, что клиентская машина отправит ответ через этот сервер.

Включить IP forwarding в Linux

По умолчанию Linux обычно не пересылает IPv4-пакеты между интерфейсами. Сервер принимает пакет, адресованный ему, но не передает транзитный пакет в другой сегмент. За пересылку отвечает параметр net.ipv4.ip_forward.

Временное включение пересылки пакетов

Для первичной проверки включите forwarding до перезагрузки:

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

Вторая команда должна вывести:

net.ipv4.ip_forward = 1

Этот способ удобен для лабораторного теста. После перезапуска системы параметр может вернуться к значению 0.

Постоянная настройка через sysctl

Создайте отдельный файл конфигурации:

sudo sh -c 'printf "net.ipv4.ip_forward = 1\n" > /etc/sysctl.d/99-router.conf'

Примените параметры:

sudo sysctl --system
sysctl net.ipv4.ip_forward

Отдельный файл в /etc/sysctl.d проще сопровождать, чем изменение общего /etc/sysctl.conf. Проверьте, нет ли других файлов с тем же параметром: позднее значение может переопределить раннюю настройку.

Для IPv6 используется отдельный параметр:

sudo sysctl -w net.ipv6.conf.all.forwarding=1
sysctl net.ipv6.conf.all.forwarding

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

Разрешить межсетевой трафик в firewall

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

Проверьте, какой firewall уже используется. Не смешивайте независимые наборы правил без понимания порядка обработки пакетов, особенно если iptables работает через совместимый слой nftables.

Настройка маршрутизации через iptables

Ниже пример для схемы из двух интерфейсов. Он разрешает новые соединения из подсети A в подсеть B и пропускает ответы в обратном направлении:

sudo iptables -A FORWARD \
  -i ens18 -o ens19 \
  -s 192.168.10.0/24 -d 192.168.20.0/24 \
  -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

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

Если клиентам требуется инициировать соединения в обе стороны, добавьте симметричное правило для новых соединений:

sudo iptables -A FORWARD \
  -i ens19 -o ens18 \
  -s 192.168.20.0/24 -d 192.168.10.0/24 \
  -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

Проверьте политику и счетчики:

sudo iptables -L FORWARD -n -v --line-numbers

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

Настройка маршрутизации через nftables

Пример минимальной IPv4-конфигурации с отслеживанием состояний:

table ip router_filter {
    chain forward {
        type filter hook forward priority filter; policy drop;

        iifname "ens18" oifname "ens19" \
            ip saddr 192.168.10.0/24 \
            ip daddr 192.168.20.0/24 \
            ct state new,established,related accept

        iifname "ens19" oifname "ens18" \
            ip saddr 192.168.20.0/24 \
            ip daddr 192.168.10.0/24 \
            ct state established,related accept
    }
}

Для двусторонней инициации соединений добавьте отдельное правило, разрешающее ct state new из подсети B в подсеть A. Ограничение по интерфейсам и адресным диапазонам снижает риск случайного транзита чужого трафика.

Просмотрите активный набор правил:

sudo nft list ruleset

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

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

Когда нужен NAT, а когда достаточно маршрутов

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

Masquerade оправдан в двух типичных случаях:

  • удаленная сеть не позволяет добавить маршрут обратно к исходной подсети;
  • Linux-сервер работает шлюзом в интернет, и внешний интерфейс получает динамический адрес.

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

Добавить маршруты на клиентах

Клиент в подсети A должен знать, что сеть 192.168.20.0/24 доступна через 192.168.10.1. Клиент в подсети B должен отправлять сеть 192.168.10.0/24 через 192.168.20.1. Без второго маршрута запрос может дойти до адресата, но ответ уйдет через другой шлюз.

Временный статический маршрут через ip route

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

sudo ip route add 192.168.20.0/24 via 192.168.10.1
ip route show 192.168.20.0/24

На клиенте B добавьте обратный маршрут:

sudo ip route add 192.168.10.0/24 via 192.168.20.1
ip route show 192.168.10.0/24

Удалить временный маршрут можно так:

sudo ip route del 192.168.20.0/24
sudo ip route del 192.168.10.0/24

Маршруты через ip route обычно действуют до перезагрузки или перезапуска сетевого соединения. Для постоянной настройки внесите их в конфигурацию сетевого менеджера.

Постоянные маршруты через NetworkManager

Сначала узнайте имя подключения:

nmcli connection show

На клиенте A добавьте маршрут:

sudo nmcli connection modify "LAN-A" +ipv4.routes "192.168.20.0/24 192.168.10.1"
sudo nmcli connection up "LAN-A"

На клиенте B используйте обратное направление:

sudo nmcli connection modify "LAN-B" +ipv4.routes "192.168.10.0/24 192.168.20.1"
sudo nmcli connection up "LAN-B"

Проверьте таблицу маршрутов:

ip route
nmcli connection show "LAN-A"

Замените имена LAN-A и LAN-B на реальные профили. Если NetworkManager не управляет интерфейсом, изменение его профиля не повлияет на рабочую сеть.

Постоянные маршруты через systemd-networkd

В файле соответствующего интерфейса добавьте секцию маршрута. Например, для клиента A:

[Match]
Name=eth0

[Network]
Address=192.168.10.10/24

[Route]
Destination=192.168.20.0/24
Gateway=192.168.10.1

Для клиента B укажите адрес интерфейса 192.168.20.10/24, назначение 192.168.10.0/24 и шлюз 192.168.20.1. После изменения перезапустите службу:

sudo systemctl restart systemd-networkd
ip route

Путь к конфигурационным файлам и набор активных секций зависят от принятой схемы systemd-networkd. Перед перезапуском сохраните текущие адреса и убедитесь, что у вас есть консольный доступ.

Проверить обмен трафиком между подсетями

Диагностируйте проблему по уровням: физическое состояние интерфейсов, адресация, маршрут, forwarding, firewall, наличие ответа и MTU. Проверка только командой ping не показывает, на каком этапе пропал пакет.

Проверка маршрута и состояния ядра

На Linux-сервере проверьте, какой путь ядро выберет к клиенту B:

ip route get 192.168.20.10
sysctl net.ipv4.ip_forward

Ожидаемый результат ip route get должен указывать интерфейс ens19 и исходный адрес 192.168.20.1. Если маршрут отсутствует или выбран другой интерфейс, исправляйте адресацию и таблицу маршрутизации до проверки firewall.

Проверьте локальные адреса с обеих сторон:

ping -c 3 192.168.10.1
ping -c 3 192.168.20.1

Эти команды подтверждают связь клиента с адресами маршрутизатора. Они не подтверждают прохождение транзитного трафика между клиентами.

Проверка firewall и счетчиков правил

Для iptables выполните:

sudo iptables -L FORWARD -n -v --line-numbers

Для nftables:

sudo nft list ruleset

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

ICMP, TCP и UDP могут фильтроваться разными правилами. Неудачный ping не доказывает, что TCP-сервис недоступен. Проверьте конкретный порт:

nc -vz 192.168.20.10 22
ss -tn

Команда nc должна выполняться на клиенте A, а порт замените на реально работающий сервис клиента B.

Наблюдение за пакетами через tcpdump

Запустите захват на входном интерфейсе Linux-сервера:

sudo tcpdump -ni ens18 'host 192.168.10.10 and host 192.168.20.10'

Одновременно просматривайте выходной интерфейс:

sudo tcpdump -ni ens19 'host 192.168.10.10 and host 192.168.20.10'

Интерпретация результата:

  • пакет не виден на ens18, проблема находится между клиентом A и сервером;
  • пакет виден на ens18, но отсутствует на ens19, проверяйте forwarding, маршрут и цепочку FORWARD;
  • пакет выходит через ens19, но ответа нет, проверяйте адрес клиента B и его firewall;
  • ответ приходит на ens19, но не появляется на ens18, ищите обратный маршрут, фильтрацию или reverse path filtering.

Для проверки маршрута между узлами используйте:

traceroute -n 192.168.20.10
tracepath 192.168.20.10

tracepath дополнительно помогает обнаружить проблемы с максимальным размером пакета и Path MTU.

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

Трафик проходит только в одну сторону

Чаще всего на одной стороне отсутствует обратный маршрут. Проверьте на клиенте B:

ip route get 192.168.10.10

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

Проверьте и обратное правило firewall. Для stateful-фильтрации обычно требуется ESTABLISHED,RELATED. Захват через tcpdump покажет, возвращается ли ответ на Linux-сервер.

Пакеты не проходят через сервер

  • Проверьте sysctl net.ipv4.ip_forward. Значение должно быть 1.
  • Проверьте политики и счетчики цепочки FORWARD.
  • Сверьте имена интерфейсов в firewall с результатом ip -br link.
  • Убедитесь, что сервер имеет маршруты к обеим подсетям.
  • Проверьте VLAN, bridge, физический линк и маски адресов.

Проверка ping до 192.168.10.1 и 192.168.20.1 подтверждает доступ к самому серверу, но не прохождение пакета между клиентами.

Маршрутизация исчезает после перезагрузки

Команды sysctl -w и ip route add меняют текущую систему. Сохраните forwarding в /etc/sysctl.d/99-router.conf, маршруты в профиле NetworkManager или файле systemd-networkd, а правила firewall в конфигурации соответствующего сервиса.

После перезагрузки проверьте:

sysctl net.ipv4.ip_forward
ip route
sudo nft list ruleset
sudo iptables -L FORWARD -n -v

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

Проверка reverse path filtering и MTU

Reverse path filtering, или rp_filter, проверяет, что обратный маршрут к источнику пакета соответствует интерфейсу, через который пакет пришел. В асимметричных схемах, при нескольких uplink, VLAN и туннелях строгая проверка может отбрасывать легитимный трафик.

Проверьте текущие значения:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.ens18.rp_filter
sysctl net.ipv4.conf.ens19.rp_filter

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

Проблемы MTU проявляются как зависание TCP-соединений, передача небольших пакетов при потере крупных и ошибки при работе через туннель. Проверьте путь:

tracepath 192.168.20.10

Сверьте MTU на интерфейсах, VLAN и туннелях. Значения должны соответствовать реальному пути передачи пакетов.

При сложной схеме с несколькими uplink полезно изучить диагностику асимметричной маршрутизации, где разобраны PBR, stateful-firewall и сохранение привязки сессий.

Итоговая последовательность настройки

  1. Определите адресный план и назначьте разные подсети каждому интерфейсу Linux-сервера.
  2. Проверьте link state, IP-адреса, маски и connected-маршруты.
  3. Включите net.ipv4.ip_forward=1 и убедитесь, что ядро применило параметр.
  4. Выберите один основной firewall, настройте цепочку FORWARD и ограничьте правила интерфейсами, источниками и назначениями.
  5. Добавьте маршрут к удаленной подсети на клиентах обеих сторон.
  6. Проверьте ping, конкретное TCP-соединение, ip route get и traceroute.
  7. При сбое запустите tcpdump на обоих интерфейсах Linux-сервера.
  8. Сохраните sysctl, маршруты и правила firewall, затем повторите тест после перезагрузки.

Минимальный чеклист перед вводом в эксплуатацию

  • На сервере есть адрес из каждой подсети.
  • На сервере включен IPv4 forwarding.
  • В firewall разрешен транзит через FORWARD.
  • На клиентах настроены маршруты в обе стороны.
  • Обратный путь симметричен или его особенности документированы.
  • NAT отсутствует, если для него нет отдельной причины.
  • Правила ограничены нужными подсетями и сервисами.
  • Настройки переживают перезапуск.
  • Проверены журналы firewall, MTU и состояние VLAN.

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

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

Поделиться:
Сохранить гайд? В закладки браузера