Перейти к содержанию

Исходящие соединения при политике OUTPUT DROP

В строгом профиле НАЙС.ОС CLOUD может действовать OUTPUT DROP: процесс на сервере не сможет произвольно открыть DNS, HTTPS, NTP или соединение к репозиторию только потому, что сеть и маршруты настроены корректно.

Диагностика

sudo iptables -S OUTPUT
sudo iptables -L OUTPUT -n -v --line-numbers
ip -4 route
resolvectl status

Последовательно проверьте DNS, IP-маршрут, резолвинг и целевой порт. Не открывайте весь OUTPUT «для удобства»: это разрушает смысл исходящей фильтрации.

Какие потоки понадобятся приложениям

Сценарий Что может потребоваться Где подтвердить
Системный DNS UDP/TCP 53 к конкретным резолверам, либо иной используемый DNS-транспорт resolvectl status, политика организации
Обновления TCP 443 к узлам репозиториев, при необходимости DNS реальные URL .repo
Синхронизация времени UDP 123 к выбранному NTP-серверу timedatectl, timesyncd.conf
Контейнерный реестр исходящий HTTPS и DNS от хоста/контейнера журнал Docker, FORWARD
Внешний API конкретный адрес/порт API схема приложения и журнал

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

Различайте хост и контейнер

Трафик локального процесса проходит через OUTPUT, а транзит контейнера может проходить через FORWARD и Docker-цепочки. Неподходящая правка OUTPUT не исправит каждый случай отсутствия сети в контейнере.

Порядок безопасного изменения

  1. Зафиксируйте текущие правила (iptables-save) и адрес назначения.
  2. Уточните протокол, порт, источник и сегмент.
  3. Создайте минимальное разрешение на тестовый период, не меняя политику по умолчанию.
  4. Повторите вызов приложения и сопоставьте счётчики iptables.
  5. Удалите тестовое правило или включите подтверждённый механизм постоянной конфигурации.

См. общую модель и сохранение правил.