Что такое сетевой порт: TCP, UDP и проверка доступа к сервису

Что такое сетевой порт простыми словами

Логический сетевой порт — числовое поле транспортного протокола, с помощью которого операционная система направляет сетевой обмен нужному приложению или сокету. IP-адрес указывает узел и сетевой контекст, а сочетание транспорта, адресов и портов позволяет различать сервисы и соединения.

Физический порт — разъём Ethernet на компьютере или коммутаторе. Логический TCP 443 не является отдельным гнездом: через один кабель одновременно проходят запросы к сайту, почте и другим сервисам. Поэтому «подключить кабель» и «разрешить доступ к порту» — разные действия.

• Пользователю: понять, почему сайт открывается, а подключение к приложению не работает.
• Администратору: найти процесс, проверить адрес прослушивания и не открывать лишний доступ.
• Бизнесу: отличить неисправность сервиса от проблемы сети и точнее поставить задачу подрядчику.

Адрес сервиса: IP, транспорт и номер

Фраза «открыть 443» неполна. Нужно определить сервер, транспорт, допустимых клиентов, направление и точку фильтрации. Например: разрешить из рабочей подсети TCP к 10.20.0.10 на порт 443. Это не то же самое, что разрешить UDP 443 или доступ к этому номеру на всех серверах.

Номер порта имеет 16 бит: от 0 до 65535. Нулевой номер зарезервирован в реестре; bind с портом 0 часто означает просьбу ОС выбрать свободный номер, а не публичный сервис «на нулевом порту». Диапазоны IANA: системные 0–1023, пользовательские 1024–49151 и динамические/частные 49152–65535. Фактический диапазон временных портов ОС проверяют отдельно.

Регистрация номера не доказывает, что трафик соответствует ожидаемому приложению или безопасен. Сервис можно настроить на другой порт; правила и мониторинг должны опираться на фактическую конфигурацию.

TCP и UDP: что именно проверяется

TCP создаёт соединение и предоставляет упорядоченный надёжный поток байтов. Это удобно для множества приложений, но успешное соединение ещё не означает правильный ответ сервиса. Дальше могут потребоваться TLS, авторизация, обращение к базе и выполнение операции.

UDP передаёт датаграммы без TCP-подобного установления соединения и сам не гарантирует доставку, порядок или отсутствие повторов. Нужные механизмы может реализовать приложение поверх UDP: поэтому «UDP всегда ненадёжный и простой, TCP всегда лучше» — неверный выбор по одному признаку.

• У TCP можно проверить установление соединения, затем отдельно протокол приложения.
• Для UDP полезен корректный запрос выбранного протокола и ожидаемый ответ.
• Отсутствие ответа UDP может означать фильтр, потерю, неподходящий запрос или молчание сервиса.
• ICMP-ошибка, тайм-аут и валидный ответ — разные наблюдения, их не смешивают.

Проверка TCP 53 не подтверждает UDP DNS. Разрешение UDP 443 не заменяет TCP 443 для клиентов, использующих другой вариант HTTPS. Транспорт является частью условий доступа.

Серверный и временный клиентский порт

TCP-соединение различают по паре адресов и паре портов; при описании потока добавляют транспорт — получается распространённое представление в виде пяти полей. Несколько клиентов могут одновременно обращаться к одному серверному TCP 443: их соединения имеют разные исходные параметры.

Для ответов не требуется автоматически публиковать весь диапазон временных портов клиента в Интернет. Stateful firewall обычно сопоставляет ответ с разрешённым состоянием, но конкретные правила и режимы устройства нужно проверить. Если появился NAT, внешний исходный адрес и порт могут дополнительно измениться.

Состояния TCP вроде LISTEN, ESTABLISHED и TIME_WAIT описывают разные ситуации. TIME_WAIT после закрытия соединения сам по себе не доказывает утечку или неисправность. Считайте динамику, ресурсы и связь с реальной жалобой.

Прослушивание: localhost, все адреса и IPv6

Если сервис слушает только 127.0.0.1:8080, соседний компьютер обычно не подключится к нему по LAN-адресу сервера. Это нормальная схема для приложения за локальным reverse proxy. Привязка к 0.0.0.0 означает все локальные IPv4-адреса в соответствующем сетевом пространстве имён, но не разрешает автоматически доступ через firewall.

Адрес [::] относится к IPv6. Принимает ли такой сокет также IPv4, зависит от ОС и настройки IPv6-only. Не делайте вывод «всё доступно по обоим протоколам» по одной строке LISTEN.

Нужны корректный bind, работающий процесс, маршрут туда и обратно и разрешения на каждом участке. Переход с localhost на wildcard расширяет поверхность доступа: сначала определите, действительно ли сервис должен быть доступен напрямую.

