Когда программа или сайт перестают работать, одна из частых причин — закрытый или фильтруемый порт. Без открытых портов клиент и сервер не смогут установить соединение, а значит — сервис “молчит” даже при исправном интернете. Понимание, как проверить порты на открытость, — базовый навык системного администратора и техподдержки: он помогает быстро найти “узкое место”, вернуть сервис в строй и укрепить безопасность.
Что такое порт и зачем он нужен
Порт — это логическая “дверь” в системе, через которую приложение принимает и отправляет сетевые данные. У каждого сетевого сервиса есть свой стандартный порт: 80 — HTTP, 443 — HTTPS, 22 — SSH, 21 — FTP, 25/587 — SMTP, 53 — DNS, 3389 — RDP, 1433 — MS SQL, 3306 — MySQL.
Если нужный порт закрыт, приложение не сможет принять соединение; если он открыт не тем сервисом — появится конфликт; если открыт снаружи без необходимости — возникает лишний риск взлома. Поэтому администратор одновременно решает две задачи: доступность и минимизацию поверхности атаки.
Почему важно регулярно проверять порты
Во-первых, доступность: после миграций, обновления ОС, смены фаервола или переноса в облако легко потерять правило, из-за которого сервис окажется недоступен. Во-вторых, безопасность: открытые лишние порты — распространённая причина инцидентов. В-третьих, контроль конфигураций: в сложных инфраструктурах (on-prem + облако + филиалы) фактическое состояние портов нередко расходится с документацией.
Таким образом, как проверить порты на открытость — вопрос не разовой диагностики, а постоянной рутины, встроенной в регламенты сопровождения.
Проверка портов в Windows: быстрые приёмы
Через “Командную строку” можно увидеть, какие порты слушают локальные процессы (LISTEN) и есть ли активные соединения:
— netstat -an — сводная картина;
— netstat -an | find «:443» — точечная проверка нужного порта;
— PowerShell-команда Test-NetConnection -ComputerName хост -Port порт — быстрая удалённая проверка доступности сервиса с измерением задержки и указанием, прошёл ли TCP-тест.
Если правило брандмауэра блокирует вход, соединение не установится, даже если приложение “слушает” порт. Поэтому всегда сверяйте сетевую картину с правилами Windows Defender Firewall (входящие/исходящие) и политиками домена (GPO).
Проверка портов в Linux: что, где и кем слушается
В Linux аналогичные задачи решаются утилитами ss или netstat:
— ss -tulpn — список TCP/UDP-портов и процессов;
— ss -lnt — только TCP-LISTEN;
— telnet хост порт или nc -zv хост порт — удалённая проверка, устанавливается ли TCP-сеанс.
Важно разбирать соответствие: интерфейс (0.0.0.0/::) — порт — процесс — служба — единицы systemd. Часто “порт не открыт” на самом деле означает “служба не поднята” или “слушает только 127.0.0.1”.
Онлайн-сервисы и внешняя перспектива
Когда нужно проверить доступ “снаружи” (например, сервис стоит за домашним роутером или корпоративным NAT), помогают внешние чекеры портов. Они позволяют увидеть порт глазами интернета: открыт ли 443 извне? доходит ли проброс 22 к нужной машине? Это особенно полезно при настройке RDP/VPN, публикации веб-приложений и тестах после изменения провайдера или маршрутизации.
Nmap: глубокая диагностика и безопасность
Nmap сканирует диапазоны портов, определяет состояние (open/closed/filtered), часто умеет распознавать службы и версии протоколов. Его используют и для инвентаризации (что реально открыто на узле), и для аудита безопасности (что лишнее).
Практически: начинайте с узкого списка критичных портов (22/80/443/25/1433/3306/3389), затем расширяйте сканирование. Регулярный отчёт Nmap — удобный артефакт для измененийной комиссии и внутреннего аудита.
TCP против UDP: важные нюансы проверки
Многие администраторы проверяют только TCP и удивляются, почему “DNS не работает”, хотя “порты открыты”. Дело в том, что UDP не устанавливает сеанс, и простая проверка “соединения” к нему неприменима.
Как действовать:
— для UDP-сервисов (DNS 53, VoIP 5060/ RTP, стриминг) используйте профильные тесты (dig/nslookup для DNS, специальные утилиты для медиа);
— учитывайте, что фаерволы часто фильтруют UDP более жёстко;
— проверяйте не только порт, но и путь: MTU, фрагментацию, политику NAT, поведение прокси и UTM.
NAT, проброс портов и CGNAT
Если сервер за маршрутизатором, потребуется Port Forwarding (NAT): внешний порт роутера → внутренний адрес:порт. Ошибки здесь типичны: неправильный внутренний IP, конфликт правил, двойной NAT, коллизии UPnP.
Отдельная история — CGNAT у провайдера: белого внешнего IP у клиента нет, поэтому открыть порт “во внешний мир” невозможно. В этом случае используйте:
— VPN с внешней точкой (Site-to-Site/сервер-клиент),
— reverse-proxy/туннели (например, через публичный фронт),
— облачные балансировщики/интеграторы (LB, Anycast, CDN) в зависимости от задачи.
Чек-лист: от симптома к решению
- Подтвердите, что служба запущена и слушает нужный порт на нужном интерфейсе.
- Проверьте локальный фаервол (Windows Defender/iptables/ufw): есть ли разрешающие правила ingress/egress.
- Проверьте маршрутизатор/облако: Security Groups, ACL, Port Forwarding, приоритет правил, двойной NAT.
- Выполните локальный тест (ss/netstat) и удалённый тест (Test-NetConnection/telnet/nc) — в идеале из нескольких сетей.
- Сегментируйте проблему: TCP/UDP, внутренний/внешний контур, IPv4/IPv6, балансировщик/инстанс.
- Задокументируйте итог: кто слушает, где открыт, откуда доступен, кто владелец правила и срок пересмотра.
В середине отладки полезно ещё раз проговорить цель: какой именно сервис проверяется и как проверить порты на открытость именно для него (протокол, порт, источник, направление).
Безопасность: минимально необходимый набор
Правило “минимально необходимого” означает: открыт только тот порт, который нужен бизнес-сценарию, с ровно теми источниками (CIDR/IP), которым он необходим, и в нужном направлении (ingress/egress). Добавьте:
— централизованный журнал подключений (SIEM/лог-коллектор),
— регулярный отчёт об отклонениях (сравнение Nmap с эталоном),
— ревью правил после релизов и инцидентов,
— автопроверки в CI/CD ( smoke-тест порта после деплоя ).
Автоматизация мониторинга портов
В ручном режиме легко упустить деградацию. Интегрируйте проверки в Zabbix/Nagios/Prometheus:
— активные проверки критичных портов,
— алерты при смене статуса open→filtered/closed или росте задержки,
— дашборды по сервисам и площадкам,
— отчёты по трендам (когда порт “падал” и почему).
Такой мониторинг сокращает MTTR, упрощает разговор с провайдерами и фиксирует доказательства для пост-морте и аудита.
Заключение
Проверка портов — не одноразовая команда, а дисциплина. Она объединяет доступность, безопасность и эксплуатацию. Зная, как проверить порты на открытость локально и извне, отличая TCP от UDP, понимая NAT/CGNAT и правила фаерволов, вы быстрее находите причину простоя и не оставляете лишних щелей в периметре.
Системный подход — чек-листы, автоматизация, аудит и документирование — превращает “проверил порт” из хаотичной операции в устойчивую практику качества.
Хочешь уверенно работать с сетями, портами и безопасностью в реальных проектах? Подробнее в нашем курсе «Профессия системный администратор«