Короткий ответ: как проверить маршрутизацию в Linux
Сетевая проблема на Linux-маршрутизаторе решается последовательной проверкой уровней: физический интерфейс, IP-адрес, локальный маршрут, соседний узел, шлюз, удалённый маршрут, сервис и правила фильтрации. Начните с команд ip -br addr и ip route, затем проверьте конкретный путь через ip route get, доступность шлюза через ping и состояние соседей через ip neigh. Отсутствие ответа ping не всегда означает обрыв маршрута: ICMP может блокироваться, поэтому сопоставляйте результаты с захватом пакетов tcpdump и состоянием TCP-соединений в ss. Такой порядок исключает случайный перебор гипотез и быстро локализует точку отказа.
Последовательность проверки от локального уровня к удаленному
Диагностика идёт от ближайшего к дальнему. Сначала убедитесь, что интерфейс административно включён и физически активен: ip -br link покажет состояние UP или DOWN. Затем проверьте IP-адреса и маски: ip -br addr выведет назначенные адреса. Далее изучите таблицу маршрутизации: ip route покажет маршруты, а ip route get <адрес> определит фактический путь. После этого проверьте соседние записи: ip neigh show отобразит ARP/NDP-кэш. Только после этого тестируйте связность с шлюзом и удалёнными узлами через ping и traceroute. В конце анализируйте сервисы и firewall: ss -lntup для слушающих портов, tcpdump -ni <интерфейс> для захвата пакетов, nft list ruleset для правил фильтрации.
Минимальный набор команд для первичной проверки
Для быстрого сбора данных выполните следующие команды:
ip -br addr- адреса и интерфейсы;ip route- таблица маршрутов;ip route get <адрес>- фактический путь до цели;ping <адрес>- базовая связность;traceroute <адрес>- маршрут до узла;ss -lntup- слушающие сокеты;tcpdump -ni <интерфейс>- захват пакетов;nft list ruleset- правила фильтрации.
Каждая команда отвечает на свой вопрос. Например, ip route get показывает, какой интерфейс и шлюз будут использованы, а ss подтверждает, что приложение действительно слушает порт. Совместный анализ вывода этих команд позволяет отличить проблему маршрутизации от проблем сервиса или firewall.
Проверка сети в Linux: интерфейсы и IP-адреса
Начните с проверки состояния сетевых интерфейсов. Команда ip -br link выведет список интерфейсов с состоянием: UP или DOWN. Состояние UP означает, что интерфейс административно включён, но не гарантирует физическое соединение. Для проверки физического линка используйте ip -s link и смотрите на счётчики ошибок: рост RX/TX errors, dropped, overruns или carrier errors указывает на проблемы кабеля, порта коммутатора или несовместимость скоростей. Если интерфейс включён, но линка нет, проверьте кабель, порт и настройки автосогласования.
Состояние link и счетчики ошибок
Пример вывода ip -br link:
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 UP 00:16:3e:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>
eth1 DOWN 00:16:3e:12:34:57 <BROADCAST,MULTICAST>Здесь eth0 активен, а eth1 выключен. Для детального просмотра ошибок выполните ip -s link show eth0. Обратите внимание на поля RX errors, TX errors, dropped и carrier. Ненулевые значения могут указывать на физические проблемы или перегрузку.
IP-адреса, маски и исходный адрес
Проверьте назначенные адреса командой ip -br addr:
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.1.1/24 fe80::216:3eff:fe12:3456/64
eth1 DOWN 10.0.0.1/24Убедитесь, что адрес и маска соответствуют ожидаемой подсети. Ошибки: адрес назначен не тому интерфейсу, слишком широкая или узкая маска, отсутствует IPv6 link-local. Если на интерфейсе несколько адресов, проверьте выбор исходного адреса: ip route get <адрес> покажет, какой source будет использован.
VLAN, bridge и несколько интерфейсов
Если используются VLAN или bridge, проверьте их конфигурацию. Команда ip -d link show покажет тип интерфейса и связанные параметры. Например, для VLAN-интерфейса отобразится VLAN ID. Убедитесь, что VLAN ID соответствует ожидаемому, а bridge содержит нужные порты: bridge link show. Ошибки в VLAN или bridge приводят к тому, что IP-адрес формально настроен, но трафик не проходит.
Команда ip route Linux: таблица маршрутизации и шлюз
Таблица маршрутизации определяет, куда Linux отправит пакет. Просмотрите её командой ip route:
default via 192.168.1.254 dev eth0 proto static
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1Запись default via 192.168.1.254 dev eth0 означает, что весь трафик, не попавший в другие маршруты, пойдёт через шлюз 192.168.1.254. Маршруты к подключённым сетям обычно не имеют via. Если маршрут отсутствует, пакет не будет отправлен.
Как читать таблицу маршрутизации
Поля записи: destination/prefix, via (шлюз), dev (интерфейс), metric (приоритет), proto (источник маршрута: kernel, static, dhcp и т.д.), src (исходный адрес). Маршрут с меньшей метрикой предпочтительнее. При наличии нескольких маршрутов к одной сети выбирается более специфичный (с большей длиной префикса).
Проверка фактического выбора через ip route get
Команда ip route get <адрес> показывает, какой маршрут будет использован для указанного адреса. Пример:
ip route get 8.8.8.8
8.8.8.8 via 192.168.1.254 dev eth0 src 192.168.1.1 uid 0
cacheЭто подтверждает, что пакет к 8.8.8.8 уйдёт через eth0 и шлюз 192.168.1.254. Если используется policy routing, проверьте правила: ip rule show. Правила могут направлять трафик в отдельные таблицы.
Как проверить шлюз в Linux
Получите адрес шлюза из маршрута, затем проверьте его доступность: ping -c 4 192.168.1.254. Если ping не проходит, проверьте соседнюю запись: ip neigh show 192.168.1.254. Состояние REACHABLE или STALE означает, что MAC-адрес известен. Если состояние FAILED или INCOMPLETE, есть проблема на канальном уровне. Успешный ping шлюза подтверждает только локальный участок, но не гарантирует маршрут дальше.
IP forwarding и обратный маршрут
Для работы Linux как маршрутизатора должен быть включён IP forwarding. Проверьте: sysctl net.ipv4.ip_forward. Для IPv6: sysctl net.ipv6.conf.all.forwarding. Если значение 0, транзитный трафик не будет пересылаться. Включите временно: sysctl -w net.ipv4.ip_forward=1. Для постоянной настройки отредактируйте /etc/sysctl.conf. Также убедитесь, что у удалённой стороны есть обратный маршрут. Асимметричный трафик может отбрасываться из-за rp_filter: проверьте sysctl net.ipv4.conf.all.rp_filter.
ARP, NDP и MTU: почему маршрут есть, а пакет не проходит
Если таблица маршрутизации корректна, но пакеты не доходят, проверьте разрешение адресов соседей и размер пакета. ARP (IPv4) и NDP (IPv6) связывают IP-адрес с MAC-адресом. Команда ip neigh show отобразит кэш соседей:
192.168.1.254 dev eth0 lladdr 00:1b:21:3a:4b:5c REACHABLE
192.168.1.10 dev eth0 INCOMPLETEСостояние INCOMPLETE означает, что запрос отправлен, но ответ не получен. FAILED - попытки исчерпаны. Причины: неверный VLAN, неправильная маска, конфликт адресов, недоступный узел.
Состояние соседей через ip neigh
Состояния: REACHABLE (подтверждён), STALE (не обновлялся, но считается действительным), DELAY (ожидание подтверждения), PROBE (повторный запрос), INCOMPLETE (запрос отправлен), FAILED (недоступен). Если нужный сосед в состоянии FAILED, проверьте физическое подключение и конфигурацию VLAN.
Подтверждение ARP/NDP через tcpdump
Захватите ARP-трафик: tcpdump -ni eth0 arp. Вы увидите запросы и ответы. Если запросы уходят, а ответов нет, проблема на стороне соседа или в коммутаторе. Для IPv6 используйте фильтр icmp6 and ip6[40] = 135 or ip6[40] = 136 (Neighbor Solicitation и Advertisement).
Проверка MTU и Path MTU Discovery
MTU (Maximum Transmission Unit) определяет максимальный размер пакета. Проверьте MTU интерфейса: ip link show eth0. Если MTU слишком большой для пути, большие пакеты будут отбрасываться. Тест: ping -M do -s 1472 <адрес> для IPv4 (1472 + 28 = 1500). Для IPv6: ping -6 -M do -s 1452 <адрес>. Если большие пакеты не проходят, а малые проходят, проблема MTU. Path MTU Discovery автоматически определяет меньший MTU, но может блокироваться firewall. Для туннелей (VPN, GRE, VXLAN) уменьшите MTU на величину заголовков.
Проверка сервисов и соединений командой ss
Если сеть работает, но сервис недоступен, проверьте, слушает ли приложение нужный порт. Команда ss -lntup покажет слушающие TCP и UDP сокеты с процессами:
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
LISTEN 0 128 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=5678,fd=5))Если сервис слушает только 127.0.0.1, он недоступен с других хостов. Если процесс не запущен, порт не будет отображаться.
Слушающие TCP- и UDP-порты
Проверьте, что нужный порт открыт и привязан к правильному адресу. Для веб-сервера ожидается 0.0.0.0:80 или 0.0.0.0:443. Если адрес 127.0.0.1, измените конфигурацию приложения.
Состояния соединений и зависший TCP handshake
Просмотрите активные соединения: ss -tan state established. Состояния: SYN-SENT (клиент отправил SYN), SYN-RECV (сервер получил SYN, отправил SYN-ACK), ESTABLISHED (соединение установлено). Если соединение зависает в SYN-SENT, нет ответа от сервера: проверьте firewall, маршрут, доступность порта. Сочетайте с tcpdump: tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' покажет SYN без ответа.
Проверка порта без ложных выводов по ping
Ping проверяет ICMP, а не TCP-порт. Сервис может быть доступен, даже если ping не проходит, и наоборот. Для проверки TCP-порта используйте nc -zv <адрес> <порт> или telnet <адрес> <порт>. Для UDP сложнее: можно использовать nc -u -zv, но надёжнее проверить логи приложения.
Как проверить прохождение пакетов с помощью ping, traceroute и tcpdump
Для точной локализации потери пакетов используйте комбинацию инструментов. Ping даёт быстрый ответ о связности, traceroute показывает путь, tcpdump фиксирует фактический трафик.
Ping: проверка связности по этапам
Выполните последовательность ping:
ping -c 4 127.0.0.1- проверка loopback;ping -c 4 <собственный IP>- проверка локального стека;ping -c 4 <шлюз>- проверка локальной сети;ping -c 4 <удалённый адрес>- проверка маршрута.
Если ping до шлюза не проходит, проблема на канальном уровне или в конфигурации интерфейса. Если шлюз отвечает, а удалённый адрес нет, проблема в маршрутизации или фильтрации.
Traceroute: поиск проблемного перехода
Traceroute показывает маршрут и время ответа каждого узла: traceroute <адрес>. По умолчанию использует UDP-пакеты, но можно указать ICMP (traceroute -I) или TCP (traceroute -T -p 80). Если ответы прекращаются на определённом узле, это может указывать на проблему, но не всегда: ICMP Time Exceeded может фильтроваться. Сравните с tcpdump.
Tcpdump на входе и выходе
Захватите трафик на интерфейсах: tcpdump -ni eth0 host <адрес>. На внешнем интерфейсе вы увидите исходящие пакеты, на внутреннем - входящие. Если пакет пришёл на внутренний интерфейс, но не вышел на внешний, проблема в маршрутизации или firewall. Если вышел, но ответа нет, проблема на удалённой стороне или обратном пути. Используйте фильтры: tcpdump -ni eth0 'tcp port 80' для HTTP, tcpdump -ni eth0 'icmp' для ICMP.
Диагностика firewall в Linux с помощью nft
Правила nftables могут блокировать трафик. Просмотрите набор правил: nft list ruleset. Вывод покажет таблицы, цепочки и правила. Обратите внимание на цепочку forward, которая обрабатывает транзитный трафик.
Проверка цепочки forward и политики по умолчанию
Если политика цепочки forward - drop, а разрешающих правил нет, весь транзитный трафик блокируется. Пример:
table inet filter {
chain forward {
type filter hook forward priority 0; policy drop;
# нет разрешающих правил
}
}Добавьте разрешающие правила или измените политику. Проверьте, что правила учитывают оба направления: запрос и ответ.
Счетчики правил, логирование и conntrack
Используйте счётчики, чтобы увидеть, какие правила срабатывают: nft list ruleset с опцией -a покажет счётчики. Для отладки добавьте временное правило с логированием: nft add rule inet filter forward log prefix "FORWARD: ". Проверьте conntrack: conntrack -L покажет активные соединения. Для ответного трафика должно быть состояние established,related.
NAT и обратный трафик
Если используется NAT, проверьте правила masquerade или SNAT: nft list table nat. Убедитесь, что masquerade применяется на исходящем интерфейсе. Обратный трафик должен сопоставляться с исходным соединением через conntrack. Если ответ не возвращается, проверьте обратный маршрут и правила forward.
Типовые сценарии диагностики сетевых проблем Linux
Рассмотрим частые симптомы и способы их устранения.
Нет маршрута или выбран неправильный интерфейс
Симптом: ping выдаёт «Network is unreachable» или пакет уходит через неверный шлюз. Проверьте ip route, ip route get <адрес>, ip rule. Добавьте маршрут: ip route add <сеть> via <шлюз> dev <интерфейс>. После изменения повторите ip route get и проверьте обратный путь.
Шлюз не отвечает, запись ARP имеет состояние FAILED
Симптом: ping до шлюза не проходит, ip neigh показывает FAILED. Проверьте link, адрес и маску интерфейса, VLAN, bridge. Захватите ARP: tcpdump -ni eth0 arp. Возможные причины: неверный VLAN ID, отключенный порт, дублирование IP, неправильная маска.
Ping проходит, но TCP-сервис недоступен
Симптом: ping до сервера успешен, но подключение к порту не устанавливается. Проверьте ss -lntup на сервере, выполните тест порта: nc -zv <адрес> <порт>. Посмотрите SYN и SYN-ACK в tcpdump. Проверьте правила input или forward в nft. Учтите привязку сервиса к localhost.
Пакет выходит, но ответа нет
Симптом: tcpdump на исходящем интерфейсе показывает пакеты, но ответы не приходят. Проверьте tcpdump на входящем интерфейсе, маршрут удалённой стороны, firewall назначения, NAT и обратный маршрут. Сравните тест из разных источников.
Трафик проходит только в одну сторону
Симптом: запросы доходят, ответы нет. Снимите трафик на обоих интерфейсах в обе стороны. Проверьте ip route get с адресами источника и назначения, ip rule, rp_filter, nft forward, conntrack. Асимметричная маршрутизация может приводить к отбрасыванию пакетов.
Малые пакеты проходят, большие зависают
Симптом: ping с малым размером успешен, с большим - нет. Сравните: ping -c 4 -s 100 <адрес> и ping -c 4 -s 1400 <адрес> (для IPv4). Проверьте MTU на всех участках, tcpdump ICMP-сообщений об ошибке. Уменьшите MTU на интерфейсе или настройте MSS clamping.
Проверка результата после исправления
После внесения изменений убедитесь, что проблема устранена полностью.
Контрольный тест в обе стороны
Проверьте трафик от клиента к серверу и обратно. Для TCP сопоставьте ss и tcpdump, для маршрутизации повторите ip route get с обоими направлениями. Проверьте доступ к нескольким адресам из разных подсетей.
Проверка сохранности конфигурации
Команды ip и временные изменения nft меняют текущее состояние, но не сохраняются после перезагрузки. Убедитесь, что постоянная конфигурация записана: для маршрутов и адресов - в файлах дистрибутива (например, /etc/network/interfaces или netplan), для nftables - в /etc/nftables.conf. После настройки выполните контролируемый перезапуск сетевого сервиса и проверьте, что всё работает.
Что зафиксировать в отчете о диагностике
Зафиксируйте: время и направление теста, вывод ip addr, ip route, ip route get, ip neigh, ss, результаты ping и traceroute, фрагменты tcpdump, релевантные правила nft и внесённые изменения. Это поможет при повторных инцидентах.
Шпаргалка: команды для диагностики сети Linux
Соберите команды в порядке диагностики.
Интерфейсы, адреса и маршруты
ip -br addr- адреса и интерфейсы;ip -s link- счётчики ошибок;ip route- таблица маршрутов;ip route get <адрес>- фактический путь;ip rule- policy routing;sysctl net.ipv4.ip_forward- проверка forwarding.
Связность, соседи и MTU
ping -c 4 <адрес>- связность;traceroute <адрес>- маршрут;ip neigh show- ARP/NDP;ping -M do -s <размер> <адрес>- тест MTU.
Порты, пакеты и фильтрация
ss -lntup- слушающие порты;tcpdump -ni <интерфейс> host <адрес>- захват пакетов;nft list ruleset- правила firewall;conntrack -L- состояния соединений.