Знакомые номера и типовые заблуждения

• HTTPS: обычно TCP 443; HTTP/3 использует QUIC поверх UDP, часто на том же номере 443.
• DNS: классический DNS использует и UDP 53, и TCP 53. «DNS работает только по UDP» — ошибка.
• SSH: обычно TCP 22. Смена номера уменьшает часть фоновых обращений, но не заменяет ключи, ограничения и обновления.
• HTTP: обычно TCP 80; за reverse proxy backend может слушать другой локальный порт.
• Корпоративные приложения: могут иметь несколько служб, динамические диапазоны и дополнительные зависимости. Список берут из документации конкретной версии.

Не открывайте произвольный набор «стандартных портов для 1С» или СУБД без топологии и нужного сценария. Доступ клиента к веб-публикации, серверу приложений, кластеру и базе данных — разные соединения. Для каждого указывают инициатора, цель и назначение.

Фактический listener и настройка приложения важнее памятки с типовыми номерами. Особенно это относится к нестандартным публикациям и контейнерам.

Где может оборваться путь к сервису

Начните с точного описания: «с ноутбука сотрудника через VPN не открывается https://portal.example:443». Сравните, что меняется при другой сети, другом клиенте и обращении с сервера. Не подменяйте FQDN случайным IP: у HTTPS важны имя, SNI, сертификат и выбор виртуального сайта.

Результат проверки сохраняют вместе со временем, источником, целью, IP-версией и методом. Один успешный тест из дата-центра не доказывает доступ из филиала. Балансировщик может отвечать на TCP, хотя за ним уже недоступны приложения.

Самый короткий путь диагностики — проверить фактический listener, затем доступ к нему из нужного источника, затем протокол и рабочую операцию. При изменениях фиксируйте до/после и оставляйте способ возврата.

Windows: найти listener и процесс

Get-NetTCPConnection -State Listen -LocalPort 443 |
    Select-Object LocalAddress, LocalPort, State, OwningProcess
Get-NetUDPEndpoint -LocalPort 53 |
    Select-Object LocalAddress, LocalPort, OwningProcess

Выполняйте в PowerShell на сервере. Первая команда читает TCP-listener 443 и PID владельца. Вторая показывает привязки UDP 53: у UDP нет состояния LISTEN в смысле TCP. Если совпадений нет, это может быть ожидаемый результат для узла без такого сервиса; затем проверьте правильный номер и транспорт.

$servicePid = 1234
Get-Process -Id $servicePid | Select-Object Id, ProcessName, Path

Замените 1234 на фактический OwningProcess из предыдущего вывода. Команда определяет процесс, а не завершает его. Путь и часть данных могут требовать повышения прав. Не используйте переменную $PID для своего значения — это служебная переменная PowerShell.

При HTTP.sys владельцем сокета может оказаться системный процесс: это не повод останавливать System. Тогда выясняют HTTP.sys/IIS-привязки и фактическое приложение штатными средствами платформы. Отсутствие понятного имени процесса не означает, что порт «ничей».

Linux: ss и фильтр по локальному порту

sudo ss -ltnp 'sport = :443'
sudo ss -lunp 'sport = :53'
ss -tn state established

Ключ -l выбирает слушающие сокеты, -t — TCP, -u — UDP, -n сохраняет числовые адреса и порты, -p добавляет процесс. Фильтр sport = :443 ограничивает локальную сторону выбранным портом. Последняя команда читает установленные TCP-соединения без просмотра только listener.

В выводе сверяют Local Address:Port, PID и ожидаемый процесс. Права, контейнерное пространство имён и сетевой контекст влияют на видимость. Отсутствие записи на хосте не всегда означает отсутствие сервисного сокета внутри контейнера; одновременно опубликованный контейнерный порт может обслуживаться правилами перенаправления.

Эти команды читают состояние. Они не открывают firewall и не создают службу. Не завершайте неизвестный процесс только для того, чтобы освободить номер: сначала определите владельца, зависимости и согласованный способ изменения.

TCP подключился — проверяем HTTP и TLS

Test-NetConnection -ComputerName portal.example -Port 443 -InformationLevel Detailed
Resolve-DnsName -Name portal.example -Type A
Resolve-DnsName -Name portal.example -Type AAAA

portal.example — заменяемое учебное имя, не реальный корпоративный сервис. Первая команда запускает TCP-проверку и показывает параметры, включая выбранный адрес и результат TcpTestSucceeded. Она не отправляет полноценный запрос приложения и не является UDP-тестом. Две следующие команды отдельно смотрят IPv4- и IPv6-разрешение имени; сравните их с фактической целью подключения.

