Основные сетевые команды Linux

В современном Linux основные сетевые команды входят в состав пакета iproute2: ip показывает интерфейсы и маршруты, ss выводит список сокетов и прослушиваемых портов, а ip neigh читает ARP-кэш.

Если вы когда-нибудь подключались к свежему контейнеру, по чистой привычке набирали ifconfig и получали в ответ command not found — вот почему это происходит. Мышечная память пережила сами бинарники на добрый десяток лет.

Эти команды заменяют старые бинарники из net-tools (ifconfig, route, netstat, arp), которые Red Hat относит к числу команд, от использования которых стоит отказаться и которые в текущих дистрибутивах часто вообще не установлены. В этом справочнике команды сгруппированы по решаемым задачам (проверка интерфейсов, маршрутизация, связность, DNS, порты и трафик), а в конце приведена схема диагностики «симптом → команда», которую можно пройти от начала до конца.

Что заменило ifconfig, netstat и route в Linux?

Пакет net-tools считается устаревшим с начала 2000-х, а активно развиваемой заменой является iproute2. Пакет net-tools-deprecated в openSUSE документирует каноническое соответствие «один к одному»:

Предпочтительнее использовать вариант из iproute2. В минимальном контейнере или на свежем сервере устаревших бинарников может просто не быть, поэтому скрипты, вызывающие ifconfig или netstat, падают с ошибкой command not found.

Интерфейсы и адреса

ip addr (или алиас ip a) показывает все интерфейсы и назначенные им адреса IPv4/IPv6 — это современный аналог ifconfig. Используйте ip link, чтобы поднять или отключить интерфейс, и hostname -I, чтобы вывести только IP-адреса машины.

ip addr                       # all interfaces + addresses (alias: ip a)
ip addr show eth0             # one interface only
sudo ip link set eth0 down    # take an interface offline
sudo ip link set eth0 up      # bring it back online
hostname -I                   # print all IP addresses, space-separated

Единственный бинарник, ip, охватывает адреса, интерфейсы, маршрутизацию и туннели. hostname -I — самый быстрый способ получить адрес для скрипта, не разбирая вывод ip addr.

Маршрутизация

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

ip route                                      # view the routing table
ip route get 1.1.1.1                          # show which route a destination uses
sudo ip route add 10.0.0.0/24 via 192.168.1.1 # add a static route

ip route get — быстрый способ ответить на вопрос «какой интерфейс и шлюз будут использованы для этого адреса?». Это помогает, когда хост доступен из одной сети, но не из другой.

Связность и маршрут прохождения пакетов

ping проверяет, отвечает ли хост; traceroute и mtr показывают, по какому пути идут пакеты и где они теряются. Всегда ограничивайте ping числом пакетов: ping -c 5 example.com отправит пять пакетов и завершится, а не будет работать бесконечно.

ping -c 5 example.com     # send 5 ICMP echoes, then stop
traceroute example.com    # trace the hop-by-hop path
sudo traceroute -T -p 443 example.com  # trace using TCP to port 443
mtr example.com           # live ping + traceroute in one view

Без дополнительных параметров traceroute прекращает работу после 30 переходов и использует размер пробного пакета 60 байт для IPv4 и 80 байт для IPv6. Добавление -T заменяет UDP-пробы по умолчанию на TCP, которые проходят через межсетевые экраны, отбрасывающие пакеты по умолчанию. mtr example.com объединяет ping и traceroute в одном живом представлении, так что вы можете наблюдать за потерями пакетов по каждому переходу в реальном времени. Учтите, что traceroute и mtr часто не предустановлены: добавьте их командой sudo apt install mtr traceroute (Debian/Ubuntu) или sudo dnf install mtr traceroute (RHEL/Fedora).

DNS-запросы

dig — основной инструмент для DNS-запросов; +short сокращает вывод до ответа, -x выполняет обратный запрос, а @server обращается к конкретному резолверу. nslookup и host решают те же задачи более лаконично.

dig +short example.com            # just the resolved A record(s)
dig -x 8.8.8.8                    # reverse lookup: IP -> hostname
dig +short example.com @8.8.8.8   # query Google's public resolver directly
host example.com                  # terse forward/reverse lookup
nslookup example.com              # interactive-capable lookup

Явное обращение к резолверу — ключевой шаг для локализации проблемы: чтобы отличить сбой DNS от неисправного локального резолвера, выполните dig +short example.com @8.8.8.8; если запрос разрешается, а через ваш резолвер по умолчанию — нет, проблема в резолвере, а не в домене.

Как узнать, какой процесс занимает порт в Linux?

Чтобы выяснить, какой процесс держит порт, выполните ss -tulnp | grep :8080. Флаг -p выводит PID и имя процесса, владеющего сокетом. Это решение ошибки «port already in use», когда сервер или контейнер не может привязаться к порту.

ss -tlnp                    # all listening TCP sockets + owning process
ss -tulnp | grep :8080      # what's bound to port 8080 (TCP + UDP)

Флаги читаются так: t = TCP, u = UDP, l = listening (прослушивание), n = numeric (без разрешения имён), p = process. Для просмотра имён процессов у сокетов, которые вам не принадлежат, нужны права root, поэтому добавляйте sudo. ss — современная замена netstat, и собственная man-страница netstat называет команду в основном устаревшей и направляет к основанной на netlink утилите ss, когда на нагруженном сервере нужно вывести много сокетов. Именно отсюда берётся разница в скорости: ss обращается к ядру через netlink, а netstat читает текстовые файлы в /proc/net. Получив PID, остановите процесс командой kill <pid>.

