Linux список открытых соединений

Первое знакомство с командой ss

В Linux есть программы, которые пригодятся программистам, специалистам по информационной безопасности, администраторам… короче говоря, каждый найдёт здесь то, что ему нужно.

Инструмент командной строки netstat был одним из тех средств, которыми часто пользовались системные администраторы. Однако команда netstat была признана устаревшей и на смену ей пришла более быстрая и удобная в использовании команда ss .

Сегодня мы поговорим о том, как применять ss для того, чтобы узнавать о том, что происходит с сетью на компьютере, работающем под управлением Linux.

О команде ss

Команда ss — это инструмент, используемый для вывода сетевой статистики в виде, похожем на тот, который выдаёт команда netstat . Однако, ss делает это проще и быстрее, чем netstat . Кроме того, ss даёт более подробные сведения о TCP-подключениях и о состояниях соединений, чем большинство других инструментов. В частности, ss может выводить данные о таких сущностях, как PACKET, TCP, UDP, DCCP, RAW, и сокеты домена Unix. Команда ss проще, чем netstat . для того, чтобы в этом убедиться, достаточно сравнить страницы man этих двух инструментов. С помощью ss можно получить весьма подробные сведения о том, как машина, работающая под управлением Linux, обменивается данными с другими компьютерами. Всё это открывает возможности по диагностике и устранению различных сетевых ошибок.

Основы ss

Команда ss работает так же, как и любые другие утилиты командной строки Linux. А именно, в командной строке вводят имя соответствующего исполняемого файла, за которым следует необходимая комбинация опций. Если взглянуть на страницу справки по ss (вызвать её можно командой man ss ), можно заметить, что тут присутствует гораздо меньше ключей командной строки, чем у netstat . Однако это не говорит о скудных возможностях ss . На самом деле, перед нами — весьма мощный инструмент.

Если запустить ss без аргументов командной строки или опций, она выведет полный список работающих соединений.

Полный список установленных соединений

Так как команда ss (без опций) показывает очень много данных (подробности по всем соединениям, установленным по TCP, UDP и с помощью сокетов Unix), можно отправить вывод этой команды в файл для того, чтобы проанализировать его позже. Делается это, например, так:

Конечно, в любых ситуациях команда в простейшем виде не так уж и полезна. Что если нужно лишь вывести список сокетов, ожидающих соединений? Сделать это просто — достаточно воспользоваться опцией -l :

Такая команда выведет список, в котором присутствуют лишь сокеты, находящиеся в режиме прослушивания сети.

Для того чтобы ещё немного сузить диапазон выводимых этой командой данных, учитывайте то, что опция -t позволяет просматривать сведения по TCP-соединениям, опция -u предназначена для вывода данных по UDP-соединениям, опция -x выводит данные по соединениям Unix. Выглядит всё это следующим образом: ss -t , ss -u , или ss -x . Любая из этих команд выведет большой объём данных, которые можно проанализировать.

Команда ss, выполненная в Elementary OS выдаёт список UDP-соединений

По умолчанию использование опций -t , -u или -x выведет лишь данные по установленным соединениям. Если нужно отобрать соединения, ожидающие подключений, понадобится добавить к вызову команды опцию -a :

В вывод этой команды попадут TCP-сокеты:

Обратите внимание на то, что последний сокет ожидает ssh-подключений

В вышеприведённом примере можно заметить, что соединения (в различных состояниях) установлены с IP-адреса анализируемого компьютера, при этом выводятся сведения по портам на этом компьютере, а также по адресам и портам на удаленных системах. В отличие от команды netstat , ss не выводит сведения о PID и имени команды, ответственной за конкретное соединение. Однако, даже учитывая это, в нашем распоряжении оказывается немало данных для поиска сетевых ошибок. Если нечто оказывается под подозрением, ss позволит узнать подробности о соединении, а значит, дать в распоряжение администратора сведения, которые пригодятся на ранних стадиях решения сетевых проблем.

Фильтрация вывода ss на основе состояний TCP

Весьма удобная возможность команды ss заключается в том, что она может фильтровать вывод, используя состояния TCP (или состояния жизненного цикла соединения). Благодаря использованию состояний облегчается фильтрация вывода ss . А именно, здесь доступны все стандартные состояния TCP:

