Открытые порты, фаерволы и «почему мой порт показывается закрытым извне»

Несколько раз в неделю приходит тикет в духе: «открыл порт 8080, но yougetsignal/canyousee.me показывают что закрыт, откройте у себя». Честный ответ — никакого «откройте у себя» нет. На ВНЕШНЕМ фаерволе (наш сетевой edge) все TCP- и UDP-порты открыты на вход и выход по умолчанию — ограничен только исходящий SMTP на пользовательских тарифах. Есть ещё ВНУТРЕННИЙ фаервол, живущий в операционной системе вашего VPS (ufw / firewalld / iptables / Windows Defender) — к нему у нас нет доступа и мы его не трогаем. Когда внешний чекер говорит «закрыт», блокирует именно внутренний фаервол или отсутствующий/неправильно привязанный listener внутри VPS. Эта статья разбирает оба слоя и как продиагностировать каждый.

Два фаервола, два разных владельца — прочтите сначала это

Между публичным интернетом и сервисом, который крутится внутри вашего VPS, есть ДВА слоя фаервола, и владельцы у них разные. Путаница между ними — главная причина, почему такие тикеты вообще существуют:

Практическое следствие: когда внешний чекер портов говорит «закрыт», блокирующий слой почти всегда внутренний — ОС-фаервол внутри VPS или сервис, который не слушает. Мы не видим и не можем это исправить со своей стороны; шаги диагностики ниже выполняются ВНУТРИ VPS — и это ваша зона.

Что наш внешний сетевой слой делает (и что не делает)

• Все TCP-порты 1–65535: открыты на вход и на выход по умолчанию на сетевом edge.
• Все UDP-порты 1–65535: открыты на вход и на выход по умолчанию на сетевом edge.
• ICMP (ping/traceroute): разрешён в обе стороны.
• Единственное исключение: исходящие SMTP-порты блокированы на сетевом edge для не-корпоративных тарифов (см. ниже).
• Мы не инспектируем, не троттлим и не фильтруем никакой другой трафик на этом слое. Что вы крутите на порту, как привязали и как защищено внутри VPS — целиком ваша зона ответственности.

Почему исходящий SMTP заблокирован (и как снять)

Исходящий SMTP — протокол доставки почты — это единственное сетевое ограничение, которое мы применяем по умолчанию на пользовательских тарифах. Конкретно:

Зачем это нужно: свежеарендованный VPS — одно из самых частых мест, откуда запускают исходящий спам. Один скомпрометированный клиент за часы может убить репутацию всего блока IP — Spamhaus, SpamCop, Barracuda и Microsoft внесут его в листинги, и у всех остальных клиентов с того же /24 неделями начнут отбиваться легитимные письма. Мы блокируем 25-й порт и компанию именно для того, чтобы один невнимательный клиент не сломал доставку почты для всех соседей по блоку.

Если у вас есть легитимная задача отправлять почту напрямую (свой корпоративный mail-сервер, высокообъёмная рассылка, бэкенд транзакционных писем), мы можем снять SMTP-ограничение после короткой верификации компании / проекта. Откройте тикет из клиентской панели и расскажите: с какого домена будете слать, какие объёмы, с какого провайдера переезжаете — типичный срок ответа в тот же день.

«Порт открыт» vs «сервис слушает на порту» — самая частая путаница

Внешний чекер портов (yougetsignal.com, canyousee.me, nmap с другой машины) показывает «open» только если какой-то процесс реально принимает соединения на этом порту. Просто «открыть» порт в фаерволе недостаточно — нужно чтобы кто-то слушал на той стороне. Если никто не слушает — ядро отвечает TCP RST, и чекер говорит «closed», независимо от любых правил фаервола.

Правильная ментальная модель — два отдельных вопроса:

1. Слушает ли процесс на этом порту? (задача вашего приложения)
2. Пропускает ли фаервол входящий трафик на этот порт? (задача вашей ОС)

Должны быть верны оба одновременно. Большинство тикетов «порт закрыт» падают на вопросе 1, а не 2.

Шаг 1 — проверить, что реально слушает

Запустите изнутри VM:

# Современные системы (Linux):
ss -tlnp                # TCP-листенеры с именами процессов
ss -ulnp                # UDP-листенеры с именами процессов

# Старое/портативное:
netstat -tlnp

# Фильтр по конкретному порту:
ss -tlnp | grep :8080

Внимательно прочитайте вывод. Колонка Local Address говорит не только про порт, но и про интерфейс, к которому привязан процесс:

Шаг 2 — выяснить, какой фаервол реально активен

На свежем Linux VPS могут одновременно работать любые комбинации (часто без вашего ведома):

