Диагностика порта, заблокированного firewall

Задача и общий подход

Материал посвящён теме «Диагностика порта, заблокированного firewall» с акцентом на диагностике и локализации ошибок.

Firewall не запускает сервис: он только разрешает или запрещает пакеты. Для соединения одновременно нужны listener, маршрут и подходящее правило.

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

Что должно получиться

После выполнения руководства по теме «Диагностика порта, заблокированного firewall» результат должен быть измеримым:

• зафиксировать логи и признаки успешного запуска
• сохранить резервную точку и понятный сценарий отката
• оставить наружу только необходимые интерфейсы и порты
• исключить зависимость от временных правил и ручных действий

Когда применять этот порядок

Этот сценарий подходит для следующих ситуаций:

• плановое внедрение или перенос компонента категории «Firewall» на новый VPS
• изменение портов, домена, сертификата, маршрута или способа публикации сервиса
• разбор инцидента, когда локальная и внешняя проверки дают разные результаты
• подготовка к обновлению пакета или восстановлению после неудачного изменения
• аварийная диагностика с фиксацией симптомов до перезапусков

Подготовка перед изменениями

Подготовительный этап снижает риск потерять доступ и смешать несколько причин одной неисправности.

• Сохраните копии изменяемых файлов с датой и временем.
• Подготовьте команду отката до применения изменений.
• Зафиксируйте текущие порты, процессы и состояние службы.
• Откройте вторую административную сессию и не закрывайте текущую.
• Используйте встроенную проверку синтаксиса конфигурации.

Пошаговая настройка

Выполняйте блоки последовательно и после каждого шага проверяйте код возврата команды.

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH admin only'

sudo ufw allow 443/tcp comment 'HTTPS public'

sudo iptables -L ufw-user-input -n --line-numbers
sudo ip6tables -L ufw6-user-input -n --line-numbers

nc -vz -w 3 127.0.0.1 443
curl -vk https://example.org/

sudo ufw status numbered
sudo ss -lntup

Имена доменов, адреса, порты и пути в примерах условные. Перед выполнением замените их фактическими значениями.

Проверка результата

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

• SSH разрешён текущему IP
• вторая SSH-сессия работает
• сервис слушает нужный адрес
• IPv4 и IPv6 ожидаемы
• ненужные порты закрыты

systemctl is-active SERVICE
systemctl status SERVICE --no-pager
journalctl -u SERVICE -n 80 --no-pager
ss -lntup

Диагностика, если не заработало

Диагностика строится как последовательное исключение уровней, а не случайный набор перезапусков.

1. Подтвердите симптом точной командой и запишите время.
2. Проверьте конфигурацию штатным тестом.
3. Проверьте процесс и последние записи журнала.
4. Убедитесь, что нужный адрес и порт слушаются.
5. Сравните локальный запрос с запросом извне.
6. Только затем проверяйте firewall, DNS и маршрут.
7. Меняйте одну переменную и повторяйте тот же тест.

Для темы «Диагностика порта, заблокированного firewall» важно не путать открытый firewall с запущенным сервисом: правило доступа не создаёт listener, а активный процесс не гарантирует доступность извне.

Как устроена схема

UFW формирует цепочки netfilter, где важен порядок правил. IPv4 и IPv6 обрабатываются отдельно, поэтому политика для двух семейств должна проверяться раздельно.

Важно разделять конфигурацию, процесс, сетевой сокет и внешний запрос. Успех на одном уровне не доказывает исправность следующего.

Безопасность

После получения рабочего результата уменьшите количество исключений и временных разрешений.

• не храните секреты в публикуемых конфигурациях и журналах
• используйте принцип минимально необходимых прав
• выдавайте файлам конфигурации минимальные права
• просматривайте журналы аутентификации и ошибки запуска
• закрывайте временные порты после завершения теста

Дальнейшее сопровождение

Рабочая конфигурация со временем устаревает и требует контроля.

• проверяйте журналы ошибок и их размер
• после обновления повторяйте тест конфигурации и портов
• контролируйте таймеры, сертификаты и автоматические задания
• периодически выполняйте тестовое восстановление
• храните резервную копию вне VPS

Типичные ошибки

Чаще всего восстановление усложняют следующие действия:

• изменение нескольких компонентов одной командой без промежуточных тестов
• игнорирование различий правил IPv4 и IPv6
• использование устаревшей команды без проверки версии пакета
• проверка только локального подключения без внешнего теста
• открытие административного порта для всего интернета
• удаление рабочей конфигурации до успешного запуска новой

Откат изменений

Откат выполняется в обратном порядке и с теми же проверками, что использовались после настройки.

1. не закрывать текущую SSH-сессию
2. удалять только точное последнее правило
3. при потере доступа использовать консоль
4. не делать ufw reset без копии

Не удаляйте неудачную конфигурацию до выяснения причины: она полезна для diff и разбора инцидента.

Контрольный список

Перед тем как считать тему «Диагностика порта, заблокированного firewall» закрытой, пройдите список:

Что дополнительно сверить в документации

При подготовке материала были сопоставлены разделы русскоязычной документации. Для углублённой проверки полезно изучить:

• Firewall
• Содержание
• Netfilter
• Ссылки
• pg_dump
• Синтаксис
• Описание
• Предупреждение

Локальная и внешняя точка наблюдения

Локальный запрос исключает часть сети и полезен для проверки процесса. Внешний запрос добавляет публичный маршрут, firewall, DNS и TLS. Оба результата нужны одновременно.

При расхождении двигайтесь от сервера наружу, проверяя каждый переход отдельно.

Критерий отката для текущей задачи

Для темы «Диагностика порта, заблокированного firewall» заранее определите признаки неудачи: штатная проверка не проходит, процесс не запускается, ожидаемый listener исчез, внешний клиент получает неверный ответ или в журнале растёт число ошибок. После достижения лимита времени выполняйте откат, а не продолжайте добавлять неподтверждённые изменения.

Откат считается завершённым только после возврата исходных проверок. Само копирование старого файла не гарантирует, что служба перечитала его и снова обслуживает клиентов.

• не закрывать текущую SSH-сессию
• удалять только точное последнее правило
• при потере доступа использовать консоль
• не делать ufw reset без копии

Данные, которые нужно сохранить до изменения

Перед работой по теме «Диагностика порта, заблокированного firewall» сохраните состояние именно тех компонентов, которые участвуют в схеме: активную конфигурацию, статус процесса, открытые порты, последние ошибки и результат контрольного запроса. Этот набор позволит отличить последствия новой правки от ранее существовавшего поведения.

Полезно хранить вывод в одном каталоге с временной меткой и коротким README. При разборе инцидента это быстрее, чем повторно собирать сведения после нескольких перезапусков.

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH admin only'

Firewall и процесс — разные уровни

Правило доступа только пропускает пакет. Если на порту нет listener, клиент получит отказ или таймаут независимо от firewall. И наоборот, локальный listener может быть полностью закрыт снаружи.

Начинайте с ss и локального подключения, затем смотрите UFW и только после этого проверяйте порт с другого узла.

ss -lntp | grep ':PORT'
nc -vz -w 3 127.0.0.1 PORT
sudo ufw status numbered

Источники и документация

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

• Firewall | Русскоязычная документация по Ubuntu
• Компания Postgres Professional
• Компания Postgres Professional
• Компания Postgres Professional