Как добавить и удалить статический маршрут в Linux: ip route add, ip route del и сохранение после перезагрузки

Статический маршрут в Linux добавляют командой ip route add 10.20.0.0/24 via 192.168.1.254 dev eth0. Она меняет таблицу маршрутизации ядра и действует до перезагрузки или перезапуска сети. Чтобы маршрут пережил reboot, его описывают в конфигурации сетевого менеджера: systemd-networkd, NetworkManager или netplan. Удаляют маршрут командой ip route del с теми же параметрами, с которыми его добавляли.

Три задачи закрываются тремя наборами команд. Добавление: ip route add для отдельного хоста, подсети и шлюза по умолчанию. Замена: ip route replace, атомарная операция без промежутка, когда маршрута нет. Удаление: ip route del. После каждого шага полезна проверка через ip route show и ip route get, иначе легко отрезать себя от сервера по SSH.

Ниже разобран синтаксис параметров via, dev, metric и src, собраны готовые команды для типовых сценариев и приведены конфиги, которые сохраняют маршруты после перезагрузки.

Что такое статический маршрут в Linux и когда он нужен

Статический маршрут - запись в таблице маршрутизации ядра, которая задаёт путь к сети или хосту через конкретный шлюз либо интерфейс. Динамические протоколы (OSPF, BGP, RIP) наполняют таблицу сами, статический маршрут администратор прописывает вручную. Ядро выбирает маршрут по правилу longest prefix match: побеждает запись с самым длинным совпадающим префиксом, а при равных префиксах - с меньшей метрикой.

Четыре сценария, где без статики не обойтись:

• Доступ к подсети за вторым шлюзом. Например, 10.20.0.0/24 доступна только через 192.168.1.254, а default gateway ведёт в интернет.
• Маршрут к management-сети. Интерфейс управления 192.168.100.0/24 подключён к отдельному порту, и трафик к нему не должен уходить в общий шлюз.
• Маршрут к pod и service CIDR в Kubernetes. При развёртывании кластера через kubeadm CIDR в custom-resources.yaml для Calico должен совпадать с заданным ранее, иначе трафик между нодами не пойдёт (разбор установки кластера).
• Резервный канал или доступ к NAS в отдельном сегменте через второго провайдера с большей метрикой.

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

Временный маршрут против постоянного: в чём разница

ip route add пишет запись только в runtime-таблицу ядра. Перезагрузка, перезапуск systemd-networkd, NetworkManager или netplan apply стирают её. В выводе ip route show такой маршрут помечен как proto static, но источника конфигурации у него нет: после reboot запись исчезнет.

Постоянный маршрут хранится в файле менеджера сети и применяется при каждом старте системы.

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

Синтаксис ip route: разбираем параметры via, dev, metric и src

Общая форма команды: ip route add СЕТЬ/МАСКА via ШЛЮЗ dev ИНТЕРФЕЙС src АДРЕС metric ЧИСЛО.

• СЕТЬ/МАСКА - целевой префикс, например 10.20.0.0/24 или 203.0.113.10/32.
• via - IP следующего хопа, то есть шлюз, который знает, куда передать пакет дальше.
• dev - исходящий интерфейс. Указывайте его, когда шлюз находится не в directly connected сети, и всегда на серверах с несколькими сетевыми картами.
• metric - приоритет маршрута. Меньше значение - выше приоритет.
• src - исходный адрес для пакетов, уходящих по этому маршруту.
• scope, table, onlink - продвинутые параметры: область действия маршрута, номер таблицы политики маршрутизации, разрешение использовать шлюз вне локальной подсети.

Посмотреть, что уже есть в таблице:

ip route show
default via 192.168.1.1 dev eth0 proto static metric 100
10.20.0.0/24 via 192.168.1.254 dev eth0 metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50

proto kernel означает, что запись создало ядро при назначении адреса интерфейсу, proto static - маршрут задан вручную или менеджером сети, scope link - сеть доступна напрямую без шлюза. Список интерфейсов и адресов удобно смотреть в кратком виде:

ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.50/24 fe80::5054:ff:fe12:3456/64

Если dev указан неверно или шлюз недостижим, ядро вернёт RTNETLINK answers: Network is unreachable. Проверьте, что адрес шлюза входит в подсеть интерфейса: ip route show покажет connected-запись вида 192.168.1.0/24 dev eth0.

Как выбрать метрику и не создать конфликт маршрутов

При одинаковой длине префикса ядро выбирает маршрут с меньшей метрикой. Два default gateway с metric 100 и 200 работают предсказуемо: трафик уходит через первый, второй остаётся резервом. Одинаковая метрика у двух маршрутов к одной сети даёт равновесный выбор, который зависит от внутренних хешей ядра и меняется непредсказуемо, поэтому такую конфигурацию лучше не оставлять.

ip route add default via 192.168.1.1 dev eth0 metric 100
ip route add default via 192.168.1.254 dev eth1 metric 200
ip route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.50 uid 0

Команда ip route get показывает, какой маршрут и какой src-адрес ядро применит к конкретному получателю. Это самый быстрый способ убедиться, что метрика сработала так, как задумано.

