Создание маршрутизатора на Debian и Ubuntu: пошаговая настройка | AdminWiki
Logo

Создание маршрутизатора на Debian и Ubuntu: пошаговая настройка

07 сентября 2026 17 мин. чтения
Содержание статьи

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

Чтобы превратить сервер на Debian или Ubuntu в маршрутизатор, подключите к нему минимум два сетевых интерфейса либо разделите сети с помощью VLAN, назначьте адреса WAN- и LAN-сегментам, задайте маршрут по умолчанию и включите пересылку пакетов. Для IPv4 используется параметр net.ipv4.ip_forward=1, для IPv6 - net.ipv6.conf.all.forwarding=1.

Рабочий порядок такой: определить топологию и имена интерфейсов, выбрать активный сетевой менеджер, настроить Netplan или systemd-networkd, включить forwarding, добавить постоянные маршруты, при необходимости настроить NAT и правила nftables, затем проверить соединение с клиента и повторить тест после перезагрузки.

Одного forwarding недостаточно. Ядро должно найти маршрут до сети назначения, соседний маршрутизатор должен знать обратный путь, а firewall должен разрешать пересылку нужного трафика. Ниже используется пример с WAN enp1s0 и LAN enp2s0. Имена интерфейсов, адреса, префиксы и шлюзы замените на значения из своей схемы.

Перед настройкой: схема сети и безопасный доступ к серверу

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

ПараметрПримерНазначение
WAN-интерфейсenp1s0Внешняя сеть
WAN IPv4192.0.2.10/24Адрес маршрутизатора во внешнем сегменте
WAN gateway192.0.2.1Шлюз по умолчанию
LAN-интерфейсenp2s0Внутренняя сеть
LAN IPv410.10.0.1/24Шлюз для клиентов LAN
WAN IPv62001:db8:100::10/64Статический адрес во внешней IPv6-сети
LAN IPv62001:db8:200::1/64Адрес маршрутизатора во внутренней IPv6-сети

Префиксы 192.0.2.0/24 и 2001:db8::/32 предназначены для документационных примеров. В рабочей сети используйте адреса, выданные провайдером или администратором инфраструктуры.

Как определить сетевые интерфейсы и текущую конфигурацию

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

ip link
ip -br addr
ip route
ip -6 route
ip route show default
ip -6 route show default

В выводе сопоставьте физические порты с именами Linux. Интерфейс с текущим маршрутом по умолчанию обычно подключен к WAN, но окончательное решение принимайте по схеме коммутации. Если сервер доступен по SSH через внешний интерфейс, его перезапуск или смена адреса может разорвать текущую сессию.

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

  • Имена WAN- и LAN-интерфейсов, например enp1s0 и enp2s0.
  • IPv4- и IPv6-адреса с префиксами для каждого сегмента.
  • Шлюз по умолчанию и способ получения адреса WAN: статический адрес или DHCP.
  • DNS-серверы, доступные маршрутизатору.
  • Сети назначения и next-hop для статических маршрутов.
  • Нужен ли NAT для выхода частных адресов в интернет.
  • Разрешенные направления и протоколы: TCP, UDP, ICMP, ICMPv6.
  • Способ восстановления доступа: локальная консоль, IPMI, виртуальная консоль или другой out-of-band канал.

Сохраните текущие файлы конфигурации и результаты команд ip -br addr и ip route. Для тестового стенда с отдельными виртуальными сетями можно использовать облачный сервер, например Timeweb Cloud, если правила компании разрешают размещение такого окружения.

Выбор инструмента: Netplan или systemd-networkd

Debian и Ubuntu могут использовать разные компоненты для управления сетью. В Ubuntu Netplan часто выступает декларативным слоем: он читает YAML из /etc/netplan/ и передает параметры выбранному backend, например systemd-networkd или NetworkManager. В Debian systemd-networkd удобно настраивать напрямую, если сервис включен и выбран основным.

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

Как определить активный сетевой менеджер

Проверьте состояние сервисов и список устройств, которыми управляет networkd:

systemctl is-active systemd-networkd
systemctl is-enabled systemd-networkd
systemctl is-active NetworkManager
systemctl is-enabled NetworkManager
systemctl is-active networking
networkctl list
ls -l /etc/netplan/
ls -l /etc/systemd/network/