Трафик и передача данных

tcpdump захватывает пакеты в реальном времени, а curl, wget и nc проверяют доступность и передают файлы. Используйте tcpdump, чтобы увидеть, что именно происходит «на проводе», когда инструменты более высокого уровня не дают ответа.

sudo tcpdump -i eth0 port 80    # capture HTTP traffic on eth0
curl -v https://example.com     # verbose HTTP request, headers and TLS
wget -O out.html https://example.com  # download to a file
nc -zv example.com 443          # check if a port is open (no data sent)

Снятие пакетов с интерфейса с помощью tcpdump требует повышенных привилегий, что на практике означает запуск через sudo (либо выдачу бинарнику права CAP_NET_RAW). nc -zv host port — самая быстрая однострочная проверка порта: -z сканирует, не отправляя данных, -v сообщает результат. В Docker Desktop имя host.docker.internal разрешается само по себе, поэтому nc -zv host.docker.internal 8080 из контейнера достигает хоста. В Docker Engine для Linux это придётся настроить вручную, запустив контейнер с параметром --add-host=host.docker.internal:host-gateway (поддерживается начиная с Docker Engine 20.10).

Схема диагностики: от симптома к команде

Сопоставьте симптом с деревом решений и двигайтесь наружу, начиная со своей машины.

• Хост недоступен → ping -c 5 host для проверки доступности, затем traceroute host или mtr host, чтобы найти, где теряются пакеты, затем ip route, чтобы убедиться в наличии корректного маршрута и шлюза.
• «Port already in use» → ss -tulnp | grep :<port>, чтобы найти PID владельца, затем kill <pid> или привязка к другому порту.
• Не работает DNS → dig +short example.com через ваш резолвер, затем dig +short example.com @8.8.8.8 через публичный; если разрешается только публичный запрос, виноват локальный резолвер.
• Медленный или перегруженный канал → sudo iftop или bmon, чтобы увидеть пропускную способность по каждому соединению в реальном времени (установите командой sudo apt install iftop bmon).

Каждая команда в этих цепочках подтверждает или исключает один уровень (канал, маршрут, разрешение имён, сокет), так что вы сужаете область поиска неисправности, а не гадаете.

Обращайтесь в первую очередь к инструментам iproute2 (ip, ss, ip neigh), прибегайте к net-tools только в системах, где они ещё поставляются, и следуйте описанным выше схемам «симптом → команда» в следующий раз, когда не удастся привязаться к порту или хост перестанет отвечать.

Частые вопросы

В чём разница между ss и netstat и являются ли они взаимозаменяемыми?

Они не взаимозаменяемы. ss — современная замена, и собственная man-страница netstat описывает команду как в основном устаревшую и указывает на ss. ss запрашивает данные о сокетах у ядра через netlink, а netstat читает текстовые файлы в /proc/net, поэтому ss лучше держит нагрузку на серверах с большим количеством сокетов. Обе команды выводят соединения и прослушиваемые порты, но в скриптах следует вызывать ss, поскольку netstat может быть не установлен.

Как найти и завершить процесс, использующий определённый порт в Linux?

Выполните ss -tulnp | grep :8080, чтобы найти сокет, привязанный к этому порту; флаг -p выводит PID и имя процесса-владельца. Для просмотра имён процессов у сокетов, которые вам не принадлежат, нужны права root, поэтому добавляйте sudo. Получив PID, остановите процесс командой kill с указанием PID. Это устраняет ошибку 'port already in use', когда сервер или контейнер не может привязаться к порту.

Почему ifconfig на моём сервере выдаёт command not found?

Потому что ifconfig входит в пакет net-tools, который многие современные дистрибутивы больше не устанавливают по умолчанию. Red Hat относит ifconfig и route к командам, заменяемым iproute2, RHEL не включает net-tools в установку по умолчанию начиная с версии 7, а Debian — начиная с Debian 9. Используйте вместо этого ip addr для просмотра интерфейсов и адресов либо установите net-tools вручную, если устаревший скрипт требует старого бинарника.

Как определить, связана ли проблема с DNS с самим доменом или с моим локальным резолвером?

Обратитесь к публичному резолверу напрямую командой dig +short example.com @8.8.8.8 и сравните результат с dig +short example.com через резолвер по умолчанию. Если публичный запрос разрешается, а запрос через резолвер по умолчанию — нет, виноват локальный резолвер, а не домен. Синтаксис @server заставляет dig обойти настроенный резолвер, локализуя сбой на одной стороне без изменения системной конфигурации.

Почему traceroute или mtr не установлены в моей системе?

traceroute, mtr, whois, nmap и iftop часто не входят в минимальные или установки по умолчанию, поэтому они возвращают command not found. Установите их командой sudo apt install mtr traceroute в Debian и Ubuntu либо sudo dnf install mtr traceroute в RHEL и Fedora. В отличие от ip и ss, которые по умолчанию поставляются вместе с iproute2, эти инструменты трассировки и сканирования обычно приходится добавлять через пакетный менеджер.