Когда нужен параметр src и как он влияет на трафик

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

ip route add 10.20.0.0/24 via 192.168.1.1 dev eth0 src 192.168.1.50

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

Как добавить статический маршрут: ip route add для хоста, подсети и шлюза по умолчанию

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

Маршрут к одному IP удобен для доступа к конкретному серверу через нестандартный шлюз.

ip route add 203.0.113.10 via 192.168.1.1 dev eth0
ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0

Обе записи эквивалентны: /32 подставляется по умолчанию. Проверка после добавления: ip route get 203.0.113.10 покажет via 192.168.1.1, а не default gateway.

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

ip route add 10.20.0.0/24 via 192.168.1.254 dev eth0 metric 100
ip route show 10.20.0.0/24
10.20.0.0/24 via 192.168.1.254 dev eth0 metric 100

Маска задаёт охват: /24 покрывает 254 адреса, /16 - более 65 тысяч. Для нескольких удалённых сетей добавьте несколько маршрутов. Если сети идут подряд (10.20.0.0/24, 10.20.1.0/24, 10.20.2.0/24), их сворачивают в один агрегированный префикс 10.20.0.0/22 с общим шлюзом, это сокращает таблицу.

Настройка шлюза по умолчанию через ip route add default via

ip route add default via 192.168.1.1 dev eth0

Если default уже существует, команда вернёт ошибку RTNETLINK answers: File exists. Варианты: сначала ip route del default, затем add, либо сразу ip route replace default via 192.168.1.1 dev eth0.

ip route show default
default via 192.168.1.1 dev eth0 proto static metric 100
ip route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.50 uid 0

На сервере, куда вы подключены по SSH, меняйте default gateway только после ping нового шлюза и только с открытой второй сессией. Если новый шлюз недоступен, удаление старого default мгновенно обрывает внешнюю связь вместе с вашей сессией.

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

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

ip route del 10.20.0.0/24 via 192.168.1.254 dev eth0
ip route del 203.0.113.10 via 192.168.1.1 dev eth0
ip route del 10.20.0.0/24

Параметры должны совпадать с теми, что указывали при добавлении, иначе ядро вернёт RTNETLINK answers: No such process. Достаточно указать префикс - последний вариант работает, если маршрут к этому префиксу один. После удаления проверьте, что записи нет:

ip route show 10.20.0.0/24

Удаление шлюза по умолчанию выполняется командой ip route del default. Делайте это, только когда новый маршрут уже добавлен и проверен через ip route get.

Замена маршрута через ip route replace

ip route replace default via 192.168.1.2 dev eth0
ip route replace 10.20.0.0/24 via 192.168.1.254 dev eth0 metric 50

ip route replace атомарно заменяет существующий маршрут к тому же префиксу или создаёт новый, если записи не было. Между удалением и добавлением нет промежутка, когда маршрута нет вовсе, поэтому для смены шлюза replace безопаснее, чем пара del плюс add.

Для чистки таблицы есть ip route flush. Команда ip route flush 10.20.0.0/24 удалит все маршруты к этому префиксу, а ip route flush table main снесёт всю основную таблицу. Второй вариант по SSH не выполняйте: связь с сервером пропадёт сразу.

Как сохранить статические маршруты после перезагрузки

Команда ip route add не сохраняется. Постоянный маршрут описывают в конфигурации того менеджера, который управляет сетью на сервере. Выбор по дистрибутивам: systemd-networkd на Ubuntu Server и минимальном Debian, NetworkManager на RHEL, CentOS Stream, Fedora и десктопных системах, netplan на Ubuntu 18.04 и новее как фронтенд к systemd-networkd или NetworkManager. Сравнение подходов с примерами есть в руководстве по ip route, netplan и systemd-networkd.

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

Файл /etc/systemd/network/10-eth0.network:

[Match]
Name=eth0

[Network]
Address=192.168.1.50/24
Gateway=192.168.1.1

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

Применение и проверка:

systemctl restart systemd-networkd
networkctl status eth0
ip route show 10.20.0.0/24

Набор ключей в секции [Route] менялся между релизами systemd: параметры Type= и GatewayOnLink= появились в systemd 240. Синтаксис для вашей версии сверяйте с man systemd.network, иначе служба не применит маршрут и вы не увидите ошибки в консоли.

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

nmcli connection modify eth0 +ipv4.routes "10.20.0.0/24 192.168.1.254"
nmcli connection up eth0
ip route show 10.20.0.0/24

Знак плюс добавляет маршрут к уже настроенным. Файл /etc/NetworkManager/system-connections/eth0.nmconnection выглядит так:

[ipv4]
method=manual
address1=192.168.1.50/24,192.168.1.1
route1=10.20.0.0/24,192.168.1.254

Файл должен принадлежать root и иметь права 600, иначе NetworkManager его проигнорирует. После правки файла вручную перечитайте профиль командой nmcli connection reload.

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

Файл /etc/netplan/01-netcfg.yaml:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.50/24
      routes:
        - to: 10.20.0.0/24
          via: 192.168.1.254
          metric: 100
        - to: default
          via: 192.168.1.1