Если изменения применяет Netplan, изучите YAML-файлы в /etc/netplan/ и значение renderer. Если интерфейс обслуживает systemd-networkd напрямую, ищите файлы с расширением .network в /etc/systemd/network/. Журналы выбранного сервиса помогут связать ошибку конфигурации с конкретным интерфейсом.

journalctl -u systemd-networkd -b --no-pager
journalctl -u NetworkManager -b --no-pager
systemctl status networking --no-pager

Когда использовать Netplan в Ubuntu

Netplan подходит для Ubuntu, где сетевые параметры уже описываются YAML-файлами. Основной каталог - /etc/netplan/. Файл /etc/netplan/01-netcfg.yaml подходит для примера, но в системе уже могут находиться файлы с другим именем. Netplan объединяет их по правилам приоритета, поэтому проверьте весь каталог.

Изменяйте исходный YAML, а не сгенерированные файлы в /run/systemd/network/. Синтаксис YAML чувствителен к отступам: используйте пробелы, а не табуляцию. Команда netplan generate проверяет генерацию конфигурации, а netplan try дает возможность подтвердить изменения и автоматически вернуться к предыдущему состоянию при отсутствии подтверждения.

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

Когда использовать systemd-networkd в Debian и Ubuntu

Прямой systemd-networkd удобен на сервере без графической оболочки и дополнительных сетевых менеджеров. Файлы с расширением .network размещают в /etc/systemd/network/. Секция [Match] выбирает интерфейс, а секция [Network] задает адреса, шлюз, DNS и связанные параметры. Статические маршруты описывают секциями [Route] в том же файле.

После изменения файлов проверьте состояние через networkctl, а ошибки чтения конфигурации ищите в журнале:

networkctl list
networkctl status enp1s0
networkctl status enp2s0
journalctl -u systemd-networkd -b --no-pager

Настройка сетевых интерфейсов маршрутизатора

В примере WAN получает статический IPv4-адрес и IPv6-адрес, а LAN использует отдельные префиксы. Маршрут по умолчанию задается на WAN. Клиенты LAN должны использовать 10.10.0.1 как IPv4 gateway и адрес маршрутизатора в IPv6-сегменте как IPv6 next-hop, полученный статически или через Router Advertisement.

Настройка интерфейсов через Netplan

Создайте или измените файл /etc/netplan/01-netcfg.yaml. Пример ниже использует backend systemd-networkd и статическую адресацию:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.0.2.10/24
        - 2001:db8:100::10/64
      routes:
        - to: default
          via: 192.0.2.1
        - to: ::/0
          via: 2001:db8:100::1
      nameservers:
        addresses:
          - 192.0.2.1
    enp2s0:
      dhcp4: false
      dhcp6: false
      addresses:
        - 10.10.0.1/24
        - 2001:db8:200::1/64

На LAN намеренно нет шлюза по умолчанию. Иначе система может получить несколько конкурирующих default route. Шлюз клиентов указывает на LAN-адрес маршрутизатора, а внешний default route ведет через 192.0.2.1 и 2001:db8:100::1.

Если провайдер выдает WAN через DHCP, замените статические адреса и маршруты на соответствующие параметры:

enp1s0:
  dhcp4: true
  dhcp6: true
  nameservers:
    addresses:
      - 192.0.2.1

В таком случае адрес и маршрут по умолчанию приходят от DHCP. Не добавляйте ручной default route, пока не проверили фактический вывод ip route и ip -6 route.

Проверьте YAML перед применением:

sudo netplan generate
sudo netplan try
sudo netplan apply
ip -br addr
ip route
ip -6 route

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

Настройка интерфейсов через systemd-networkd

Для прямой настройки networkd создайте два файла. WAN-конфигурация /etc/systemd/network/10-wan.network:

[Match]
Name=enp1s0

[Network]
Address=192.0.2.10/24
Address=2001:db8:100::10/64
Gateway=192.0.2.1
Gateway=2001:db8:100::1
DNS=192.0.2.1
IPv6AcceptRA=no

Параметр IPv6AcceptRA=no подходит для статического WAN, где шлюз и адрес заданы вручную. Если провайдер передает IPv6-префикс и маршрут через Router Advertisement, этот параметр нужно согласовать с реальной схемой, иначе система не получит нужные объявления.

