Если вы хотите узнать, привязан ли процесс к порту, есть несколько инструментов, которые вы можете использовать, но если их нет, вы можете использовать cat /proc/net/tcp.
🖧 Использование различных пользовательских агентов с wget
Можно оказаться в ситуации, когда ss, nc, netstat, telnet и curl были недоступны, и нет возможности их установить.
Все эти инструменты позволяют вам увидеть, привязан ли адрес к определенному порту.
🖧 Использование Curl для создания Telnet-соединения
Возможно, вы что-то устраняете и хотите убедиться, что интересующий вас процесс действительно запущен на определенном порту и привязан к определенному адресу, например, 0.0.0.0 или 127.0.0.1, в зависимости от того, что вы делаете.
Если вы работаете в контейнеризованном мире с помощью Docker или Kubernetes, вы можете оказаться в суперблокированном контейнере, работающем от имени пользователя без прав root, без разрешений на повышение уровня пользователя и с очень небольшим количеством установленных утилит.
В случае с Kubernetes вы всегда можете создать отладочный контейнер для анализа состояния другого контейнера с помощью пользовательских инструментов, но, возможно, вы не используете Kubernetes или, возможно, среда, в которой вы находитесь, не позволяет вам запускать новые контейнеры.
Вот где может быть полезно научиться читать cat /proc/net/tcp или cat /proc/net/tcp6.
🖧 В чем разница между curl и Wget?
Вот где может быть полезно научиться читать cat /proc/net/tcp или cat /proc/net/tcp 6.
Что такое /proc/net/tcp[6]?
- В системах Linux процесс записывает свой адрес:информацию о порте в свой файл протокола
Если вы работаете на macOS, файл /proc/net будет недоступен, но если вы используете контейнер Linux, вы можете подключиться к нему и найти подробную информацию о портах этого контейнера - В /proc/net есть файлы, связанные с протоколами tcp, udp и многими другими сетевыми файлами
Вы часто будете видеть tcp и tcp6 в зависимости от того, привязан ли сокет к IPv4 или IPv6
Контейнеризированные процессы с Docker
Если вы используете Docker и у вас запущен контейнер с чем-то вроде -p 8080:80, и вы хотите проверить порт на своем хосте, тогда вам нужно использовать cat/proc/net/tcp6, потому что, насколько я знаю, Docker будет привязывать порт обратно к вашему хосту по IPv6 сокет с подстановочным знаком (::) и этот сокет способен обрабатывать трафик как IPv4, так и IPv6 для всех адресов.
Если вместо этого вы использовали -p 127.0.0.1:8080:80, то Docker будет использовать сокет IPv4, и вы найдете его в cat /proc/net/tcp.
Это важная деталь, если вам интересно, почему она может отличаться в зависимости от того, над какими проектами вы работаете.
Анализ выходных данных /proc/net/tcp[6]
Способ анализа обоих файлов (tcp6 и tcp) один и тот же.
Там есть несколько столбцов, но мы сосредоточимся только на local_address.
Я удалил другие столбцы, чтобы было удобнее читать.
Вот состояние системы в моем окне разработки.
Чуть позже мы рассмотрим пример команды Docker, чтобы вы могли следить за ней:
tcp6 и tcp
0 (первая) запись запущена Hugo и опубликована в 0.0.0.0:1313 с помощью Docker
0 (первая) запись – это запущенный NGiNX, опубликованный в версии 127.0.0.1:8080 через Docker
16-разрядный шестнадцатеричный порт
Локальный адрес заканчивается на :XXXX, что означает порт в 16-разрядном шестнадцатеричном формате.
В командной строке вы можете использовать printf для преобразования этого значения в десятичное, а также многие другие инструменты.
В большинстве инструментов убедитесь, что ваш шестнадцатеричный номер начинается с 0x:
16–разрядный шестнадцатеричный адрес
Значения адресов IPv6 и IPv4 для :: и 0.0.0.0 являются:
0000000000000000000000000000000000000000
Для этого вам, вероятно, не потребуется переводить их в десятичную форму, но есть немало деталей, о которых следует помнить, когда вам все-таки потребуется выполнить преобразование.
Например, 0100007F – это IPv4–адрес для 127.0.0.0.
Вот рабочий процесс для преобразования этого значения в IP–адрес:
Разбейте его на байты, которые представляют собой фрагменты по 2 символа, например, 01 00 00 7F
Измените его на 7F 00 00 01
Он представлен в строчном формате (сохраняет младший байт по наименьшему адресу)
Преобразуйте каждый байт в десятичный:
- 7F равно 127
- 00 равно 0
- 00 равно 0
- 01 равно 1
Бум, мы только что добрались до версии 127.0.0.1.
Забавно, но, посмотрев это достаточно внимательно, вы сможете выбрать 0100007F как 127.0.0.1, не проходя через этот процесс каждый раз.
Преобразование десятичной системы счисления в 16-разрядную шестнадцатеричную
Если у вас есть куча записей в /proc/net/tcp и вы хотите найти определенный порт, вы всегда можете запустить grep “:XXXX” /proc/net/tcp и заменить XXXX на нужное вам шестнадцатеричное значение.
Вот где помогает знание того, как выполнить преобразование, потому что вы можете захотеть преобразовать 5432 (десятичное число) в значение, которое вы будете искать в шестнадцатеричном формате:
Вы можете убедиться в этом с помощью портов, которые мы использовали выше (13/8080).:
Теперь у вас достаточно информации, чтобы проанализировать этот вывод и выполнить поиск по определенным портам, чтобы убедиться, что ваш процесс прослушивается и выполняется правильно.
С учетом сказанного, если у вас есть такие инструменты, как ss или netstat, получить эту информацию гораздо проще, поскольку она преобразует и выравнивает все для вас:
Отслеживание с помощью Docker
Это еще больше упростит приведенные выше примеры, показав разные значения в зависимости от того, говорим ли мы о компьютере хоста или внутри контейнера, и если вы используете macOS, это также позволит вам следить за процессом.
Чтобы получить выходные данные NGiNX, которые я использовал ранее, я запустил эту команду:
Теперь вы можете запустить это во втором терминале:
Теперь мы запускаем cat /proc/net/tcp внутри контейнера, поэтому информация о хосте и порту связана с этим.
Образ NGiNX, который мы используем, привязывается к 0.0.0.0 и работает на порту 80.
В качестве отдельного шага мы опубликовали это в версии 127.0.0.1:8080 на хосте.
Технически вы также можете запустить docker container exec proc net cat /proc/net/tcp6 и просмотреть информацию об IPv6, потому что внутри контейнера NGiNX привязывается как к IPv4, так и к IPv6.
см. также:
