Как проверить открыт ли порт на удаленном хосте и локальном хосте

Проверка открытых портов: Локальный хост vs Удаленный хост

В DevOps-практике проверка доступности портов — это базовая, но критически важная операция. Она используется для диагностики сетевых проблем, проверки конфигурации сервисов (веб-серверов, баз данных, брокеров сообщений), валидации правил межсетевых экранов (Firewall) и групп безопасности (Security Groups), а также для аудита безопасности. Методы проверки различаются в зависимости от того, целевой хост находится на той же машине (локальный хост) или доступен через сеть (удаленный хост).

Основные инструменты и подходы

Для этой задачи существует богатый арсенал утилит командной строки, которые есть практически в любой Unix-подобной системе (Linux, macOS) и доступны для Windows (через WSL, Git Bash или отдельную установку).

1. Проверка портов на удаленном хосте

Цель: определить, принимает ли целевой сервер (remote.example.com:443) входящие соединения на конкретном порту извне.

• telnet — классический инструмент для проверки TCP-соединений.

  telnet remote.example.com 443
  

    Если порт открыт, вы увидите пустой экран или приветственное сообщение сервиса. Если закрыт — сообщение об ошибке подключения. `telnet` часто не установлен по умолчанию из-за соображений безопасности (нешифрованный протокол).

• nc (netcat) — "швейцарский армейский нож" для сетей.

    Более гибкий инструмент. Проверка TCP:

```bash
nc -zv remote.example.com 443
```

    Проверка UDP (например, для DNS):

```bash
nc -zuv remote.example.com 53
```

    Ключи: `-z` — режим сканирования (без передачи данных), `-v` — подробный вывод, `-u` — UDP.

• nmap — мощный сканер портов для аудита и разведки.

    Позволяет проверять диапазоны портов и определять сервисы.

```bash
# Проверка одного порта
nmap -p 22 remote.example.com

# Проверка диапазона портов
nmap -p 80-443 remote.example.com

# Быстрое сканирование самых популярных портов
nmap -F remote.example.com
```

    **Важно:** Используйте `nmap` только на инфраструктуре, которой вы управляете, или с явного разрешения. Сканирование чужих сетей может быть расценено как атака.

• Использование высокоуровневых протоколов.

    Иногда нужно не просто проверить доступность порта, но и убедиться в работоспособности сервиса. Для этого подходят клиенты конкретных протоколов:

```bash
# Проверка HTTP/HTTPS
curl -I https://remote.example.com

# Проверка SSH
ssh -o ConnectTimeout=5 -p 22 user@remote.example.com echo "SSH доступен"

# Проверка базы данных PostgreSQL
pg_isready -h remote.example.com -p 5432
```

2. Проверка портов на локальном хосте

Цель: узнать, какие сервисы слушают на сетевых интерфейсах самой машины. Здесь на первый план выходят утилиты, анализирующие состояние сетевого стека ОС.

• ss (современная замена netstat) — предпочтительный инструмент в Linux.

    Показывает детальную информацию о сокетах.

```bash
# Показать все слушающие TCP-порты
ss -tln

# Показать все слушающие UDP-порты
ss -uln

# Показать процессы, использующие конкретный порт (требует прав root)
ss -tlnp | grep :80
```

    Ключи: `-t` — TCP, `-u` — UDP, `-l` — слушающие (listening) сокеты, `-n` — выводить номера портов (не резолвить имена), `-p` — информация о процессе.

• netstat — классический, но устаревающий инструмент.

    До сих пор широко используется. Синтаксис похож на `ss`.

```bash
netstat -tulnp | grep LISTEN
```

• lsof (List Open Files) — показывает все открытые файлы, включая сетевые сокеты.

    Невероятно мощная утилита для глубокой диагностики.

```bash
# Показать кто слушает порт 5432
lsof -i :5432

# Показать все TCP-соединения в состоянии LISTEN
lsof -i TCP -s TCP:LISTEN
```

Ключевые различия и важные нюансы

• Контекст выполнения: Проверка удаленного хоста — это попытка установить соединение. Проверка локального хоста — это аудит конфигурации самой системы.
• Сетевые правила: При проверке удаленного хоста результат зависит от всех межсетевых экранов на пути (локальный фаервол, облачные группы безопасности, корпоративный прокси). Порт может быть открыт на сервисе, но недоступен из-за блокировки. На локальном хосте ss покажет порт как слушающий, даже если он заблокирован фаерволом.
• Состояния сокетов: При локальной проверке обращайте внимание на состояние LISTEN (ожидание входящих соединений). Состояния ESTABLISHED, TIME_WAIT и другие относятся к активным соединениям.
• Интерфейсы привязки (Binding): В выводе ss или netstat колонка Local Address показывает, на каком интерфейсе слушает сервис. 0.0.0.0:80 означает "все интерфейсы", 127.0.0.1:3306 — только локальная петля (loopback), что делает сервис (например, MySQL) недоступным снаружи.

Практический пример для DevOps: проверка перед развертыванием

Представьте сценарий: вы разворачиваете веб-приложение (порт 8080) и кэш Redis (порт 6379) на новом сервере. Ваш чек-лист:

1. После запуска контейнеров/сервисов проверьте локальное прослушивание:

   sudo ss -tlnp | grep -E '(8080|6379)'
   

    Убедитесь, что процессы слушают на нужных портах.

1. Серверным фаерволом (если есть, например, ufw или firewalld) разрешите входящий трафик:

   sudo ufw allow 8080/tcp
   sudo ufw allow 6379/tcp
   

2. Проверьте доступность с удаленной управляющей машины (с CI/CD-сервера):

   nc -zv ваш-новый-сервер 8080
   nc -zv ваш-новый-сервер 6379
   

3. Если проверка не удалась, начните диагностику по цепочке:

    *   Работает ли сервис на целевом хосте? (`systemctl status`, `docker ps`)
    *   Слушает ли он на всех интерфейсах (`0.0.0.0`), а не только на `127.0.0.1`?
    *   Правила фаервола на сервере применены? (`sudo ufw status`)
    *   Разрешены ли порты в облачной **группе безопасности** AWS/Azure/GCP?
    *   Есть ли блокировка на уровне сетевого оборудования или корпоративного proxy?

Таким образом, комбинируя инструменты для локального (ss, lsof) и удаленного (nc, curl) анализа, DevOps-инженер может быстро локализовать проблему — находится ли она в конфигурации приложения, настройках ОС, локальном фаерволе или в сетевой инфраструктуре.