LAN-конфигурация /etc/systemd/network/20-lan.network:

[Match]
Name=enp2s0

[Network]
Address=10.10.0.1/24
Address=2001:db8:200::1/64

Файл LAN не содержит Gateway=. Маршрутизатор автоматически создает connected route для локальных подсетей. Для IPv6-клиентов дополнительно нужен корректный Router Advertisement или статическая настройка адреса и маршрута на клиенте. Сам параметр forwarding не сообщает клиенту, куда отправлять IPv6-пакеты.

Включите networkd, перечитайте конфигурацию и примените ее к интерфейсам:

sudo systemctl enable --now systemd-networkd
sudo networkctl reload
sudo networkctl reconfigure enp1s0
sudo networkctl reconfigure enp2s0
networkctl status enp1s0
networkctl status enp2s0

Перезапуск systemd-networkd тоже применит параметры, но может оборвать SSH. После изменения default route проверяйте таблицу маршрутизации и доступ к шлюзу.

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

  1. Откройте вторую SSH-сессию и оставьте первую активной.
  2. Сохраните исходные файлы с понятным именем резервной копии.
  3. Проверьте имя интерфейса командой ip link до редактирования YAML или .network.
  4. Применяйте Netplan через netplan try, а networkd - через networkctl reload и networkctl reconfigure.
  5. Проверьте адреса, маршрут по умолчанию и доступ к шлюзу сразу после изменения.
  6. Для удаленного production-сервера заранее подготовьте локальную консоль или out-of-band доступ.

Если меняется только дополнительный маршрут, риск обычно ниже. Смена адреса WAN, LAN или default route может сделать текущий SSH-адрес недоступным.

Как включить IP forwarding в Debian и Ubuntu

Linux принимает пакеты, адресованные самому серверу, без специальной настройки. Для передачи пакета между интерфейсами требуется включить forwarding в ядре. IPv4 и IPv6 используют разные параметры sysctl, поэтому их проверяют отдельно.

Временная проверка пересылки IPv4 и IPv6

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

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

Ожидаемое значение для каждого параметра - 1. После этого проверьте маршрут до удаленного адреса на маршрутизаторе и попробуйте соединение с клиента LAN. Если тест успешен, сохраните параметры в постоянной конфигурации.

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

Создайте файл /etc/sysctl.d/99-router.conf:

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Загрузите параметры и убедитесь, что ядро приняло их:

sudo sysctl --system
sysctl -n net.ipv4.ip_forward
sysctl -n net.ipv6.conf.all.forwarding

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

Особенности IPv6 forwarding

IPv6 forwarding не включается автоматически вместе с IPv4. Для него нужны собственный параметр, маршруты с IPv6-префиксами и обратная маршрутизация. У вышестоящего маршрутизатора должен существовать путь к LAN-префиксу 2001:db8:200::/64 через WAN-адрес этого сервера.

После включения IPv6 forwarding Linux может изменить поведение Router Advertisement. Если WAN получает маршрут через RA, проверьте параметр net.ipv6.conf.enp1s0.accept_ra и настройки networkd. На LAN-клиентах проверьте наличие IPv6 default route. Адрес на интерфейсе маршрутизатора сам по себе такой маршрут клиенту не создает.

Постоянные маршруты для Debian и Ubuntu

Маршрут описывает сеть назначения, префикс, next-hop или выходной интерфейс и, при необходимости, метрику. Маршрут по умолчанию используется, когда более точного пути нет. Статический маршрут до 10.20.0.0/24 нужен только при наличии реального соседнего маршрутизатора или другого интерфейса, через который достижима эта сеть.

Для маршрутизации между двумя управляемыми подсетями обратный маршрут обязателен. Если узел из сети 10.20.0.0/24 отвечает в LAN, его gateway или промежуточный маршрутизатор должны знать путь к 10.10.0.0/24. NAT может скрыть отсутствие обратного маршрута для интернет-доступа, но для связанных внутренних сетей лучше описать маршруты явно.

Проверка маршрутов командами ip route и ip -6 route

Сначала посмотрите обе таблицы:

ip route show
ip -6 route show
ip route show table main
ip -6 route show table main
ip route get 10.20.0.10
ip -6 route get 2001:db8:300::10

В результате ip route get указывает выбранный интерфейс, next-hop и исходный адрес. Это быстрее, чем анализировать всю таблицу, когда нужно понять путь к одному узлу. Сравните вывод с топологией: WAN default route должен вести на внешний gateway, а маршрут к внутренней сети - через интерфейс или соседний маршрутизатор в том же сегменте.

Команды ip route add и ip -6 route add подходят для краткого теста. Они не переживают перезагрузку и перезапуск сетевого менеджера:

sudo ip route replace 10.20.0.0/24 via 10.10.0.254 dev enp2s0
sudo ip -6 route replace 2001:db8:300::/64 via 2001:db8:200::fe dev enp2s0
sudo ip route del 10.20.0.0/24

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

Подробные варианты команд ip route и сохранения маршрутов собраны в практическом руководстве по статическим маршрутам в Linux.

Постоянные маршруты в Netplan

В Netplan постоянный маршрут размещают в блоке интерфейса, через который доступен next-hop. Фрагмент для сети 10.20.0.0/24 выглядит так:

enp2s0:
  addresses:
    - 10.10.0.1/24
  routes:
    - to: 10.20.0.0/24
      via: 10.10.0.254
      metric: 100
    - to: 2001:db8:300::/64
      via: 2001:db8:200::fe
      metric: 100

Добавьте этот блок к общей конфигурации, проверьте отступы и примените изменения:

sudo netplan generate
sudo netplan try
sudo netplan apply
ip route get 10.20.0.10
ip -6 route get 2001:db8:300::10

Значение via должно находиться в сети, непосредственно подключенной к выбранному интерфейсу. Например, gateway 10.10.0.254 достижим через enp2s0, потому что этот интерфейс имеет адрес 10.10.0.1/24. Для нестандартного next-hop может потребоваться флаг on-link, но его добавляют только при подтвержденной топологии.

Если нужны policy routing, разные таблицы и правила ip rule, используйте отдельную схему вместо набора конкурирующих default route. Это помогает разделять трафик по источнику, интерфейсу или маркировке.

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

В networkd маршрут добавляют в соответствующий .network-файл. Для маршрута через соседний маршрутизатор на LAN измените /etc/systemd/network/20-lan.network:

[Match]
Name=enp2s0

[Network]
Address=10.10.0.1/24
Address=2001:db8:200::1/64

[Route]
Destination=10.20.0.0/24
Gateway=10.10.0.254
Metric=100

[Route]
Destination=2001:db8:300::/64
Gateway=2001:db8:200::fe
Metric=100

После перечитывания конфигурации проверьте маршрут:

sudo networkctl reload
sudo networkctl reconfigure enp2s0
networkctl status enp2s0
ip route
ip -6 route

Секция [Route] привязана к интерфейсу из того же файла. Если next-hop недостижим, networkd может не установить маршрут или ядро не сможет передать ему пакет. Проверяйте соседний адрес командой ping или ping -6 до диагностики удаленной сети.

Для сравнения вариантов Netplan, networkd и классического iproute2 пригодится руководство по маршрутизации в Linux с ip route, Netplan и systemd-networkd.

NAT и firewall: что требуется для доступа из LAN

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

Для связи между двумя сетями NAT не требуется, если все маршрутизаторы знают обратные пути. Например, при маршрутизации между 10.10.0.0/24 и 10.20.0.0/24 сохранение исходных адресов упрощает аудит, фильтрацию и диагностику.

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

В IPv6 обычно маршрутизируют глобальный префикс без NAT. Провайдер или вышестоящий маршрутизатор должен направить LAN-префикс на этот сервер. Если такого маршрута нет, включенный IPv6 forwarding не обеспечит доступ.

Проверка правил nftables для forwarding

Пример минимального набора правил для лабораторной схемы:

table inet router_filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iifname "enp2s0" oifname "enp1s0" ip saddr 10.10.0.0/24 accept
    iifname "enp2s0" oifname "enp1s0" ip6 saddr 2001:db8:200::/64 accept
  }
}

