#Признаки неисправности и область применимости
Правило безопасности для нужного TCP- или UDP-порта есть, но соединение с ресурсом Yandex Cloud всё равно не проходит. Ключевое отличие от случая с SSH: диагностика подходит для произвольной службы — HTTP, БД, DNS или внутреннего API.
#Почему это происходит
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Неправильное направление либо протоколПравила групп безопасности имеют отдельные направления, протоколы и источники. | Указан исходящий TCP, а ожидался входящий UDP | Сверьте реальный транспорт и направление. |
| Группа не назначена нужному интерфейсуПравило не действует на ВМ без привязки группы. | В другом проекте правило работает, здесь нет | Проверьте сетевой интерфейс. |
| Приложение не слушает внешний интерфейсБлокировка в гостевой ОС или bind только на loopback выглядит как проблема облака. | Служба доступна на localhost, но не по внутреннему IP | Проверьте сокет и локальный брандмауэр. |
#Пошаговая диагностика и устранение
- Определите пару соединенияЗапишите источник IP, назначение IP, порт, протокол TCP/UDP, направление и время неудачной попытки. Для браузера HTTPS обычно TCP 443; для обычного DNS — UDP 53 (иногда TCP 53). Не используйте тест TCP для проверки работоспособности UDP-приложения.
- Узнайте адрес действительного интерфейсаВ Compute Cloud откройте ВМ → «Сеть» и найдите сетевой интерфейс, через который должен идти трафик. Для приватного подключения используйте внутренний IP, а не внешний адрес NAT. Сверьте подсеть и маршруты по архитектуре сети.
- Сверьте привязанные группы и правилаВ Virtual Private Cloud → «Группы безопасности» найдите группы именно этого интерфейса. Проверьте направление (входящее на сервер, исходящее у клиента), протокол, точный порт или диапазон и источник — IP, CIDR или выбранную группу.
- Проверьте исходящие разрешенияЕсли у клиента тоже включены группы безопасности, ему требуется разрешённый исходящий трафик. Для новых подключений проверьте нужное направление с обеих сторон. Не расширяйте правила на весь диапазон 0–65535 ради одного сервиса.
- Сделайте пробу с разрешённого источникаС машины в разрешённой сети выполните проверку TCP на целевой адрес. Отказ соединения означает отличную от тайм-аута ошибку. Для UDP используйте штатный протокольный запрос клиента и журналы, а не утилиту TCP.
- Linux/macOS с nc, без администратораLinux · Терминал (Bash)КомандаLinux/macOS с nc, без администратора. Подставьте приватный адрес и требуемый TCP-порт. Успех — succeeded/open; команда не проверяет UDP.
nc -vz -w 5 PRIVATE_IP 443
- Проверьте слушающий сокет на сервереНа целевой Linux-ВМ проверьте конкретный порт и привязанный адрес. 127.0.0.1 означает доступ только локально; 0.0.0.0 или частный IP — доступ через интерфейс при выполнении правил. Для UDP используйте
ss -lnupвместо TCP. - Linux, только чтениеLinux · Терминал (Bash)КомандаНужен sudoLinux, только чтение. Найдите требуемый порт, приложение и локальный адрес; не исправляйте настройки чужих служб.
sudo ss -lntp
- Проверяйте локальный брандмауэрВ гостевой ОС изучите текущие nftables/ufw/firewalld правила, если они используются. Создавайте узкое разрешение под конкретную сеть и порт только после согласования; облачное правило не отменяет запрет внутри ОС.
- Повторите запрос и откатите лишнееПосле точечной правки повторите ту же пробу. Убедитесь, что открывается один нужный сервис, а не все порты. Если результат не изменился, верните правило к исходному состоянию и продолжите диагностику маршрута и приложения.
#Как проверить, что проблема исправлена
Подключение к требуемому порту проходит с разрешённого источника и остаётся закрытым для неразрешённых клиентов. Сервис отвечает на свой протокольный запрос; в журнале не появляются новые ошибки.
#Если проблема осталась
Если TCP проходит, а приложение выдаёт 500 или ошибку авторизации, это уже прикладной уровень. Если TCP завершается тайм-аутом при корректных правилах, сравните маршруты подсетей, локальный брандмауэр и адрес назначения.