• iptables — классический пакетный фильтр Linux. Даже если вы его не трогали, дистрибутив иногда ставит дефолтные правила.
• nftables — современная замена iptables. Debian 11+, Ubuntu 22.04+, RHEL 8+ идут с nftables по умолчанию и могут транслировать iptables-правила через него.
• ufw (Ubuntu / Debian) — дружелюбная обёртка над iptables/nftables. Если вы один раз сделали `ufw enable` и забыли — весь входящий трафик кроме явно разрешённого дропается.
• firewalld (CentOS, RHEL, Rocky, AlmaLinux, Fedora) — zone-based обёртка над nftables. Дефолтная зона часто разрешает только ssh + dhcpv6-client.
• Legacy-пакет iptables-services — иногда установлен параллельно с firewalld, и в реальности применяется один из них.
• Правила уровня контейнеров (Docker, Podman) — Docker сам пишет правила в iptables, чтобы пробрасывать порты контейнеров. `docker run -p 80:80` добавляет правила; `docker run -p 127.0.0.1:80:80` пробрасывает только на localhost (см. Шаг 1).

Команды для быстрой ревизии:

# ufw активен?  (вернёт 'Status: active' или 'Status: inactive')
sudo ufw status verbose

# firewalld активен?
sudo systemctl is-active firewalld
sudo firewall-cmd --state
sudo firewall-cmd --list-all       # правила в дефолтной зоне

# Какие правила реально загружены в ядро?
sudo iptables -L -n -v             # IPv4 (также покажет правила, транслированные из nftables)
sudo ip6tables -L -n -v            # IPv6
sudo nft list ruleset              # натуральный nftables-вид

# Docker добавил правила?
sudo iptables -L DOCKER -n -v 2>/dev/null
sudo iptables -L DOCKER-USER -n -v 2>/dev/null

Если `iptables -L` показывает policy ACCEPT и нет правил DROP/REJECT — никакой фаервол не блокирует входящий трафик, ваша проблема в другом месте (скорее всего в Шаге 1, привязке listener-а). Если видите строки `target=DROP` или `target=REJECT`, попадающие на ваш порт — это и есть причина.

Шаг 3 — открыть порт в фаерволе (если он реально нужен)

# ufw (Ubuntu/Debian):
sudo ufw allow 8080/tcp
sudo ufw reload

# firewalld (RHEL/CentOS/Rocky):
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

# nftables напрямую:
sudo nft add rule inet filter input tcp dport 8080 accept

# iptables напрямую (volatile — без iptables-persistent не переживёт перезагрузку):
sudo iptables -I INPUT -p tcp --dport 8080 -j ACCEPT

Другие классические грабли, которые мы видим в тикетах

• SELinux блокирует сам bind. На RHEL/Rocky/AlmaLinux сервис может отказываться биндиться на нестандартный порт, потому что SELinux policy не разрешает. Проверьте `sudo ausearch -m AVC -ts recent` или временно `setenforce 0` для теста (не оставляйте так).
• Сервис слушает только IPv6, а вы тестируете по IPv4. Часто у Java-приложений и некоторых Python-фреймворков. Смотрите в `ss -tlnp` `[::]:port` против `0.0.0.0:port`.
• Cloud-init или ваша панель хостинга включает фаервол при ребуте. Если сервис вчера работал, а сегодня после ребута перестал — `systemctl status ufw firewalld iptables`.
• Тестируете изнутри той же VM через `curl http://ваш-публичный-ip` и получаете connection refused. Некоторые routing-настройки не разрешают loopback через публичный IP. Тестируйте с другой машины или `curl https://canyousee.me` с ноутбука.
• DNS A-запись указывает на не тот IP. Порт открыт, но вы тестируете не тот сервер. Подтвердите через `dig +short yourdomain.com` с ноутбука.
• UDP-сервис без conntrack-правила. UDP без соединений; некоторые конфиги фаервола требуют явного return-path правила. В большинстве дистрибутивов это работает само, но кастомные сетапы могут дропать ответ.
• Не тот сетевой интерфейс. На VPS с несколькими NIC или при наличии VPN/WireGuard-интерфейсов сервис может биндиться к не тому. Проверьте имена в `ip -br addr` и привяжите сервис явно.

Краткое дерево решений

1. Внешний чекер говорит «closed». Запустите `ss -tlnp | grep :ПОРТ` внутри VM. Нет вывода? → запустите сервис. Привязан к 127.0.0.1? → пересвяжите на 0.0.0.0. Привязан к 0.0.0.0? → дальше.
2. Сервис на 0.0.0.0:ПОРТ. Запустите `sudo ufw status` и `sudo systemctl is-active firewalld`. Один из них активен и нет правила? → добавьте правило выше.
3. Оба чисто. Запустите `curl -v http://ВАШ-ПУБЛИЧНЫЙ-IP:ПОРТ` с ДРУГОЙ машины (не с самого VPS). Если работает — внешний чекер ошибся (или DNS не туда). Если падает с `Connection refused` — перепроверьте Шаг 1; с `Connection timed out` — перепроверьте Шаг 2.
4. Всё равно не работает? Тогда стоит открыть тикет. Приложите: вывод `ss -tlnp`, вывод `sudo iptables -L -n -v`, точный публичный IP куда стучитесь, и команду теста с внешней машины.

Смежно: сетевой слой под всем этим описан в статье про общий порт 1 Гбит/с в VPS. Если ваша проблема «порт работает, но медленно» — это статья про скорость интернета, а не эта.