table ip router_nat {
  chain postrouting {
    type nat hook postrouting priority 100; policy accept;
    oifname "enp1s0" ip saddr 10.10.0.0/24 masquerade
  }
}

Цепочка forward разрешает established и related-соединения, затем пропускает трафик из LAN в WAN. Цепочка NAT маскирует только IPv4-адреса внутренней сети при выходе через enp1s0. Правило с широкой политикой accept подходит для первичной проверки, но в рабочей среде задайте разрешения по нужной политике. Например, явно разрешите TCP-порты 80 и 443, DNS по UDP и TCP на порту 53, ICMP и ICMPv6 для диагностики.

Проверьте загруженные правила:

sudo nft list ruleset
sudo nft list chain inet router_filter forward
sudo nft list table ip router_nat

Если правило уже существует, объедините его с текущим набором вместо создания второй конкурирующей цепочки. После проверки сохраните конфигурацию в /etc/nftables.conf и включите загрузку правил при старте:

sudo nft -f /etc/nftables.conf
sudo systemctl enable nftables
sudo systemctl start nftables

Не отключайте firewall как постоянный способ диагностики. Сначала проверьте счетчики правил, policy цепочки и наличие обратного трафика. Для входящих соединений к самому маршрутизатору действует цепочка input, а для транзитных пакетов - forward. Это разные уровни фильтрации.

Проверка маршрутизатора после настройки и перезагрузки

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

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

ip link show enp1s0
ip link show enp2s0
ip -br addr
networkctl status enp1s0
networkctl status enp2s0

Состояние интерфейса должно быть UP или routable в выводе networkd. На WAN проверьте адрес и маршрут к внешнему gateway. На LAN проверьте адрес 10.10.0.1/24 и IPv6-префикс, если он используется. Отсутствующий адрес указывает на проблему сетевого менеджера или конфигурационного файла, а не на firewall.

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

ip route
ip -6 route
ip route get 1.1.1.1
ip -6 route get 2001:4860:4860::8888
sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

Проверьте наличие connected route для каждой локальной сети и default route на WAN. Для удаленной сети команда ip route get должна показать правильный интерфейс и next-hop. Значение forwarding для IPv4 и IPv6 должно быть равно 1.

Проверьте доступность соседних шлюзов до сквозного теста:

ping -c 4 192.0.2.1
ping -c 4 10.10.0.254
ping -6 -c 4 2001:db8:100::1
ping -6 -c 4 2001:db8:200::fe

Сквозной тест с клиента

На клиенте LAN проверьте три уровня соединения:

  1. Адрес маршрутизатора: ping -c 4 10.10.0.1.
  2. Соседний узел или gateway во внешнем сегменте, если он доступен для проверки.
  3. Удаленный узел через IPv4 и IPv6, например ping -4 -c 4 1.1.1.1 и ping -6 -c 4 2001:4860:4860::8888.

Посмотрите маршрут, который видит клиент:

ip route
ip -6 route
tracepath -4 1.1.1.1
tracepath -6 2001:4860:4860::8888

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

При спорном результате снимите трафик на обоих интерфейсах:

sudo tcpdump -ni enp2s0 host 10.10.0.20
sudo tcpdump -ni enp1s0 host 1.1.1.1

Пакет на LAN и его отсутствие на WAN указывает на forwarding или firewall. Пакет на обоих интерфейсах без ответа требует проверки внешнего gateway, NAT и обратного пути.

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

Перезагрузка обязательна, если вы проверяете постоянную конфигурацию. Перед ней убедитесь, что у вас есть консольный доступ и сохранены файлы Netplan, networkd, sysctl и nftables.

sudo reboot

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

ip -br addr
ip route
ip -6 route
sysctl -n net.ipv4.ip_forward
sysctl -n net.ipv6.conf.all.forwarding
sudo nft list ruleset
networkctl status enp1s0
networkctl status enp2s0

Затем выполните сквозной тест с клиента. Конфигурация считается сохраненной, когда после reboot автоматически восстанавливаются адреса, маршруты, forwarding, правила NAT и доступ между сетями.

При сбое изучите журналы текущей загрузки:

journalctl -b -u systemd-networkd --no-pager
journalctl -b -k --no-pager
systemctl status nftables --no-pager

Диагностика типовых проблем

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

Проверьте физическое подключение, имя устройства и состояние линка:

ip link
ip -br link
networkctl list

Для Netplan частые причины - ошибка отступов YAML, неверное имя интерфейса, файл в другом каталоге или конфликт нескольких YAML-файлов. Запустите netplan generate и изучите сообщение об ошибке. Для systemd-networkd проверьте секцию [Match]: значение Name=enp1s0 должно точно совпадать с именем из ip link.

Проверьте права доступа и журнал:

ls -l /etc/netplan/
ls -l /etc/systemd/network/
journalctl -u systemd-networkd -b --no-pager

Если активен NetworkManager, а конфигурация рассчитана на networkd, сначала определите владельца интерфейса и выберите один backend. Ручная команда ip addr add может временно скрыть проблему, но после перезапуска сервиса адрес исчезнет.

Пакеты не проходят через маршрутизатор

Разделите проверку на четыре пункта:

  1. У клиента есть адрес в LAN и default gateway 10.10.0.1.
  2. На маршрутизаторе включены net.ipv4.ip_forward и net.ipv6.conf.all.forwarding.
  3. Команды ip route get и ip -6 route get выбирают ожидаемые интерфейс и next-hop.
  4. nftables разрешает нужный трафик в цепочке forward, а для IPv4 при выходе частной сети настроен masquerade.

Для внутренних сетей проверьте обратный маршрут на вышестоящем маршрутизаторе. Если он не знает путь к 10.10.0.0/24 или 2001:db8:200::/64, ответы не вернутся к клиенту. Для IPv6 проверьте Router Advertisement и наличие default route на клиенте.

Счетчики nftables показывают, какое правило обрабатывает пакеты. Если счетчик разрешающего правила не растет, пакет идет через другой интерфейс или его блокирует предыдущая цепочка.

Конфигурация работает до перезагрузки, но исчезает после нее

Сравните временное состояние с постоянными файлами:

ip -br addr
ip route
ip -6 route
sysctl -a 2>/dev/null | grep -E 'net.ipv4.ip_forward|net.ipv6.conf.all.forwarding'
find /etc/netplan /etc/systemd/network /etc/sysctl.d -maxdepth 2 -type f -print

Маршрут, добавленный через ip route add, не сохраняется. Forwarding, заданный через sysctl -w, тоже требует записи в /etc/sysctl.d/. Правила nftables должны загружаться сервисом nftables из постоянного файла. Адреса и маршруты должны находиться в активной конфигурации Netplan или systemd-networkd, а не только в текущем выводе команды ip.

Проверьте порядок запуска и журналы:

systemctl is-enabled systemd-networkd
systemctl is-enabled nftables
journalctl -b -u systemd-networkd --no-pager
journalctl -b -u nftables --no-pager

После изменения сети потерян SSH-доступ

Подключитесь через локальную консоль или out-of-band управление. Проверьте, поднят ли интерфейс, сохранился ли ожидаемый адрес и есть ли маршрут по умолчанию:

ip link
ip -br addr
ip route
systemctl status systemd-networkd --no-pager
systemctl status nftables --no-pager

Если причина в Netplan, верните рабочий YAML из резервной копии через консоль и выполните netplan try. Если причина в networkd, временно исправьте соответствующий файл в /etc/systemd/network/, перечитайте конфигурацию и проверьте адрес. При блокировке firewall изучите цепочки input и forward, потому что доступ к самому серверу и транзитный трафик фильтруются раздельно.

Следующее изменение выполняйте из двух SSH-сессий или через консоль. Перед сменой адреса и default route сохраняйте текущий рабочий вариант.

При нескольких провайдерах, асимметричных путях, Kubernetes CNI или разных шлюзах для разных источников обычной таблицы main может быть недостаточно. Для такой схемы используйте policy routing с ip rule, отдельными таблицами и проверкой через ip route get. Практический пример такой конфигурации приведен в руководстве по policy routing на Linux-сервере.

Контрольный критерий: после перезагрузки WAN и LAN имеют ожидаемые адреса, таблицы IPv4 и IPv6 содержат нужные маршруты, оба forwarding-параметра равны 1, nftables пропускает разрешенный forward-трафик, а клиент достигает удаленной сети.
Поделиться:
Сохранить гайд? В закладки браузера