• established
• syn-sent
• syn-recv
• fin-wait-1
• fin-wait-2
• time-wait
• closed
• close-wait
• last-ack
• listening
• closing

Кроме того, ss распознаёт следующие идентификаторы состояний:

• all (все вышеперечисленные состояния)
• connected (все состояния, кроме ожидающих соединения и закрытых)
• synchronized (все состояния, соответствующие установленным соединениям, за исключением syn-sent )
• bucket (состояния, представляющие собой минисокеты, например — time-wait и syn-recv )
• big (всё кроме того, что соответствует идентификатору bucket )

Работать с состояниями довольно просто. Например, для IPv4 это выглядит так:

В этих двух примерах FILTER представляет собой идентификатор состояния.
Предположим, нужно просмотреть все ожидающие соединения IPv4-сокеты. Сделать это поможет такая команда:

В ответ на эту команду система выведет нечто подобное тому, что показано на следующем рисунке.

Использование ss с фильтром состояния ожидания соединения

Показ подключений с конкретных адресов

Одно из полезных применений ss заключается в том, чтобы получать с помощью этой команды сведения по соединениям, установленных с неких IP-адресов. Предположим, нужно выяснить, подключена ли машина, скажем, с IP-адресом 192.168.1.139 к нашему серверу, и если это так — узнать об этом подробности. Для решения этой задачи подойдёт такая команда:

В ответ на эту команду будут выведены сведения, включающие в себя Netid, состояние подключения, данные по локальному IP-адресу и порту, а также по удалённому IP и порту соединения.

Удалённый компьютер установил ssh-подключение к нашей машине

Итоги

Утилита ss может очень пригодиться в делах поиска и устранения сетевых неполадок Linux-серверов. Конечно, для того, чтобы в полной мере освоить ss , неплохо будет почитать man и попрактиковаться. Однако, теперь у вас есть представление о том, как применять эту команду, которую просто необходимо знать современному администратору Linux.

Уважаемые читатели! Пользуетесь ли вы ss?

Источник

Мониторинг сетевого стека linux

Часто мониторинг сетевой подсистемы операционной системы заканчивается на счетчиках пакетов, октетов и ошибок сетевых интерфейсах. Но это только 2й уровень модели OSI!
С одной стороны большинство проблем с сетью возникают как раз на физическом и канальном уровнях, но с другой стороны приложения, работающие с сетью оперируют на уровне TCP сессий и не видят, что происходит на более низких уровнях.

Я расскажу, как достаточно простые метрики TCP/IP стека могут помочь разобраться с различными проблемами в распределенных системах.

Netlink

Почти все знают утилиту netstat в linux, она может показать все текущие TCP соединения и дополнительную информацию по ним. Но при большом количестве соединений netstat может работать достаточно долго и существенно нагрузить систему.

Есть более дешевый способ получить информацию о соединениях — утилита ss из проекта iproute2.

Ускорение достигается за счет использования протола netlink для запросов информации о соединениях у ядра. Наш агент использует netlink напрямую.

Считаем соединения

Disclaimer: для иллюстрации работы с метриками в разных срезах я буду показывать наш интерфейс (dsl) работы с метриками, но это можно сделать и на opensource хранилищах.

В первую очередь мы разделяем все соединения на входящие (inbound) и исходящие (outbound) по отношению к серверу.

Каждое TCP соединения в определенный момент времени находится в одном из состояний, разбивку по которым мы тоже сохраняем (это иногда может оказаться полезным):

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

Здесь так же видно резкое падение общего количества соединений незадолго до 11 Jun, попробуем посмотреть на соединения в разрезе listen портов:

На этом графике видно, что самое значительное падение было на порту 8014, посмотрим только 8014 (у нас в интерфейсе можно просто нажать на нужном элементе легенды):

Попробуем посмотреть, изменилось ли количество входящий соединений по всем серверам?

Выбираем серверы по маске “srv10*”:

Теперь мы видим, что количество соединений на порт 8014 не изменилось, попробуем найти на какой сервер они мигрировали:

Мы ограничили выборку только портом 8014 и сделали группировку не по порту, а по серверам.

Теперь понятно, что соединения с сервера srv101 перешли на srv102.