curl.exe --connect-timeout 5 --max-time 15 -I https://portal.example/

В Windows явно вызываем curl.exe. В Linux используется curl с теми же параметрами. --connect-timeout ограничивает фазу подключения, --max-time — весь вызов, -I запрашивает заголовки методом HEAD. Ответ HTTP означает, что достигнут отвечающий HTTP-узел, но backend или бизнес-операция всё ещё могут быть неисправны.

HEAD может обрабатываться иначе, чем рабочий GET или авторизованный запрос. Ошибку сертификата не скрывают постоянным -k: проверяют имя, SNI, цепочку, сроки и доверие. 401/403 может означать, что сервис доступен, но не разрешает операцию этому клиенту; 502/503 — что ответил proxy или другой HTTP-узел, а не обязательно целевое приложение.

UDP: проверяем запросом нужного протокола

Resolve-DnsName -Name example.com -Server 10.20.0.53 -DnsOnly
Resolve-DnsName -Name example.com -Server 10.20.0.53 -DnsOnly -TcpOnly

Пример для PowerShell: замените 10.20.0.53 на согласованный DNS-сервер. Первая команда выполняет обычный DNS-запрос, который при необходимости может использовать TCP; по одному успешному результату нельзя утверждать, что ответ пришёл именно по UDP. Вторая явно требует DNS через TCP. Для точного доказательства транспорта сопоставляют запрос с захватом и журналом.

dig @10.20.0.53 example.com A +time=2 +tries=1 +notcp +ignore
dig @10.20.0.53 example.com A +time=2 +tries=1 +tcp

В Linux при установленном dig первая команда запрещает TCP и с +ignore не переходит на него при усечённом ответе; вторая проверяет TCP. Время ожидания и число попыток ограничены. Проверяйте статус ответа, источник и ожидаемую запись; отсутствие рекурсии для клиента может быть нормальной политикой DNS.

Молчание на произвольную UDP-датаграмму не является надёжным доказательством «порт закрыт». Сервис может ждать другой формат или намеренно не отвечать. Для телефонии, VPN и других UDP-протоколов выбирают собственную корректную проверку, а не заменяют её TCP-пробой того же номера.

Как сформулировать правило firewall

Полезная заявка содержит источник, назначение, транспорт, порт, направление, цель и срок действия. Например: «Разрешить из 10.10.10.0/24 к 10.20.0.10 TCP 443 для корпоративного портала; остальные источники — по действующей политике».

• Проверить правило на клиенте, сервере и промежуточном устройстве, если оно фильтрует этот поток.
• Учесть интерфейс, зону, профиль Windows, VPN, IPv4/IPv6 и реальный адрес после NAT.
• Различать доступ к самому маршрутизатору и проходящий через него трафик.
• Проверить обратный путь и обработку stateful-состояния.
• Записать назначение правила, владельца, дату проверки и способ удаления временного доступа.

Отключение firewall целиком усложняет выводы и расширяет доступ. Для диагностики лучше сопоставить конкретный тест с попаданием в ожидаемое правило и ограниченным журналированием. В статье нет универсальной изменяющей команды firewall: синтаксис и порядок правил зависят от платформы и реальной политики.

Проброс порта и обратный путь

При входящем перенаправлении внешний адрес и порт могут переводиться во внутренние. Клиент обращается к TCP 8443 на границе, а сервер видит соединение к 443. Исходный адрес также может измениться при дополнительном SNAT. Диагностика должна учитывать, какие параметры видны на каждом участке.

Одного DNAT недостаточно, если фильтр запрещает поток или ответ сервера уходит через другой шлюз без нужного состояния. Проверка изнутри по внешнему имени может зависеть от hairpin NAT или split DNS и иметь другой результат, чем проверка снаружи.

Частный WAN-адрес и CGNAT у провайдера могут не позволять обычную входящую публикацию. Сначала выясните реальную схему адресации и договорённость с оператором. Перенос внешнего номера с 443 на 8443 не заменяет TLS, обновления, права и защиту опубликованного сервиса.

Контейнеры, proxy и балансировщики

У приложения внутри контейнера может быть порт 80, у хоста — 8080, а у внешнего reverse proxy — HTTPS 443. Это не ошибка: перед вами разные точки одного пути. При диагностике последовательно проверяют публикацию, доступность backend и ответ приложения.

• Docker: запись публикации вида 127.0.0.1:8080:80 ограничивает хостовую привязку; 8080 и 80 выполняют разные роли.
• Reverse proxy: принимает клиентский HTTP/TLS-сеанс и создаёт отдельное соединение к backend.
• Балансировщик: может отвечать на подключение, хотя одна или все целевые службы неисправны.
• Сетевое пространство: localhost контейнера и localhost хоста — разные точки.

