Маршрутизация в Debian 2026 без NetworkManager: шлюз и статические маршруты

В Debian без NetworkManager временный маршрут добавляют командой ip route add, а постоянную конфигурацию сохраняют в файле, который использует активный сетевой менеджер. Для классической схемы с ifupdown это обычно /etc/network/interfaces. Если интерфейс обслуживает systemd-networkd, маршрут задают в файле с расширением .network.

Базовый пример маршрута до удаленной сети выглядит так:

sudo ip route add 10.20.0.0/16 via 192.168.1.1 dev ens18

Здесь 10.20.0.0/16 - сеть назначения, 192.168.1.1 - шлюз, а ens18 - интерфейс, через который доступен следующий узел. Команда действует до перезапуска сети или системы. Для постоянной настройки нужно перенести параметры в конфигурацию ifupdown или systemd-networkd.

Как добавить маршрут в Debian без NetworkManager

Утилита ip входит в пакет iproute2 и служит основным инструментом управления маршрутами в Debian. Она изменяет таблицу ядра сразу, поэтому подходит для проверки сетевой схемы перед записью постоянных параметров.

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

sudo ip route add NETWORK/CIDR via GATEWAY dev INTERFACE

Например, сервер находится в сети 192.168.1.0/24, шлюз имеет адрес 192.168.1.1, а удаленная сеть использует диапазон 10.20.0.0/16:

sudo ip route add 10.20.0.0/16 via 192.168.1.1 dev ens18
ip route show

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

Минимальный пример временного маршрута

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

sudo ip route add 172.16.40.0/24 via 192.168.1.1 dev ens18

Проверьте запись:

ip route show 172.16.40.0/24
ip route get 172.16.40.10

Ожидаемый результат команды ip route get должен содержать сеть назначения, шлюз 192.168.1.1 и интерфейс ens18. Если удаленный узел отвечает на ICMP, выполните дополнительную проверку:

ping -c 4 172.16.40.10

Шлюз должен находиться в локальной сети интерфейса или иметь корректный канальный путь через существующий маршрут. Для адреса интерфейса 192.168.1.20/24 шлюз 192.168.1.1 подходит, а адрес 192.168.2.1 требует другой топологии и отдельного объяснения.

Что изменится после перезагрузки

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

Временный маршрут полезен для двух задач:

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

Для рабочего сервера перенесите проверенные параметры в /etc/network/interfaces, если интерфейс обслуживает ifupdown, либо в файл .network для systemd-networkd. Редактирование неиспользуемого файла результата не даст.

Что проверить перед настройкой маршрутизации

Перед изменением сети подготовьте консольный доступ к серверу или резервный канал управления. Ошибка в маршруте по умолчанию способна оборвать SSH-сессию и заблокировать удаленный доступ.

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

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

Определить интерфейс и его адрес

Сначала выведите список интерфейсов:

ip link show
ip -br link

Имена интерфейсов в Debian часто выглядят как ens18, enp1s0 или eth0. Ориентируйтесь на фактический вывод системы, а не на шаблоны из старых инструкций.

Проверьте IPv4-адреса:

ip addr show
ip -4 addr show dev ens18

Интерфейс должен иметь состояние UP, физический линк должен работать, а адрес и префикс должны соответствовать локальному сегменту. Например, запись 192.168.1.20/24 создает подключенный маршрут к сети 192.168.1.0/24.

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

ip route show
ip -4 route show
ip -6 route show

В таблице обычно присутствуют три типа записей:

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

Маршрут с более длинным префиксом имеет приоритет над общим. Запись 10.20.0.0/16 будет выбрана для адреса 10.20.5.10 вместо маршрута по умолчанию, если обе записи доступны.

Проверить достижимость шлюза

Проверьте адрес шлюза через нужный интерфейс:

ping -c 4 -I ens18 192.168.1.1

Затем узнайте, как ядро отправит пакет к шлюзу:

ip route get 192.168.1.1

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

Временная настройка: как добавить и удалить маршрут через ip route

Временная настройка позволяет сначала проверить сетевую схему, а потом сохранить рабочий вариант. Это особенно полезно на удаленном сервере с несколькими интерфейсами.

Маршрут до удаленной подсети

Добавьте маршрут к сети 10.50.0.0/24 через шлюз 192.168.1.1:

sudo ip route add 10.50.0.0/24 via 192.168.1.1 dev ens18

Проверьте запись и выбор пути:

ip route show
ip route get 10.50.0.25

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

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

Маршрут до отдельного хоста

Для одного IPv4-адреса используйте префикс /32:

sudo ip route add 10.50.0.25/32 via 192.168.1.1 dev ens18
ip route get 10.50.0.25

Такая запись действует только для указанного узла. Она подходит, когда через другой шлюз нужно направить один сервер, систему мониторинга или endpoint API.

Для одного IPv6-адреса используют префикс /128:

sudo ip -6 route add 2001:db8:50::25/128 via 2001:db8:1::1 dev ens18

IPv6-маршрут требует корректного IPv6-адреса интерфейса и доступного IPv6-шлюза. Не смешивайте команды ip route и ip -6 route.

Маршрут по умолчанию и замена шлюза

Маршрут по умолчанию задают так:

sudo ip route replace default via 192.168.1.1 dev ens18

Команда replace заменит существующую запись или создаст ее, если записи нет. Удаление выполняют так:

sudo ip route del default via 192.168.1.1 dev ens18

Изменение default route влияет на весь трафик, для которого нет более специфичного маршрута. Уже открытая SSH-сессия может оборваться, если ответные пакеты начнут уходить через другой uplink.

Проверяйте результат сразу:

ip route show default
ip route get 1.1.1.1

Удаление временного маршрута

Удалите маршрут до подсети командой:

sudo ip route del 10.50.0.0/24 via 192.168.1.1 dev ens18
ip route show

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

Постоянная статическая маршрутизация Debian через /etc/network/interfaces

Файл /etc/network/interfaces обрабатывает пакет ifupdown. Этот вариант подходит, когда интерфейс действительно поднимает ifupdown, а не systemd-networkd, cloud-init или другой менеджер.

Базовая конфигурация интерфейса со шлюзом

Пример статической настройки интерфейса:

auto ens18
iface ens18 inet static
    address 192.168.1.20/24
    gateway 192.168.1.1

В старых конфигурациях вместо CIDR часто используют отдельную маску:

auto ens18
iface ens18 inet static
    address 192.168.1.20
    netmask 255.255.255.0
    gateway 192.168.1.1

auto поднимает интерфейс при запуске системы. allow-hotplug связывает запуск с обнаружением сетевого устройства. iface задает тип адресации, address и netmask описывают адрес, а gateway создает маршрут по умолчанию.

На сервере с несколькими интерфейсами обычно задают default gateway только на одном основном uplink. Для остальных сетей добавляют конкретные маршруты.

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

Для постоянного маршрута можно использовать команды up и down:

auto ens18
iface ens18 inet static
    address 192.168.1.20/24
    gateway 192.168.1.1
    up ip route add 10.50.0.0/24 via 192.168.1.1 dev ens18
    down ip route del 10.50.0.0/24 via 192.168.1.1 dev ens18

В некоторых конфигурациях применяют эквивалентные директивы post-up и pre-down:

auto ens18
iface ens18 inet static
    address 192.168.1.20/24
    gateway 192.168.1.1
    post-up ip route add 10.60.0.0/16 via 192.168.1.1 dev ens18
    pre-down ip route del 10.60.0.0/16 via 192.168.1.1 dev ens18

Используйте один согласованный набор директив и проверьте синтаксис на конкретной версии ifupdown. Маршрут должен добавляться после появления адреса и доступности шлюза. Если маршрут уже создается другим сервисом, команда завершится ошибкой или появится дублирование.

Применение изменений без полной перезагрузки

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

sudo cp -a /etc/network/interfaces /etc/network/interfaces.bak

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

sudo ifdown ens18
sudo ifup ens18

Перезапуск интерфейса разорвет SSH, если соединение идет через ens18. На некоторых серверах используют перезапуск сетевой службы:

sudo systemctl restart networking

Команда зависит от состава системы и затрагивает несколько интерфейсов. После применения проверьте адрес и маршрут:

ip addr show dev ens18
ip route show
ip route get 10.50.0.25

Как убедиться, что маршрут восстановится после reboot

Сначала перезапустите только интерфейс и проверьте запись. Затем запланируйте перезагрузку в контролируемое окно:

sudo reboot

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

