Команды для диагностики сетевых интерфейсов Linux: практическая шпаргалка

Для проверки сетевого интерфейса Linux начните с пяти команд: ip -br link, ip -br addr, ip route, ss -lntup и ping. Они показывают состояние линка, назначенные адреса, маршруты, открытые порты и доступность узла.

Базовая последовательность выглядит так: проверить, поднят ли интерфейс, убедиться в наличии IPv4 или IPv6-адреса, найти маршрут к нужному узлу, проверить шлюз, затем проверить DNS и порт приложения. Если проблема связана с физическим подключением, добавьте ethtool. При управлении сетью через NetworkManager используйте nmcli.

ip -br link
ip -br addr
ip route
ss -lntup
ping -c 4 192.0.2.1
tracepath -n 203.0.113.10

Адреса 192.0.2.1 и 203.0.113.10 приведены как примеры. Подставьте IP шлюза и проверяемого узла. Команды просмотра обычно доступны обычному пользователю, но для изменения настроек, чтения счетчиков драйвера и анализа трафика потребуются права root или sudo.

Дерево страниц

Диагностику удобнее строить как последовательное дерево проверок. Каждый следующий шаг имеет смысл после успешного предыдущего.

1. Интерфейс: команда ip -br link показывает имя устройства и состояние UP или DOWN.
2. Линк: команда ethtool eth0 сообщает, обнаружен ли физический сигнал, какую скорость и дуплекс согласовали устройства.
3. Адрес: команда ip -br addr show dev eth0 показывает IPv4 и IPv6-адреса, назначенные интерфейсу.
4. Маршрут: команда ip route get 203.0.113.10 показывает, через какой интерфейс и шлюз уйдет пакет.
5. Сосед: команда ip neigh show dev eth0 помогает проверить ARP для IPv4 или Neighbor Discovery для IPv6.
6. Доступность: команда ping -c 4 GATEWAY_IP отделяет локальную проблему от неполадки за шлюзом.
7. Путь: команда tracepath -n 203.0.113.10 показывает промежуточные узлы и обнаруженное значение MTU.
8. Приложение: команда ss -lntup помогает проверить, слушает ли нужный сервис порт и на каком адресе он принимает соединения.

Если интерфейс отсутствует в выводе ip link, проверяйте имя устройства, драйвер и виртуальный сетевой namespace. Если интерфейс виден, но имеет состояние DOWN, причина обычно связана с административным отключением или настройками менеджера сети.

Для общего знакомства с командами Linux и базовым администрированием пригодится практическое руководство по Linux для DevOps и системных администраторов.

Архитектурный паттерн

Сетевой стек Linux удобно проверять по уровням. Ошибка на нижнем уровне делает проверки выше по цепочке малоинформативными.

Сетевой интерфейс может существовать одновременно в нескольких контекстах. Физический порт хоста подключается к bridge, bridge связывает виртуальные Ethernet-устройства контейнеров, а каждый namespace получает собственный набор адресов, маршрутов и сокетов. Поэтому команда, выполненная на хосте, не всегда показывает состояние сети внутри контейнера.

Минимальный снимок состояния

ip -br link
ip -br addr
ip -s link show dev eth0
ip route show
ip neigh show
ss -s
resolvectl status

В выводе ip -s link смотрите счетчики RX и TX. Поля errors, dropped, overrun и carrier требуют отдельной проверки. Рост RX dropped может указывать на переполнение очереди или фильтрацию, а увеличение carrier часто связано с потерей физического линка.

Функциональные возможности

Команды распределяются по задачам. Одна команда показывает конфигурацию, другая помогает проверить фактическое поведение сети.

Команда ip

ip link show
ip -br link
ip addr show dev eth0
ip -s link show dev eth0
ip route show table main
ip route get 203.0.113.10
ip rule show
ip neigh show

Ключ -br включает краткий формат, удобный для быстрого просмотра нескольких интерфейсов. В выводе ip addr префикс /24 означает маску сети 255.255.255.0. Строка scope link у маршрута указывает на непосредственно подключенную сеть, а строка с default via задает маршрут по умолчанию.

Команды ss и ethtool

ss -lntup
ss -lunp
ss -tan state established
ss -tan state time-wait
ethtool eth0
ethtool -i eth0
ethtool -S eth0

В ss -lntup параметры означают TCP, UDP, числовой вывод, слушающие сокеты и сведения о процессе. Если сервис слушает 127.0.0.1:8080, подключения через адрес интерфейса не пройдут. Для удаленного доступа процесс должен слушать подходящий адрес, например 0.0.0.0:8080 или конкретный адрес сервера.

В выводе ethtool поле Link detected показывает наличие физического линка, Speed сообщает согласованную скорость, Duplex показывает режим дуплекса, а Auto-negotiation отражает состояние автосогласования. Подкоманда -S зависит от драйвера, поэтому набор счетчиков у разных адаптеров отличается.

Команды nmcli, ping и tracepath

nmcli device status
nmcli connection show --active
nmcli device show eth0
ping -c 4 -W 2 GATEWAY_IP
ping -4 -c 4 DEST_IP
ping -6 -c 4 DEST_IPV6
tracepath -n DEST_IP
getent ahosts internal.example
resolvectl query internal.example

ping проверяет ICMP, поэтому отсутствие ответа не всегда означает полную недоступность узла. Межсетевой экран может блокировать ICMP при работающем TCP-порту. tracepath использует механизм определения пути и показывает значение pmtu, которое помогает находить проблемы с размером пакетов.

Backend-сервисы

На Linux за сетевую конфигурацию могут отвечать NetworkManager, systemd-networkd, netplan, встроенный DHCP-клиент или комбинация этих компонентов. Одновременное управление одним интерфейсом несколькими службами часто приводит к смене адреса, маршрута или DNS после перезапуска.

systemctl is-active NetworkManager
systemctl is-active systemd-networkd
networkctl status eth0
nmcli general status
nmcli -f GENERAL,IP4,IP6 device show eth0
resolvectl status

Если активен NetworkManager, ищите профиль в выводе nmcli connection show. Для systemd-networkd полезны networkctl и журнал службы.

journalctl -u NetworkManager -b --no-pager
journalctl -u systemd-networkd -b --no-pager
journalctl -b | grep -Ei 'dhcp|carrier|link|network'

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

Проверка DHCP и DNS

ip addr show dev eth0
ip route show
resolvectl status
resolvectl query internal.example
getent hosts internal.example

resolvectl query обращается к системному resolved, а getent hosts проверяет путь разрешения имен через NSS. Разница между командами помогает понять, проблема находится в DNS-резолвере или в настройке приложений.

Для диагностики не подменяйте проверку DNS проверкой IP. Сначала выполните ping DEST_IP, затем getent hosts internal.example, после чего проверьте порт приложения через ss или тестовый клиент. Такая последовательность отделяет ошибку маршрута от ошибки имени.

Инфраструктурные сервисы

В серверной инфраструктуре один физический интерфейс может участвовать в VLAN, bond, bridge или виртуальной сети. Для каждого слоя нужна отдельная проверка.

VLAN, bridge и bonding

ip -d link show
ip -d link show vlan10
bridge link
bridge vlan show
cat /proc/net/bonding/bond0
ip route show

У VLAN проверяйте идентификатор тега и родительский интерфейс. У bridge смотрите, добавлен ли нужный порт и какое состояние STP у него установлено. Файл /proc/net/bonding/bond0 показывает режим bond, активный slave, состояние линка и скорость участников.

MTU и фрагментация

ip link show dev eth0
tracepath -n DEST_IP
ping -M do -s 1472 -c 3 GATEWAY_IP

Для Ethernet с MTU 1500 размер ICMP-полезной нагрузки IPv4 часто составляет 1472 байта: 20 байт занимает IP-заголовок и 8 байт ICMP-заголовок. Если пакет с флагом DF не проходит, уменьшайте размер и фиксируйте максимальное значение. В туннелях, VPN и VXLAN допустимый размер может быть ниже из-за дополнительных заголовков.

Проверка среды размещения

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

Внешний фильтр проверяют вместе с локальными правилами. Внутри хоста полезны:

sudo nft list ruleset
sudo ss -lntup
sudo tcpdump -ni eth0 'host CLIENT_IP and port 443'

Если SYN-пакет виден в tcpdump, но ответа SYN-ACK нет, проверяйте локальный firewall и приложение. Если пакет не доходит до интерфейса, ищите причину в маршруте, security group, ACL или настройках виртуального коммутатора.

Frontend (Web GUI)

Графическая панель упрощает просмотр адресов, маршрутов и состояния устройств, но показывает только тот контекст, к которому подключена панель. Для точной проверки сверяйте значения в GUI с выводом ip, ss и журналом сетевой службы.

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

Инструкции по защите доступа к Cockpit и Webmin с проверкой портов собраны в руководстве по настройке и защите веб-интерфейса сервера.

Сетевая архитектура (Docker сети)

Docker создает отдельные сетевые пространства имен, bridge и виртуальные Ethernet-пары. Поэтому диагностика контейнера состоит из проверки хоста, Docker-сети и самого namespace контейнера.

Проверка сети Docker

docker network ls
docker network inspect bridge
ip link show type bridge
bridge link
ip link show type veth

docker network inspect показывает подсеть, шлюз, IPAM и подключенные контейнеры. На хосте bridge обычно виден как отдельный интерфейс, а veth связывает его с namespace контейнера.

Проверка из контейнера

docker exec CONTAINER ip -br addr
docker exec CONTAINER ip route
docker exec CONTAINER cat /etc/resolv.conf
docker exec CONTAINER getent hosts internal.example
docker exec CONTAINER ping -c 2 CONTAINER_OR_GATEWAY_IP

Если команда ip отсутствует в минимальном образе, проверяйте маршрут через доступный клиент приложения или временно используйте диагностический контейнер в той же сети. Для просмотра namespace с хоста найдите PID процесса и выполните:

docker inspect -f '{{.State.Pid}}' CONTAINER
nsenter -t CONTAINER_PID -n ip addr
nsenter -t CONTAINER_PID -n ip route
nsenter -t CONTAINER_PID -n ss -lntup

