Маршрут по умолчанию (default route) - запись в таблице маршрутизации с адресом 0.0.0.0/0. Она срабатывает для каждого пакета, которому не нашлось более точного совпадения, а следующий узел из этой записи называют шлюзом по умолчанию (default gateway).
Пока строка default есть в таблице, хост отправляет во внешние сети всё, что не относится к его локальным подсетям. Уберите её, и локальная сеть продолжит работать, а адреса за пределами известных префиксов станут недостижимыми. Проверка default-маршрута поэтому открывает любую диагностику в ситуации «пинг до соседнего сервера идёт, а интернет не работает».
Дальше: команды для Linux, Windows и Cisco, способы проверить текущий шлюз и разбор трёх сбоев, из-за которых трафик уходит не через тот интерфейс или пропадает совсем.
Что такое маршрут по умолчанию и когда трафик идёт через шлюз
Запись 0.0.0.0/0 означает «любой адрес назначения». В Windows та же запись выглядит как пара адрес 0.0.0.0 и маска 0.0.0.0. Next-hop в ней - адрес маршрутизатора, подключённого к тому же сегменту, что и сам хост.
Пример таблицы маршрутизации рабочей станции:
| Префикс | Next-hop | Интерфейс | Метрика |
|---|---|---|---|
| 0.0.0.0/0 | 192.168.1.1 | eth0 | 100 |
| 192.168.1.0/24 | напрямую | eth0 | 0 |
| 10.10.0.0/16 | 192.168.1.254 | eth0 | 50 |
Пакет к 10.10.5.7 совпадёт с префиксом 10.10.0.0/16 и уйдёт на 192.168.1.254. Пакет к 192.168.1.20 доставят напрямую в локальный сегмент. Пакет к 8.8.8.8 не совпадёт ни с чем, кроме 0.0.0.0/0, и будет отправлен на 192.168.1.1. Так работает обычная схема: default-маршрут обслуживает только те адреса, для которых в таблице нет отдельной записи.
Аналогия: шлюз по умолчанию - единственный выход из здания для тех, кто не знает точного расположения нужного кабинета. Точный маршрут с конкретным префиксом всегда предпочтительнее выхода «наугад».
Как маршрутизатор выбирает путь: приоритет специфичных маршрутов
Выбор идёт по принципу longest prefix match: маршрут с более длинной маской считается более точным и получает приоритет. Запись 0.0.0.0/0 имеет маску нулевой длины, поэтому проигрывает всем остальным записям. Маршрут /32 к одному хосту выиграет даже у /24 к его подсети.
Практическое следствие для диагностики: трафик уходит мимо default gateway не из-за ошибки в шлюзе, а потому что в таблице появился более специфичный маршрут. Пример: после поднятия VPN добавилась запись 192.168.1.0/24 через tun0, и пакеты к этой подсети пойдут в туннель, хотя default-маршрут остался прежним. Команда ip route get <адрес> в Linux показывает, какой маршрут реально выбран для конкретного назначения.
Роль метрики при выборе default-маршрута
Метрика задаёт приоритет маршрута: чем меньше значение, тем раньше запись попадёт в выборку. Если в таблице несколько строк 0.0.0.0/0, ядро и маршрутизатор выберут ту, у которой метрика меньше. Так система держит основной проводной канал и резервный беспроводной или LTE-интерфейс.
В Linux метрику задают при добавлении: ip route add default via 192.168.1.1 dev eth0 metric 100. У статических записей значение по умолчанию обычно 100, у маршрутов от NetworkManager метрика зависит от типа соединения, поэтому проводное подключение чаще получает приоритет над Wi-Fi. Если метрики нескольких default-маршрутов совпадают, они могут существовать как несколько next-hop одной записи, и ядро распределит между ними потоки.
В Windows к метрике маршрута добавляется метрика интерфейса, поэтому при двух адаптерах с одинаковой маршрутной метрикой победит тот, у которого лучше метрика интерфейса. Обе метрики задаются явно.
Настройка шлюза по умолчанию в Linux
Основной инструмент - команда ip route. Минимальный синтаксис: ip route add default via <шлюз>. Если в системе больше одной сетевой карты, добавляйте dev <интерфейс>: без этого ядро может выбрать не тот интерфейс. Правило актуально и в кластерных сценариях: при развёртывании кластера Kubernetes через kubeadm на ноде с несколькими сетевыми интерфейсами интерфейс для маршрута по умолчанию указывают явно, иначе kubeadm может выбрать не тот (разбор установки кластера kubeadm на Ubuntu 22.04).
Добавление default-маршрута через ip route
# добавить маршрут по умолчанию через конкретный интерфейс ip route add default via 192.168.1.1 dev eth0 # тот же маршрут с явной метрикой ip route add default via 192.168.1.1 dev eth0 metric 100 # проверить ip route show | grep default # какой маршрут будет выбран для конкретного адреса ip route get 8.8.8.8 # удалить ip route del default via 192.168.1.1
В строке вывода default via 192.168.1.1 dev eth0 proto static metric 100 читается всё нужное: адрес шлюза, интерфейс и метрика. Если команда добавления вернула Network is unreachable, значит, шлюз не входит ни в одну из подсетей, настроенных на интерфейсе, поэтому сначала проверьте адрес и маску самого интерфейса. Изменения, сделанные через ip route, живут до перезагрузки или перезапуска сетевой службы.
Сохранение маршрута после перезагрузки
Способ зависит от того, чем управляется сеть в дистрибутиве.
NetworkManager (RHEL, Fedora, CentOS Stream, Ubuntu Desktop, часть серверных сборок):
nmcli con mod eth0 ipv4.gateway 192.168.1.1 nmcli con mod eth0 ipv4.route-metric 100 nmcli con up eth0
systemd-networkd (серверные сборки Debian, Ubuntu, Arch): параметр Gateway в файле /etc/systemd/network/10-eth0.network, после правки нужен systemctl restart systemd-networkd.
[Match] Name=eth0 [Network] Address=192.168.1.50/24 Gateway=192.168.1.1 DNS=8.8.8.8
Классические файлы: для Debian и Ubuntu без NetworkManager строка gateway 192.168.1.1 в /etc/network/interfaces, для RHEL и CentOS файл /etc/sysconfig/network-scripts/ifcfg-eth0 с параметрами GATEWAY и METRIC. В Ubuntu с Netplan шлюз задают в YAML-файле в /etc/netplan и применяют командой netplan apply. Отдельный разбор этой схемы с готовыми конфигами есть в статье о маршрутизации в Debian без NetworkManager.
Предупреждение для облачных и виртуальных машин: cloud-init и DHCP-клиент могут перезаписывать сетевые настройки при каждом запуске. Если маршрут исчезает после ребута, сначала проверьте, не управляет ли интерфейсом cloud-init. Больше приёмов работы с ip route и таблицами маршрутизации собрано в статье о статической маршрутизации в Linux.
Настройка шлюза по умолчанию в Windows
В Windows маршрут по умолчанию добавляют командой route add с адресом 0.0.0.0 и маской 0.0.0.0. Команда требует прав администратора.
Команды route add и route print
route add 0.0.0.0 mask 0.0.0.0 192.168.1.1 route add 0.0.0.0 mask 0.0.0.0 192.168.1.1 metric 10 if 12 route print -4 route delete 0.0.0.0
Ключ metric задаёт приоритет, if - номер интерфейса из списка Interface List в выводе route print. В route print -4 ищите строку с адресом 0.0.0.0 и маской 0.0.0.0: в ней указаны шлюз, адрес интерфейса и метрика. Если таких строк несколько, работает та, у которой суммарная метрика меньше. Шпаргалка по route и netsh с примерами для VPN и корпоративных схем собрана в статье о командах route и netsh в Windows.
Постоянный маршрут с ключом -p
route -p add 0.0.0.0 mask 0.0.0.0 192.168.1.1 route delete 0.0.0.0
Ключ -p сохраняет маршрут в реестре, и запись восстанавливается после перезагрузки. Без -p маршрут действует до перезапуска системы. В PowerShell те же задачи решает командлет New-NetRoute; по умолчанию он пишет маршрут в активное хранилище, поэтому для сохранения добавляйте -PolicyStore PersistentStore.
New-NetRoute -DestinationPrefix 0.0.0.0/0 -NextHop 192.168.1.1 -InterfaceIndex 12 -PolicyStore PersistentStore Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -Confirm:$false Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 10
В графическом интерфейсе шлюз задают в свойствах подключения: Протокол Интернета версии 4 (TCP/IPv4), поле «Основной шлюз». Метрика интерфейса настраивается там же через кнопку «Дополнительно».
Настройка шлюза по умолчанию на сетевом оборудовании (Cisco)
На маршрутизаторе или L3-коммутаторе Cisco маршрут по умолчанию задают статической записью с префиксом 0.0.0.0/0.
Команда ip route 0.0.0.0 0.0.0.0
ip route 0.0.0.0 0.0.0.0 192.168.1.1 ip route 0.0.0.0 0.0.0.0 192.168.1.1 10 ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1
Первый вариант указывает next-hop. Второй добавляет administrative distance (в примере 10), что позволяет держать резервный default-маршрут с большим значением: он активируется, когда основной перестанет быть доступен. Третий вариант применяют на интерфейсах типа point-to-point, где next-hop задавать не требуется.
Проверка и удаление default-маршрута
show ip route | include 0.0.0.0 no ip route 0.0.0.0 0.0.0.0 192.168.1.1 copy running-config startup-config
В таблице маршрутизации Cisco статический default отображается строкой S* 0.0.0.0/0 [1/0] via 192.168.1.1: S означает static, звёздочка подтверждает выбор записи как маршрута по умолчанию, а в скобках указаны administrative distance и метрика. Маршрут, полученный по OSPF или EIGRP, будет помечен D* или O*. Без команды copy running-config startup-config настройка не сохранится в NVRAM и пропадёт после перезагрузки устройства.
У других вендоров синтаксис отличается: у Huawei это ip route-static 0.0.0.0 0.0.0.0 192.168.1.1, у Juniper - static route 0.0.0.0/0 next-hop 192.168.1.1 в конфигурации. Принцип выбора маршрута остаётся тем же.
Как проверить маршрут по умолчанию
Достаточно одной команды на платформу:
| Платформа | Команда | Характерная строка вывода |
|---|---|---|
| Linux | ip route show | grep default | default via 192.168.1.1 dev eth0 proto static metric 100 |
| Windows | route print -4 | 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.50 25 |
| Cisco | show ip route | include 0.0.0.0 | S* 0.0.0.0/0 [1/0] via 192.168.1.1 |
Как читать вывод. В Linux строка default via <адрес> dev <интерфейс> означает, что весь неспецифичный трафик уходит через этот шлюз и этот интерфейс. В Windows в строке 0.0.0.0 0.0.0.0 сначала идёт шлюз, затем адрес интерфейса, а в конце - метрика. В Cisco звёздочка рядом с S подтверждает, что запись выбрана как маршрут по умолчанию.
Дополнительные проверки: ip route get 8.8.8.8 в Linux показывает выбранный маршрут и его источник, ipconfig /all в Windows выводит шлюз по каждому адаптеру, ping шлюза проверяет доступность next-hop. Если строки default в таблице нет, внешние адреса будут недостижимы при отсутствии других маршрутов к ним. Пошаговый разбор смены шлюза с сохранением настройки есть в статье о просмотре и изменении default gateway.
Синтаксис ключей и имена параметров отличаются между версиями ОС и моделями оборудования (netplan в разных выпусках Ubuntu, Windows Server и Windows 11, IOS и IOS XE), поэтому перед правкой сверяйтесь с документацией своей версии и проверяйте результат командой просмотра таблицы маршрутизации.
Типовые сбои и их устранение
Три сценария закрывают большинство обращений: конкуренция нескольких default-маршрутов, конфликт шлюзов в одной подсети и потеря маршрута после перезагрузки.
Несколько default-маршрутов с разными метриками
Симптом: интернет работает, но трафик идёт через другой интерфейс, чем ожидалось, либо скорость и задержки не совпадают с параметрами основного канала. Диагностика: ip route show в Linux, route print в Windows, show ip route в Cisco покажут несколько записей с 0.0.0.0.
# Linux: посмотреть все default-маршруты с метриками ip route show default # Linux: удалить лишний маршрут ip route del default via 192.168.1.2 dev eth1
# Windows: удалить лишний маршрут route delete 0.0.0.0 mask 0.0.0.0 192.168.1.2 # Windows: понизить приоритет адаптера Set-NetIPInterface -InterfaceIndex 15 -InterfaceMetric 50
Работает маршрут с наименьшей метрикой. Метрика может выставляться автоматически в зависимости от типа и скорости интерфейса, поэтому после подключения нового адаптера, VPN-туннеля или модема таблица меняется без участия администратора. Явное значение метрики снимает неоднозначность.
Конфликт шлюзов
Конфликт возникает, когда в одной подсети объявлены два разных шлюза по умолчанию. Типовой источник - DHCP-сервер выдаёт один адрес, а в конфигурации интерфейса вручную прописан другой. Вторая частая причина - два DHCP-сервера в сегменте.
Что делать: сравнить адрес шлюза из аренды DHCP и из статической конфигурации (ip route show, ipconfig /all или show ip route), затем оставить один корректный шлюз и удалить ошибочный маршрут. Если адрес приходит по DHCP, надёжнее исправить настройку сервера или исключить раздачу маршрута по умолчанию для клиента, чем править таблицу руками на каждом хосте.
Маршрут исчезает после перезагрузки
Причина в способе добавления: команды ip route add и route add без ключа -p действуют до перезагрузки или перезапуска сетевой службы. Варианты закрепления:
- Linux: настройки NetworkManager (nmcli), systemd-networkd, /etc/network/interfaces, Netplan или /etc/sysconfig/network-scripts.
- Windows: route -p add либо New-NetRoute с ключом -PolicyStore PersistentStore.
- Cisco: copy running-config startup-config или write memory после настройки.
Отдельно проверьте, не перезаписывает ли конфигурацию cloud-init, DHCP-клиент или система управления конфигурациями. В таких средах ручная правка файлов не поможет: маршрут добавляют в шаблон, которым управляет автоматика. При нескольких сетевых интерфейсах всегда указывайте интерфейс явно (dev eth0 в Linux, if <номер> в Windows, выходной интерфейс в Cisco), иначе выбор может оказаться не тем, что вы ожидаете.
Чек-лист диагностики: трафик уходит не через тот интерфейс
Проходите пункты по порядку и останавливайтесь на первом, который дал расхождение с ожидаемой схемой.
- Посмотрите таблицу маршрутизации: ip route show (Linux), route print -4 (Windows), show ip route (Cisco). Найдите все строки default.
- Проверьте, что default указывает на нужный шлюз и нужный интерфейс. В Linux это видно по параметру dev в строке default, в Windows - по номеру интерфейса в строке 0.0.0.0.
- Сравните метрики. Если default-маршрутов несколько, трафик пойдёт по меньшей метрике; лишние записи удалите или поднимите их метрику.
- Определите реально выбранный маршрут: ip route get 8.8.8.8 в Linux, Find-NetRoute -RemoteIPAddress 8.8.8.8 в PowerShell, tracert 8.8.8.8 для проверки пути.
- Проверьте доступность шлюза: ping 192.168.1.1. Нет ответа - проблема на уровне L2, ARP или VLAN, а не в таблице маршрутизации.
- Убедитесь, что рядом нет более специфичного маршрута: VPN-туннель, сеть docker0 или мост в контейнерных средах, политики маршрутизации (ip rule show) уводят трафик мимо default.
- Проверьте источник адреса шлюза: ipconfig /all или содержимое аренды DHCP - второго адреса маршрутизатора там быть не должно.
- Проверьте фильтрацию и трансляцию адресов: nft list ruleset, iptables -t nat -L -n, правила NAT на пограничном устройстве. Заблокированный ICMP или отсутствующий NAT дают похожую картину: маршрут есть, связи нет.
- Если сбой появился после изменений, сравните слепок таблицы до и после и верните предыдущую конфигурацию. Обзор практик маршрутизации и диагностики для офисных сетей собран в статье об IP-маршрутизации и диагностике.
Начните с одной команды: ip route show default, route print -4 или show ip route | include 0.0.0.0. Она сразу показывает, есть ли шлюз по умолчанию, какой у него адрес, интерфейс и метрика. Дальше правьте только то, что расходится с ожидаемой схемой, и проверяйте результат той же командой до перезагрузки и после неё.