ITSM Дао 😎

Сегодня в рублике #посредственнаятулза поговорим о утилите ss, которая выводит на консоль сетевые сокеты во всех их состояниях. 🥺 Да, это наследник хорошо известных lsofи netstatи с виду все тоже самое, но есть нюансы 😈. netstat- старая утилита из пакета net-tools который не обновлялся со времен царя гороха 😣. Все очень похоже, вплоть до ключей, но netstat ходит по /proc/net/tcp и /proc/net/tcp6 и парсит, парсит, парсит. А ss ходит за данными прямо через netlink-интерфейс в ядро. Так что если сокетов мульен, то ss работает гораздо быстрее. С lsofсложнее, так как взгляд на проблему тут со стороны всех файловых дескрипторов. То есть сначала строим список всех дескрипторов, потом уже среди них можно найти сокеты. Кстати, сразу после того, как утилита отработает виден контекст безопасности. Но это все сказочка, а вот быль. Пришли ко мне коллеги. У них пропал доступ к web-консоли их любимого локального сервиса. Рестарт не помог, спасите-помогите. Пробую подключиться – коннекшен таймаут. Сервис жив, сетевая связанность с другими службами на хосте есть. Фаервол не блокирует. Ага, думаю, надо посмотреть жив ли сокет. Набираю ss -ltn | grep 8888 и вижу:

[u1@gate2 ~]# ss -ltn
LISTEN 0 128    [::]:8888    [::]:*

Сокет есть, но только по ipv6, а по ipv4 нет. Логично предположить, что или службу научили 🥷 плохому слушать только ipv6, или стоит параметр net.ipv6.bindv6only = 1 или служба падает по ошибке. Сижу проверяю. Конфиг стандартный, sysctl net.ipv6.bindv6only показывает 0, journalctl -u servicename --since "10 min ago" после перезапуска ничего не показывает (обожаю в journalctl эти фишечки с "10 min ago»). Если бы курил, закурил бы. 🤙 Интуиция шепчет, проверь подключение. Подключаюсь через vpn открываю вебморду по ipv4 – работает. Я на секунду зависаю и меня осеняет. Пишу ss -ltne | grep 8888 и вижу: LISTEN 0 128    [::]:8888    [::]:* ino:14724 sk:ffff96ed319f8840 v6only:0 <-> Для сравнения другой Ipv6 сокет: LISTEN 0 128 [::]:50022 [::]:* ino:22872 sk:ffff96ed33328840 v6only:1 <-> Прикольно, да? Одна маленькая циферка и такое разное поведение! Это, друзья мои, нормальное поведение Linux при dual-stack. По-модному делать отдельный сокет для ipv4 сейчас не надо. Когда приходит "чистый" IPv4-пакет на dual-stack хост, сетевой стек ядра автоматически превращает адрес отправителя в IPv4-mapped адрес и передаёт его наверх, в единственный IPv6-сокет приложения — приложению даже не нужно знать, что это был IPv4-пакет, оно просто видит входящее соединение. Вот как выглядит открытый сокет: ESTAB 0 0   [::ffff:10.11.0.77]:8888    [::ffff:10.13.0.3]:55640 uid:997 ino:2621265 sk:ffff96ed21636300 <-> Как строится маппед адрес по RFC 3493 хорошо видно. Так почему эти дуалстеки часто отключают и делают разные сокеты по ipv4 и ipv6? Да, админы 👁 консерваторы осторожные. С этим механизмом и с SSRF (Server-Side Request Forgery) есть целый куст уязвимостей. Легкое гугление показало сразу CVE-2026-42449 и CVE-2026-70367. Но жизнь не стоит на месте. Надо переходить на новое, потому, что заставят. Пытливый читатель спросит, а почему сначала сервис был не доступен? 😮Оказалось, что все банально. На уровне сервиса сделали белый список адресов 👮 и забыли. К счастью, локальные адреса в нем были. #посредственнаятулза #ipv6