Применение: netplan apply. На удалённом сервере используйте netplan try: команда применит конфигурацию и вернёт её назад, если за отведённое время вы не подтвердите результат нажатием Enter. Отступы в YAML критичны, ошибка в них приводит к потере сети после apply.

netplan try
netplan apply
ip route show

Не описывайте один маршрут сразу в netplan и в ip route add, а также не прописывайте его одновременно в /etc/systemd/network и в NetworkManager: менеджеры перезапишут записи друг друга. При развёртывании Kubernetes на Ubuntu 22.04 через kubeadm маршруты к pod и service CIDR создаёт CNI-плагин (например, Calico), и ручные записи к тем же префиксам обычно не нужны. Подробнее про подготовку узлов и установку Calico через Tigera Operator рассказано в инструкции по развёртыванию кластера Kubernetes.

Типичные ошибки при работе с маршрутами и как их избежать

• Удаление default gateway по SSH. Сессия обрывается через секунды, а вернуться можно только через консоль или IPMI. Решение: сначала ip route add нового шлюза, затем ip route get 8.8.8.8, и только после успешной проверки ip route del default.
• Дублирующиеся маршруты из ip route add и конфига менеджера. После перезапуска сети записи накладываются друг на друга. Решение: один источник истины, ручные команды применяйте только для временной отладки.
• Неверный dev или via. Ответ ядра RTNETLINK answers: Network is unreachable означает, что шлюз не входит в подсеть интерфейса или интерфейс назван неправильно. Решение: сверьте вывод ip -br addr и connected-запись в ip route show.
• Забытая метрика на двух default gateway. Без metric ядро может выбрать канал случайно. Решение: разные метрики, например 100 и 200.
• Опечатка в маске. Вместо 10.20.0.0/24 указано 10.20.0.0/16, и маршрут перехватывает трафик к чужим сетям. Решение: перепроверяйте префикс через ip route show и ip route get для конкретного адреса.
• Неверные отступы в netplan YAML. netplan apply завершается ошибкой или ломает маршрут по умолчанию. Решение: netplan try для безопасного применения и последующая проверка ip route show.
• Ручной маршрут к pod CIDR в Kubernetes. Конфликт с маршрутами CNI приводит к тому, что трафик между нодами не идёт или уходит петлёй. Решение: удалить ручную запись и проверить настройки Calico, в частности совпадение CIDR с заданным при kubeadm.
• Изменения без проверки. Маршрут в таблице есть, а трафик не идёт из-за неверного src или шлюза. Решение: ip route get для целевого адреса плюс ping и traceroute до цели.

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

Порядок действий для удалённого сервера:

1. Откройте вторую SSH-сессию и держите её открытой. Работайте в ней, а первую оставьте как страховку.
2. Проверьте доступность нового шлюза: ping -c 3 192.168.1.254.
3. Добавьте новый маршрут, не удаляя старый, или используйте ip route replace для атомарной замены.
4. Проверьте маршрут: ip route get 8.8.8.8 и ip route get адрес-цели.
5. Убедитесь, что узел отвечает: ping внешнего адреса, traceroute до нужной сети.
6. Только после этого удалите старый маршрут через ip route del.

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

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

Пример разбора вывода ip route get:

ip route get 10.20.0.5
10.20.0.5 via 192.168.1.254 dev eth0 src 192.168.1.50 uid 0
    cache

Строка читается так: пакет уйдёт через шлюз 192.168.1.254, интерфейс eth0, источник 192.168.1.50. Если вместо нужного шлюза вы видите default gateway, маршрут не применился или его перекрыл более длинный префикс. Проверьте ip route show 10.20.0.0/24 и убедитесь, что запись на месте. Больше сценариев диагностики собрано в материале по диагностике IP-маршрутизации.

Когда ping до шлюза проходит, а до цели нет, смотрите traceroute: маршрут на вашей стороне может быть верным, а обратный маршрут на удалённом оборудовании отсутствовать. Полезно проверить, не перекрывает ли маршрут более специфичный префикс, например /32 к отдельному хосту поверх /24 к его подсети.

Краткая шпаргалка: ip route add, ip route del и сохранение

Добавление:

ip route add 203.0.113.10 via 192.168.1.1 dev eth0
ip route add 10.20.0.0/24 via 192.168.1.254 dev eth0 metric 100
ip route add default via 192.168.1.1 dev eth0

Замена и удаление:

ip route replace default via 192.168.1.2 dev eth0
ip route del 10.20.0.0/24 via 192.168.1.254 dev eth0
ip route del default
ip route flush 10.20.0.0/24

Проверка:

ip route show
ip route show 10.20.0.0/24
ip route get 8.8.8.8
ip -br addr
ping -c 3 10.20.0.5
traceroute 10.20.0.5

Постоянные маршруты: блок [Route] в /etc/systemd/network/*.network для systemd-networkd, route1= в /etc/NetworkManager/system-connections/*.nmconnection для NetworkManager, секция routes в /etc/netplan/*.yaml для netplan. Команда ip route add действует до перезагрузки; чтобы маршрут сохранился, добавьте его в конфигурацию менеджера сети и примените изменения.