Разбивка по IP

Часто бывает необходимо посмотреть, сколько было соединений с различных IP адресов. Наш агент снимает количество TCP соединений не только с разбивкой по listen портам и состояниям, но и по удаленному IP, если данный IP находится в том же сегменте сети (для всех остальный адресов метрики суммируются и вместо IP мы показываем “

Рассмотрим тот же период времени, что и в предыдущих случаях:

Здесь видно, что соединений с 192.168.100.1 стало сильно меньше и в это же время появились соединения с 192.168.100.2.

Детализация рулит

На самом деле мы работали с одной метрикой, просто она была сильно детализирована, индентификатор каждого экземпляра выглядит примерно так:

Например, у одно из клиентов на нагруженном сервере-фронтенде снимается

700 экземпляров этой метрики

TCP backlog

По метрикам TCP соединений можно не только диагностировать работу сети, но и определять проблемы в работе сервисов.

Например, если какой-то сервис, обслуживающий клиентов по сети, не справляется с нагрузкой и перестает обрабатывать новые соединения, они ставятся в очередь (backlog).

На самом деле очереди две:

• SYN queue — очередь неустановленных соединений (получен пакет SYN, SYN-ACK еще не отправлен), размер ограничен согласно sysctl net.ipv4.tcp_max_syn_backlog;
• Accept queue — очередь соединений, для которых получен пакет ACK (в рамках «тройного рукопожатия»), но не был выполнен accept приложением (очередь ограничивается приложением)

При достижении лимита accept queue ACK пакет удаленного хоста просто отбрасывается или отправляется RST (в зависимости от значения переменной sysctl net.ipv4.tcp_abort_on_overflow).

Наш агент снимает текущее и максимальное значение accept queue для всех listen сокетов на сервере.

Для этих метрик есть график и преднастроенный триггер, который уведомит, если backlog любого сервиса использован более чем на 90%:

Счетчики и ошибки протоколов

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

В данный момент однозначного ответа на этот вопрос окметр дать по-прежнему не может, так как сниффинг мы только начали осваивать, но мы немного продвинулись в этом вопросе.

Попробуем что-то понять про эти выбросы входящего трафика:

Теперь мы видим, что это входящий UDP трафик, но здесь не видно первых из трех выбросов.
Дело в том, что счетчики пакетов по протоколам в linux увеличиваются только в случае успешной обработки пакета.

Попробуем посмотреть на ошибки:

А вот и наш первый пик — ошибки UDP:NoPorts (количество датаграмм, пришедших на UPD порты, которые никто не слушает)

Данный пример мы эмулировали с помощью iperf, и в первый заход не включили на сервер-приемщик пакетов на нужном порту.

TCP ретрансмиты

Отдельно мы показываем количество TCP ретрансмитов (повторных отправок TCP сегментов).

Само по себе наличие ретрансмитов не означает, что в вашей сети есть потери пакетов.
Повторная передача сегмента осуществляется, если передающий узел не получил от принимающего подтверждение (ACK) в течении определенного времени (RTO).

Данный таймаут расчитывается динамически на основе замеров времени передачи данных между конкретными хостами (RTT) для того, чтобы обеспечивать гарантированную передачу данных при сохранении минимальных задержек.

На практике количество ретрансмитов обычно коррелирует с нагрузкой на серверы и важно смотреть не на абсолютное значение, а на различные аномалии:

На данном графике мы видим 2 выброса ретрансмитов, в это же время процессы postgres утилизировали CPU данного сервера:

Cчетчики протоколов мы получаем из /proc/net/snmp.

Conntrack

Еще одна распространенная проблема — переполнение таблицы ip_conntrack в linux (используется iptables), в этом случае linux начинает просто отбрасывать пакеты.

Это видно по сообщению в dmesg:

Агент автоматически снимает текущий размер данной таблицы и лимит с серверов, использующих ip_conntrack.

В окметре так же есть автоматический триггер, который уведомит, если таблица ip_conntrack заполнена более чем на 90%:

На данном графике видно, что таблица переполнялась, лимит подняли и больше он не достигался.

Вместо заключения

Примеры наших стандартных графиков можно посмотреть в нашем демо-проекте.
Там же можно постмотреть графики Netstat.

Источник