Порт, опубликованный Docker, проверяйте в двух местах: в контейнере процесс должен слушать нужный порт, а на хосте ss -lntup должен показывать опубликованный порт. Прослушивание только на 127.0.0.1 внутри контейнера не подходит для доступа через его сетевой адрес.

Режимы работы

Сетевые проблемы часто появляются после изменения административного состояния интерфейса, MTU, автосогласования или режима управления NetworkManager.

Административное состояние

ip link show dev eth0
sudo ip link set dev eth0 up
sudo ip link set dev eth0 down

Команда ip link set dev eth0 up включает интерфейс на текущий запуск системы. Она не сохраняет настройку в профиле NetworkManager или файле systemd-networkd. Команда down немедленно оборвет соединения через устройство, поэтому удаленный сервер лучше менять через консоль или резервный канал.

Автосогласование, offload и promisc

ethtool eth0
ethtool -k eth0
ethtool -c eth0
ip link show dev eth0
sudo ip link set dev eth0 promisc on

Опции ethtool -k показывают checksum offload, TSO, GSO и GRO. Эти функции могут менять вид пакетов при захвате через tcpdump, поэтому при анализе счетчиков учитывайте обработку offload. Promiscuous mode нужен bridge, гипервизору и отдельным средствам мониторинга, но сам по себе не исправляет потерю пакетов.

Управление NetworkManager

nmcli device status
nmcli device show eth0
nmcli connection show
nmcli connection show --active
nmcli device set eth0 managed yes

Статус unmanaged означает, что NetworkManager не меняет состояние устройства. Причина может находиться в конфигурации дистрибутива, файлах netplan или настройках конкретного профиля. Перед переводом устройства в режим управления проверьте, какая служба сейчас задает адрес и маршрут.

Backend

Сетевой backend сервера включает ядро, драйвер интерфейса, сетевой менеджер, firewall и процессы, которые слушают TCP или UDP-порты. Диагностируйте эти компоненты в указанном порядке.

Проверка слушающих сервисов

ss -lntup
ss -lunp
ss -tnp state established
ss -tnp state syn-recv
ss -tnp state time-wait

LISTEN означает готовность TCP-сокета принимать соединения. SYN-RECV показывает незавершенные входящие TCP-сеансы. Большое число таких записей требует проверки нагрузки, фильтрации и доступности процесса. TIME-WAIT после закрытых соединений обычно нормально, но резкий рост может указывать на большое число коротких подключений.

Проверка прохождения пакета

sudo tcpdump -ni eth0 'host CLIENT_IP and port 443'
sudo tcpdump -ni any 'icmp or icmp6'
sudo nft list ruleset
ip route get CLIENT_IP

Сначала определите ожидаемый интерфейс через ip route get CLIENT_IP. Затем запустите захват на этом интерфейсе и повторите подключение. Входящий SYN без ответа указывает на проблему после доставки пакета на хост: firewall, bind-адрес или процесс. Ответ RST обычно означает, что порт закрыт или приложение отклонило соединение.

Типовые сценарии

• Нет IP-адреса: проверьте DHCP-журнал, профиль NetworkManager и состояние линка.
• Есть IP, но нет шлюза: изучите ip route и параметры профиля.
• Шлюз доступен, удаленный IP недоступен: выполните tracepath и проверьте обратный маршрут.
• IP доступен, имя не разрешается: сравните resolvectl status и getent ahosts.
• Порт закрыт: проверьте ss -lntup, bind-адрес процесса и правила nftables.
• Есть потери и ошибки RX/TX: сопоставьте счетчики ip -s link с результатом ethtool -S, скоростью и дуплексом.

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

Frontend

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

Проверка по слоям

getent ahosts APP_HOST
ping -c 4 APP_IP
tracepath -n APP_IP
ss -lntup
curl -v http://APP_HOST:APP_PORT

Если имя не разрешается, переходите к DNS. Если имя разрешается, но ICMP не отвечает, проверяйте маршрут и правила фильтрации. Если IP доступен, а TCP-соединение не устанавливается, анализируйте порт через ss и tcpdump. Ответ HTTP с кодом 4xx или 5xx означает, что сеть уже доставила запрос до приложения, поэтому нужно читать журнал frontend-сервера и backend-сервиса.

Короткий чек-лист после изменения сети

1. Сохраните исходный вывод ip -br link, ip -br addr и ip route.
2. Проверьте, что нужный интерфейс имеет состояние UP и ожидаемый адрес.
3. Сравните маршрут к клиенту и маршрут по умолчанию через ip route get.
4. Проверьте шлюз и целевой IP командами ping с ограничением в 3-4 пакета.
5. Проверьте разрешение имени через getent или resolvectl.
6. Убедитесь, что сервис слушает нужный адрес и порт через ss -lntup.
7. При подозрении на MTU запустите tracepath и тест с флагом DF.
8. При входящей проблеме подтвердите наличие пакета через tcpdump.
9. Повторите тест из реальной клиентской сети, потому что локальная проверка не показывает фильтрацию на внешнем маршрутизаторе.

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