Основы: как устроена таблица маршрутизации и зачем нужны статические маршруты
Таблица маршрутизации в Linux работает как карта дорог для сетевых пакетов. Она содержит записи о том, через какой интерфейс и шлюз нужно отправлять трафик к определенным сетям. Когда пакет покидает ваш сервер, ядро сверяется с этой таблицей, чтобы выбрать оптимальный путь доставки.
Шлюз по умолчанию (default gateway) - это специальная запись в таблице, которая указывает маршрут для всего трафика, не подпадающего под более конкретные правила. Обычно это адрес вашего роутера, ведущего в интернет.
Динамическая маршрутизация использует протоколы вроде OSPF или BGP для автоматического обновления таблиц на основе изменений в сети. Статическая маршрутизация требует ручного добавления маршрутов администратором. Вы создаете статические маршруты в нескольких случаях:
- Для изоляции трафика между подсетями
- При использовании резервных каналов связи
- Когда нужно направлять специфичный трафик через определенный интерфейс
- В сценариях с несколькими интернет-провайдерами
Утилита ip route заменила устаревшие инструменты route и ifconfig. Она предоставляет единый интерфейс для управления всеми аспектами маршрутизации в современных Linux-системах.
Как интерпретировать вывод команды ip route show
Команда ip route show (или сокращенно ip r) показывает текущее состояние таблицы маршрутизации. Рассмотрим типичный вывод:
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 metric 100
10.0.0.0/24 via 192.168.1.254 dev eth0 metric 200
Первая строка указывает шлюз по умолчанию: весь трафик (default) идет через шлюз 192.168.1.1 (via 192.168.1.1) на интерфейсе eth0 (dev eth0). Метрика 100 означает приоритет этого маршрута.
Вторая строка описывает локальную сеть: подсеть 192.168.1.0/24 доступна напрямую через интерфейс eth0. Поле src 192.168.1.100 показывает исходный IP-адрес, который система будет использовать для исходящих пакетов в эту сеть.
Третья строка - статический маршрут: трафик к сети 10.0.0.0/24 направляется через шлюз 192.168.1.254 на том же интерфейсе eth0 с метрикой 200.
Ключевые поля для понимания:
destination- сеть назначения (например, 10.0.0.0/24)via- адрес шлюза для этого маршрутаdev- сетевой интерфейсmetric- числовой приоритет маршрута (чем меньше, тем лучше)scope- область действия (link, host, global)
Чтобы проверить, какой маршрут выберет ядро для конкретного адреса, используйте команду ip route get 8.8.8.8. Она покажет полный путь, включая исходный интерфейс и адрес.
Практика: базовые операции с маршрутами через ip route
Следующие команды решают большинство повседневных задач системного администратора. Выполняйте их с правами root или через sudo.
Добавление и удаление статического маршрута
Базовый синтаксис добавления маршрута:
ip route add <сеть> via <шлюз> dev <интерфейс>
Пример: направить трафик к сети 192.168.100.0/24 через шлюз 10.0.0.1 на интерфейсе eth0:
ip route add 192.168.100.0/24 via 10.0.0.1 dev eth0
Параметр dev иногда можно опустить, если система может определить интерфейс автоматически по адресу шлюза. Однако в сложных конфигурациях с несколькими интерфейсами в одной подсети явное указание dev предотвращает ошибки.
Для удаления маршрута используйте команду с тем же набором параметров:
ip route del 192.168.100.0/24 via 10.0.0.1 dev eth0
Или более короткий вариант, если в таблице только один маршрут к этой сети:
ip route del 192.168.100.0/24
Предупреждение: удаление маршрута, используемого для текущего SSH-соединения, приведет к потере доступа к серверу. Всегда проверяйте активные соединения перед изменением таблицы маршрутизации.
Управление шлюзом по умолчанию
Добавление нового шлюза по умолчанию:
ip route add default via 192.168.1.1 dev eth0
Удаление текущего шлюза по умолчанию:
ip route del default via 192.168.1.1
В Linux может существовать несколько маршрутов по умолчанию с разными метриками. Ядро выбирает маршрут с наименьшей метрикой. Если метрики равны, поведение зависит от реализации ядра и может быть непредсказуемым. Для создания актив-пассивной схемы назначьте основному каналу метрику 100, а резервному - 200:
ip route add default via 192.168.1.1 dev eth0 metric 100
ip route add default via 192.168.2.1 dev eth1 metric 200
При таком подходе трафик всегда идет через eth0, пока этот интерфейс активен. Если eth0 теряет связь, система автоматически переключается на маршрут через eth1.
Проверка и очистка конфигурации
Полный просмотр таблицы маршрутизации:
ip route show
Или в более компактном формате:
ip r
Проверка маршрута до конкретного адреса - одна из самых полезных диагностических команд:
ip route get 10.0.0.50
Эта команда показывает не только конечный маршрут из таблицы, но и исходный IP-адрес, который система использует для связи с целевым хостом.
Очистка всех статических маршрутов (используйте с крайней осторожностью):
ip route flush table main
Команда flush удаляет все маршруты из таблицы main, кроме автоматически сгенерированных ядром (помеченных как proto kernel). После выполнения этой команды останутся только маршруты к непосредственно подключенным сетям.
Сложные сценарии: политики маршрутизации и несколько таблиц
Policy-Based Routing (PBR) позволяет принимать решения о маршрутизации на основе условий, а не только адреса назначения. Эта технология лежит в основе сценариев с несколькими провайдерами, балансировкой нагрузки и изоляцией трафика VLAN.
Создание и использование дополнительных таблиц маршрутизации
По умолчанию Linux использует таблицу main (идентификатор 254). Вы можете создавать дополнительные таблицы для организации изолированных наборов маршрутов. Список доступных таблиц находится в файле /etc/iproute2/rt_tables:
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
Добавьте новую таблицу в конец файла:
200 provider2
Теперь наполните эту таблицу маршрутами:
ip route add default via 192.168.2.1 dev eth1 table provider2
ip route add 192.168.2.0/24 dev eth1 table provider2
Просмотр содержимого конкретной таблицы:
ip route show table provider2
Или используя числовой идентификатор:
ip route show table 200
Каждая таблица маршрутизации независима. Маршруты в таблице provider2 не влияют на маршруты в таблице main и не используются системой до тех пор, пока не будут явно выбраны через правила.
Правила ip rule: выбор таблицы на основе источника, метки и других условий
Правила определяют, какую таблицу маршрутизации использовать для принятия решения о пути пакета. Просмотрите текущие правила:
ip rule list
Вы увидите примерно такой вывод:
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Ядро обрабатывает правила в порядке возрастания приоритета (от меньшего числа к большему). Правило с приоритетом 0 проверяется первым: весь трафик сначала проверяется в таблице local, которая содержит специальные маршруты для широковещательных адресов и адресов самого хоста.
Создайте правило для маршрутизации трафика с определенного IP-адреса через отдельную таблицу:
ip rule add from 192.168.100.50 lookup provider2 priority 1000
Теперь весь исходящий трафик с исходным адресом 192.168.100.50 будет использовать таблицу provider2 вместо main. Это основа для разделения трафика по нескольким провайдерам.
Правила могут использовать различные селекторы:
from- исходный IP-адресto- адрес назначенияfwmark- метка пакета, установленная iptables или nftablesiif/oif- входной/выходной интерфейс
Для работы с трафиком из VLAN создайте правило на основе входного интерфейса:
ip rule add iif vlan100 lookup vlan100_table priority 1500
Удаление правила выполняется аналогично добавлению:
ip rule del from 192.168.100.50 lookup provider2
Или по приоритету:
ip rule del priority 1000
Кейс: Настройка маршрутизации для двух интернет-провайдеров
Рассмотрим практический сценарий: сервер имеет два сетевых интерфейса, каждый подключен к разному провайдеру. Нужно разделить трафик так, чтобы определенные сервисы использовали ISP1, а остальные - ISP2.
1. Добавьте таблицы в /etc/iproute2/rt_tables:
100 isp1
200 isp2
2. Настройте default-маршруты в каждой таблице:
ip route add default via 192.168.1.1 dev eth0 table isp1
ip route add 192.168.1.0/24 dev eth0 table isp1
ip route add default via 192.168.2.1 dev eth1 table isp2
ip route add 192.168.2.0/24 dev eth1 table isp2
3. Создайте правила для разделения трафика. Например, весь трафик с исходным адресом 10.0.0.10 идет через ISP1, а с адресом 10.0.0.20 - через ISP2:
ip rule add from 10.0.0.10 lookup isp1 priority 1000
ip rule add from 10.0.0.20 lookup isp2 priority 1001
4. Для резервирования добавьте маршруты с большей метрикой в основную таблицу:
ip route add default via 192.168.1.1 dev eth0 metric 100
ip route add default via 192.168.2.1 dev eth1 metric 200
Теперь если оба правила не сработают (или если трафик идет с других адресов), система использует основной канал через ISP1 как активный, а канал через ISP2 как резервный.
Для более сложных сценариев с балансировкой нагрузки между провайдерами используйте подход с маркировкой пакетов. Подробное руководство по source-based маршрутизации с готовыми конфигурациями вы найдете в статье «Source-based маршрутизация в Linux: Разделение и балансировка трафика по нескольким шлюзам».
Метрика маршрута: управление приоритетами и резервирование каналов
Метрика маршрута - это числовое значение, которое определяет его предпочтительность. Когда в таблице маршрутизации существует несколько путей к одной сети, ядро выбирает маршрут с наименьшей метрикой. Если метрики равны, может использоваться любой из доступных маршрутов, что иногда приводит к асимметричной маршрутизации.
Как задать метрику при добавлении маршрута
Используйте параметр metric в команде ip route add:
ip route add default via 192.168.1.1 dev eth0 metric 100
ip route add default via 192.168.2.1 dev eth1 metric 200
В этом примере основной шлюз через eth0 имеет метрику 100, а резервный через eth1 - 200. Пока интерфейс eth0 активен, весь трафик идет через него. Если eth0 теряет соединение (например, обрыв кабеля), система автоматически переключается на маршрут с метрикой 200.
Метрику можно задать и для конкретных сетей:
ip route add 10.0.0.0/24 via 192.168.1.254 dev eth0 metric 50
ip route add 10.0.0.0/24 via 192.168.2.254 dev eth1 metric 150
Здесь трафик к сети 10.0.0.0/24 предпочтительно направляется через первый шлюз. Второй маршрут работает как резервный.
Проверьте работу метрик командой:
ip route get 10.0.0.10
Вывод покажет выбранный маршрут и его метрику. Для диагностики проблем с выбором пути также полезно использовать инструменты traceroute и mtr.
Важное замечание: метрика влияет только на выбор маршрута внутри одной таблицы маршрутизации. Если вы используете несколько таблиц с правилами ip rule, выбор между таблицами определяется приоритетом правил, а не метриками маршрутов внутри них.
Как сделать настройки постоянными (после перезагрузки)
Команды ip route и ip rule изменяют состояние ядра, но не сохраняются после перезагрузки. Чтобы маршруты сохранялись, их нужно прописать в конфигурационных файлах вашего дистрибутива.
Для систем с NetworkManager (RHEL, CentOS, Fedora, современные Ubuntu)
На системах, использующих NetworkManager, статические маршруты добавляются в файлы конфигурации интерфейсов. В RHEL/CentOS 7 и более ранних версиях:
# /etc/sysconfig/network-scripts/route-eth0
192.168.100.0/24 via 10.0.0.1 dev eth0
default via 192.168.1.1 dev eth0 metric 100
В RHEL/CentOS 8+ и Fedora используйте ключевые файлы NetworkManager:
nmcli connection modify eth0 +ipv4.routes "192.168.100.0/24 10.0.0.1"
Или создайте файл в /etc/NetworkManager/system-connections/ с секцией:
[ipv4]
route1=192.168.100.0/24,10.0.0.1
route2=0.0.0.0/0,192.168.1.1,100
После изменения конфигурации перезапустите NetworkManager:
systemctl restart NetworkManager
Для систем с systemd-networkd (Ubuntu Server, некоторые дистрибутивы)
Systemd-networkd использует файлы с расширением .network в директории /etc/systemd/network/ или /lib/systemd/network/. Пример конфигурации для eth0:
# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0
[Network]
Address=192.168.1.100/24
Gateway=192.168.1.1
DNS=8.8.8.8
[Route]
Destination=192.168.100.0/24
Gateway=10.0.0.1
Metric=100
Для настройки нескольких таблиц и правил создайте отдельный файл с типом .route:
# /etc/systemd/network/10-eth0.route
[Route]
Destination=0.0.0.0/0
Gateway=192.168.1.1
Table=100
[RoutingPolicyRule]
From=192.168.100.50
Table=100
Активируйте изменения:
systemctl restart systemd-networkd
Универсальный способ: скрипт в /etc/network/if-up.d/ или systemd unit
Для сложных сценариев с ip rule и несколькими таблицами создайте скрипт, который выполняется при поднятии интерфейса:
# /etc/network/if-up.d/static-routes
#!/bin/bash
if [ "$IFACE" = "eth0" ]; then
# Очистка старых правил
ip rule del priority 1000 2>/dev/null
# Добавление таблиц
ip route add default via 192.168.1.1 dev eth0 table 100
ip route add 192.168.1.0/24 dev eth0 table 100
# Правила
ip rule add from 192.168.100.50 lookup 100 priority 1000
fi
Сделайте скрипт исполняемым:
chmod +x /etc/network/if-up.d/static-routes
Альтернативный подход - создание systemd-юнита:
# /etc/systemd/system/static-routes.service
[Unit]
Description=Static routes configuration
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/setup-routes.sh
[Install]
WantedBy=multi-user.target
В скрипте /usr/local/bin/setup-routes.sh разместите все необходимые команды ip route и ip rule. Важно соблюдать порядок: сначала добавлять маршруты в таблицы, затем создавать правила.
Этот метод подходит для любых дистрибутивов и дает полный контроль над процессом настройки. Однако он требует ручного управления зависимостями между сетевыми интерфейсами и маршрутами.
Отладка: методика проверки и диагностики проблем маршрутизации
Когда маршрутизация не работает, систематический подход к диагностике экономит время. Следуйте этому чек-листу, чтобы найти причину проблемы.
Чек-лист: «Почему не работает маршрут?»
- Проверка доступности шлюза
ping 10.0.0.1
Если пинг до шлюза не проходит, проблема может быть на канальном уровне (кабель, порт коммутатора) или в настройках самого шлюза. - Проверка наличия маршрута в таблице
ip route show
Убедитесь, что нужный маршрут присутствует в таблице. Обратите внимание на метрику - возможно, существует более приоритетный маршрут к той же сети. - Анализ применяемых правил и таблиц
ip rule list
ip route get 8.8.8.8 from 192.168.100.50
Вторая команда показывает, какой маршрут выберет ядро для трафика с указанным исходным адресом. Это ключевой инструмент для диагностики policy-based routing. - Проверка обратного пути
Асимметричная маршрутизация - частая проблема в сетях с несколькими путями. Трафик от клиента к серверу идет по одному маршруту, а ответ - по другому. Используйтеtracerouteв обоих направлениях для проверки.
Подробнее об этой проблеме и методах ее решения читайте в статье «Асимметричная маршрутизация: от диагностики проблемы до рабочих решений». - Проверка firewall
iptables -L -n -vилиnft list ruleset
Файрвол может блокировать трафик даже при правильной маршрутизации. Особое внимание уделите цепочкам FORWARD (если сервер работает как маршрутизатор) и OUTPUT. - Диагностика с помощью traceroute и mtr
traceroute -n 8.8.8.8
mtr -n 8.8.8.8
Эти инструменты показывают каждый хоп на пути к цели. Если трафик доходит до шлюза, но не идет дальше, проблема может быть на стороне провайдера или в следующем маршрутизаторе. - Проверка MTU
ping -M do -s 1472 8.8.8.8
Если пакеты размером 1500 байт (1472 + 28 заголовка) не проходят, но меньшие пакеты проходят, возможно, проблема с MTU. Это особенно актуально для туннелей и VPN.
Для комплексной диагностики сетевых проблем, включая работу с динамическими протоколами маршрутизации, обратитесь к практическому руководству по принципам IP-маршрутизации и настройке OSPF.
Помните: большинство проблем с маршрутизацией решается проверкой основ - доступности шлюза, наличия маршрута в таблице и отсутствия блокировок на фаерволе. Системный подход к диагностике избавляет от необходимости гадать и перебирать варианты наугад.