У Docker поведение публикации и прямого доступа зависит от сетевого режима, правил и версии. Не переносите вывод про один режим bridge на host network или другую архитектуру. Проверьте фактические mapping и правила установленной системы. Дополнительный слой не отменяет авторизацию и правильную привязку backend.

Типовые результаты и правильный следующий шаг

• Connection refused: получен отказ на подключение. Возможны отсутствие listener или активный reject; выясните источник ответа.
• Timeout: своевременного результата нет. Возможны фильтр, маршрут, потери, перегрузка или проблема обратного пути.
• Локально работает, из LAN нет: проверить bind, адрес клиента, firewall, маршрут и сетевой контекст.
• По IP иначе, чем по имени: проверить DNS, IPv4/IPv6, виртуальный сайт, TLS/SNI и proxy.
• TCP успешен, HTTP ошибочный: перейти к TLS, коду HTTP, журналам и зависимостям приложения.
• После переноса порт занят: определить фактический процесс и конфигурацию, не завершать его наугад.

Не превращайте возможную причину в установленный диагноз. Тайм-аут не доказывает именно firewall, а отказ TCP не подтверждает исправность всех промежуточных устройств. Сопоставляйте клиентские результаты с listener, журналами и точкой прохождения пакета.

Локальный пример: listener, HTTP и остановка

Скачайте ZIP и распакуйте в отдельную папку. Внутри lab-web находятся только health.json и README. Нужен установленный Python 3; порт 18080 должен быть свободен. Если занят, выберите другой и замените его во всех командах — не останавливайте чужой процесс.

# Windows: из родительской папки lab-web
py -3 -m http.server 18080 --bind 127.0.0.1 --directory .\lab-web
# Linux: соответствующая команда вместо Windows-варианта
python3 -m http.server 18080 --bind 127.0.0.1 --directory ./lab-web

Запускают только вариант своей ОС. Команда создаёт временный HTTP-сервер на loopback 127.0.0.1:18080 и раздаёт выделенную папку. Она занимает терминал до Ctrl+C. Не используйте модуль как production-сервер и не запускайте его из каталога с рабочими данными.

# В другом терминале Windows
Test-NetConnection -ComputerName 127.0.0.1 -Port 18080
curl.exe --noproxy "*" -i http://127.0.0.1:18080/health.json
# Для Linux: curl --noproxy '*' -i http://127.0.0.1:18080/health.json

TCP-проверка подтверждает возможность соединения. curl затем запрашивает конкретный файл: ожидаем HTTP 200 и JSON с service avg-it-ports-demo, status ok. --noproxy исключает proxy для этой локальной проверки. Успех одного TCP без ожидаемого JSON ещё не завершает эксперимент.

Остановите только свой сервер Ctrl+C и снова посмотрите listener: он должен исчезнуть. Последующий запрос не должен успешно получать тот же файл от завершённого процесса. Если ответ остаётся, выясните, какой процесс отвечает.

Что проверено при подготовке: 13 ноября 2026 года на Windows с Python 3.12.14 запущен локальный сервер, подтверждены listener 127.0.0.1:18080 и его процесс, TCP-соединение, HTTP 200 и ожидаемый JSON через curl.exe. Созданный процесс остановлен, повторное TCP-подключение больше не установилось.

Этот пример проверяет локальные TCP и HTTP без TLS. Он не испытывает DNS, доступ из LAN, входящую публикацию, VPN или Интернет. Результаты выполненной локальной проверки хранятся отдельно от общих примеров команд.

Что считать доказанным результатом

1. Зафиксировать точку проверки, имя, разрешённый IP, транспорт и порт.
2. Найти listener и владельца процесса на ожидаемом узле или в нужном контейнере.
3. Проверить соединение или корректный UDP-обмен с реального клиента.
4. Проверить TLS и протокол приложения, включая ожидаемый ответ.
5. Выполнить пользовательскую операцию с нужными правами.
6. Сохранить время, логи, изменение и способ возврата; настроить наблюдение нужного уровня.

Мониторинг порта полезен, но не заменяет контроль сервиса. История listener, соединений, ошибок TLS, HTTP и нагрузки помогает расследовать, когда возникла проблема и какие изменения ей предшествовали.

Первичные источники: реестр IANA, ss, Test-NetConnection, учебный HTTP-сервер Python. Документация сверена 13 ноября 2026 года; доступность команд зависит от версии и установленных компонентов.

Скачать пример и карточку диагностики

Архив не содержит паролей и производственных конфигураций. Пример слушает только loopback; правила firewall и маршрутизатора не изменяет.

Поможем восстановить доступ и сопровождать сервисы

Вопросы и ответы