ip route show
ip route get 10.50.0.25
ping -c 4 10.50.0.25

Проверка после reboot нужна обязательно. Рабочая запись в текущей таблице еще не доказывает, что ifupdown корректно создает ее при старте.

Настройка маршрутов через systemd-networkd, если interfaces не используется

Отсутствие NetworkManager не означает автоматическое использование ifupdown. На Debian-серверах сеть может обслуживать systemd-networkd. В таком случае файл /etc/network/interfaces не управляет интерфейсом.

Как определить, кто управляет интерфейсом

Проверьте состояние служб:

systemctl is-active systemd-networkd
systemctl is-active networking
systemctl is-enabled systemd-networkd
systemctl is-enabled networking

Посмотрите процессы и журналы:

systemctl status systemd-networkd
journalctl -u systemd-networkd -b
journalctl -u networking -b

Проверьте, не созданы ли конфигурации cloud-init:

ls -la /etc/systemd/network/
ls -la /etc/network/interfaces.d/

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

Статический маршрут в .network-файле

Создайте файл, например /etc/systemd/network/10-ens18.network:

[Match]
Name=ens18

[Network]
Address=192.168.1.20/24
Gateway=192.168.1.1

[Route]
Destination=10.50.0.0/24
Gateway=192.168.1.1

Секция [Match] выбирает интерфейс. В секции [Network] задают адрес и шлюз. Секция [Route] описывает сеть назначения и следующий хоп.

После изменения перезапустите службу:

sudo systemctl restart systemd-networkd
ip addr show dev ens18
ip route show
ip route get 10.50.0.25

Синтаксис отдельных параметров зависит от версии systemd, установленной в Debian. Для Debian 12 и Debian 13 проверяйте локальную справку:

man systemd.network
systemd-analyze verify /etc/systemd/network/10-ens18.network

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

Общую разницу между ip route, Netplan и systemd-networkd можно сверить в руководстве по маршрутизации Linux 2026.

Несколько интерфейсов и шлюзов: как избежать неправильной маршрутизации

Multi-homed-сервер может иметь management-сеть, storage-сеть и внешний uplink. Несколько интерфейсов сами по себе не требуют нескольких маршрутов по умолчанию.

Почему не стоит задавать шлюз на каждом интерфейсе

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

Для каждой внутренней сети задавайте специфичный маршрут:

sudo ip route add 10.10.0.0/16 dev ens19
sudo ip route add 172.16.40.0/24 via 192.168.1.1 dev ens18

Основной шлюз оставьте на интерфейсе внешнего uplink. Для storage-сети часто достаточно connected route без default gateway.

Метрика маршрута и приоритеты

Метрика помогает выбрать один из маршрутов одинаковой длины:

sudo ip route add default via 192.168.1.1 dev ens18 metric 100
sudo ip route add default via 192.168.2.1 dev ens19 metric 200

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

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

Когда нужен policy routing

Policy routing использует правила ip rule и отдельные таблицы. Пример направления трафика с адреса 192.168.2.20 через второй шлюз:

sudo ip route add 10.200.0.0/16 via 192.168.2.1 dev ens19 table 200
sudo ip route add default via 192.168.2.1 dev ens19 table 200
sudo ip rule add from 192.168.2.20/32 table 200
ip rule show
ip route show table 200

Для полноценной схемы в отдельной таблице нужны connected routes до локальной сети и корректный обратный путь. После временного теста перенесите правила в конфигурацию активного сетевого менеджера.

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

Диагностику начинайте с локального состояния, затем переходите к шлюзу и удаленному сервису. Такой порядок помогает отделить ошибку маршрута от DNS, firewall и обратного пути.

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

ip route get 10.50.0.25
ip route get 10.50.0.25 from 192.168.1.20

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

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

Для первого теста используйте tracepath:

tracepath 10.50.0.25

Если установлен traceroute, можно выбрать тип проверки:

traceroute 10.50.0.25
traceroute -T -p 443 10.50.0.25

tracepath и классический ICMP или UDP traceroute могут получать разные результаты. Промежуточный маршрутизатор способен фильтровать диагностические пакеты и при этом пропускать TCP-соединения. Отсутствие ответа от узла не доказывает потерю трафика на этом узле.

Проверить пакеты через tcpdump

Посмотрите обмен на нужном интерфейсе:

sudo tcpdump -ni ens18 host 10.50.0.25
sudo tcpdump -ni ens18 host 10.50.0.25 and port 443

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

Отделить маршрутизацию от DNS и firewall

Сначала проверяйте IP-адрес, затем имя:

ping -c 4 10.50.0.25
getent hosts server.example
ping -c 4 server.example

Если IP доступен, а имя не разрешается, ищите проблему в DNS и настройках systemd-resolved или другого resolver. Если маршрут выбран правильно, но TCP-порт закрыт, проверьте локальные правила:

sudo nft list ruleset
sudo iptables -S

Проверка ICMP не подтверждает доступность конкретного TCP-сервиса. Для порта анализируйте соединение через tcpdump и проверяйте состояние удаленного приложения.

Типовые ошибки при ручной настройке маршрутов в Debian

Симптом	Вероятная причина	Проверка
Шлюз недоступен	Неверный префикс, VLAN или адрес шлюза	`ip addr`, `ip route get GATEWAY`, `ping -I INTERFACE GATEWAY`
Трафик идет через другой интерфейс	Конфликт маршрутов или метрик	`ip route show`, `ip route get TARGET`
Маршрут исчезает после reboot	Изменен только runtime-состояние	Проверить ifupdown, systemd-networkd и конфигурационные файлы
SSH оборвался	Изменен default route или обратный путь	Проверить консоль, `ip route get CLIENT_IP` и policy routing

Шлюз находится вне локальной подсети

При адресе интерфейса 192.168.1.20/24 шлюз 192.168.2.1 не входит в подключенную сеть. Ядро может отклонить маршрут с ошибкой Nexthop has invalid gateway.

Проверьте:

ip -4 addr show dev ens18
ip -4 route show dev ens18
ip route get 192.168.2.1

Исправьте адрес, маску, VLAN или фактическую схему L2. Не добавляйте обходные параметры, пока не установлена причина отсутствия канального пути.

Маршрут добавлен, но трафик идет через другой интерфейс

Сравните длину префиксов. Маршрут 10.50.0.0/24 приоритетнее 10.0.0.0/8, а оба приоритетнее default. При одинаковом префиксе проверьте метрики:

ip route show table main
ip route get 10.50.0.25

Удалите ошибочную запись или задайте корректную метрику. Для выбора по исходному адресу используйте policy routing.

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

Проверьте четыре условия:

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

systemctl is-active networking
systemctl is-active systemd-networkd
journalctl -b -u networking
journalctl -b -u systemd-networkd

Не смешивайте up из ifupdown с секцией [Route] в systemd-networkd без ясного понимания, какой сервис отвечает за конкретный интерфейс.

Потеря SSH после изменения default route

Подготовьте команду отката до изменения маршрута:

sudo ip route replace default via OLD_GATEWAY dev OLD_INTERFACE

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

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

Итоговая схема выбора способа настройки

Краткий алгоритм настройки

Определите активный сетевой стек: ifupdown, systemd-networkd или cloud-init.
Проверьте имя интерфейса и адрес командой ip addr.
Посмотрите таблицу через ip route show.
Проверьте шлюз командой ping и через ip route get.
Добавьте временный маршрут с помощью ip route add.
Проверьте трафик через ping, tracepath или tcpdump.
Перенесите рабочие параметры в /etc/network/interfaces или файл .network.
Перезапустите интерфейс в контролируемое окно.
Проверьте маршрут после перезапуска и после reboot.

Когда достаточно обычного статического маршрута

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

sudo ip route add 10.20.0.0/16 via 192.168.1.1 dev ens18

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

Когда требуется отдельная схема маршрутизации

Policy routing нужно рассматривать при следующих условиях:

на сервере есть несколько независимых uplink;
разные исходные адреса должны использовать разные шлюзы;
management-сеть и внешний трафик разделены;
storage-сеть должна оставаться изолированной;
обычные default route создают асимметрию;
нужно направлять трафик по source-based routing.

Итоговая шпаргалка проста: ip route проверяет временную схему, /etc/network/interfaces хранит постоянные параметры для ifupdown, файлы .network используются systemd-networkd, а ip rule и отдельные таблицы нужны для выбора пути по источнику. Перед изменением проверяйте интерфейс, адрес, шлюз, таблицу, результат ip route get и сохранение после перезагрузки.

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