PrepBro
← Назад к вопросам

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

1.7 Middle🔥 202 комментариев
#Сети и протоколы

Комментарии (2)

🐱
deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Отличный вопрос. Это фундаментальный навык для DevOps/SRE, позволяющий диагностировать проблемы с подключением, безопасностью и производительностью. В Linux есть целый арсенал инструментов для мониторинга сетевой активности процессов. Вот подробный разбор методов, от базовых к продвинутым.

Основные инструменты командной строки

1. lsof (List Open Files)

В Linux всё есть файл, включая сетевые сокеты. lsof — главный инструмент для просмотра открытых файлов (и сокетов) процессом.

  • Просмотр всех сетевых соединений: 
    lsof -i
  • Фильтрация по протоколу и порту: 
    lsof -i TCP:80      # Все, кто использует TCP порт 80
lsof -i :443        # Все, кто использует порт 443 (любой протокол)
lsof -i @8.8.8.8    # Все соединения с адресом 8.8.8.8
  • Смотрим, какой процесс использует конкретный порт: 
    lsof -i :8080
  • Показываем сетевую активность конкретного процесса (по PID или имени): 
    lsof -p 1234 -i
lsof -c nginx -i

    Вывод включает **PID, пользователя, тип сокета (IPv4/IPv6), состояние соединения (LISTEN, ESTABLISHED) и адреса**.

2. ss (Socket Statistics) / устаревший netstat

ss — современная замена netstat, быстрее и информативнее. Показывает состояние сокетов ядра.

  • Все TCP-соединения с именами процессов: 
    ss -tulp

    Ключи: `-t` (TCP), `-u` (UDP), `-l` (только listening), `-p` (процессы), `-n` (не резолвить имена).
  • Поиск процесса, слушающего порт: 
    ss -ltnp 'sport = :80'
  • Показать все установленные соединения конкретного процесса: 
    ss -tnp src *:443 | grep pid=1234

3. netstat (устарел, но еще широко используется)

Аналоги ss, но медленнее. Полезен, если ss недоступна.

netstat -tulnp

Мониторинг в реальном времени и трассировка

4. strace — трассировка системных вызовов

Мощнейший инструмент для низкоуровневой отладки. Показывает все системные вызовы, которые делает процесс, включая сетевые (socket, connect, sendto, recvfrom).

  • Запустить процесс под strace: 
    strace -e trace=network curl https://google.com
  • Подключиться к уже запущенному процессу: 
    strace -p 1234 -e trace=network -s 10000

    Ключ `-e trace=network` фильтрует только сетевые вызовы. Это позволяет увидеть, *какие именно* адреса и порты пытается использовать программа, даже если соединение не устанавливается.

5. tcpdump и Wireshark — сниффинг пакетов

Позволяют увидеть сырой сетевой трафик. tcpdump — консольный, Wireshark — с GUI.

  • Перехват трафика интерфейса eth0 для порта 80: 
    tcpdump -i eth0 port 80 -nn
  • Перехват трафика конкретного процесса (с использованием nsof для определения его сокетов): 
    # Находим inode сокета процесса
lsof -p 1234 -a -i -F n | grep ^n | cut -c2-
# Перехватываем по inode (требуются права root)
tcpdump -i any -nn "tcp and ( $(lsof -p 1234 -a -i -F n | grep ^n | cut -c2- | sed 's/.*/inode &/g' | paste -sd ' or ') )"

    Это золотой стандарт для анализа *что именно* передается по сети.

6. /proc Filesystem — программный доступ

Информация о каждом процессе лежит в /proc/[PID]/. Это основа, из которой берут данные lsof, ss и ps.

  • Просмотр открытых файловых дескрипторов (включая сокеты) процесса: 
    ls -la /proc/1234/fd/

    Сокеты будут ссылками вида `socket:[inode_number]`.
  • Статистика сети по процессу: 
    cat /proc/1234/net/tcp
cat /proc/1234/net/udp

    Вывод в сыром виде, требует парсинга.

Практический рабочий процесс для DevOps

  1. Обнаружение аномалии: Заметили высокий сетевой трафик (nload, iftop) или ошибки подключения в логах.
  2. Идентификация процесса: Используем ss -tulp или lsof -i :PORT, чтобы найти PID и имя процесса, ответственного за соединение на интересующем порту.
  3. Анализ связей: Смотрим, с кем общается процесс (lsof -p PID -i или ss -tnp dst :443). Определяем, ожидаемое ли это поведение (например, связь с БД, API-шлюзом).
  4. Глубинная диагностика (если проблема неочевидна):
    *   **Не устанавливается соединение?** Используем `strace -p PID -e trace=network` или `strace -e trace=network <команда>`, чтобы увидеть, на каком системном вызове (например, `connect`) происходит ошибка и какие параметры передаются.
    *   **Подозрительный или шифрованный трафик?** Запускаем `tcpdump` на интерфейсе или в namespace контейнера, чтобы увидеть метаданные (адреса, объем трафика, шаблоны).
    *   **Программный мониторинг:** Пишем скрипты, которые парсят `/proc/[PID]/net/tcp` или используют вывод `ss` для сбора метрик в Prometheus (например, с помощью `node_exporter` или кастомных текстовых файлов).

Особенности в контейнеризированном мире (Docker/K8s)

  • Внутри контейнера: Используйте те же инструменты (lsof, ss, netstat), установив их в образ или зайдя через docker exec.
  • С хоста: Процессы контейнера видны на хосте. Найдите PID основного процесса контейнера (docker inspect --format '{{.State.Pid}}' <container_id>) и исследуйте его, как обычный процесс.
  • Network Namespaces: Каждый контейнер/под имеет свой сетевой namespace. Для отладки с хоста нужно войти в его namespace: 
    nsenter -t <CONTAINER_PID> -n ss -tulp

    Или использовать `docker run --network container:<name>` для запуска инструментов в том же namespace.

Вывод: Для быстрой проверки "кто слушает порт" используйте ss -tulp. Для детального анализа всех соединений процесса — lsof -p PID -i. Для отладки проблем с установкой соединения — strace. Для анализа содержимого трафика — tcpdump. Понимание этих инструментов и их совместное применение — ключевой навык для эффективного решения сетевых проблем в распределенных системах.