Диагностика iptables без отключения защиты¶

Самый опасный «ремонт» firewall — временно выполнить iptables -F или iptables -P INPUT ACCEPT. Это разрушает модель безопасности, а на Docker-сервере может одновременно повредить контейнерную сеть. Правильная диагностика НАЙС.ОС CLOUD проводится с сохранением действующих правил, просмотром счётчиков и воспроизводимым тестом.

1. Сохраните данные перед изменением¶

umask 077
mkdir -p /root/firewall-audit
iptables-save > /root/firewall-audit/ipv4.rules
ip6tables-save > /root/firewall-audit/ipv6.rules
iptables -V
ip6tables -V
systemctl cat iptables
systemctl status iptables --no-pager

Файлы правил могут содержать приватные IP-адреса и сведения о сегментации. Не загружайте их на публичные сайты.

2. Четыре уровня проверки¶

Уровень	Команда	Что устанавливает
Приложение	`ss -lntup`	Есть ли слушающий сокет и на каком адресе
Адрес/маршрут	`ip route get <адрес>`	Куда ядро отправит ответ
Фильтрация	`iptables -L -n -v --line-numbers`	Порядок правил и счётчики
Пакеты	`tcpdump` (если доступен)	Видно ли фактические запросы/ответы

ss со статусом LISTEN не подтверждает доступности извне. Локальный curl localhost не проверяет входящий INPUT-путь с внешнего интерфейса.

3. Точная проверка SSH¶

ss -lntp | grep ':22'
iptables -S INPUT
iptables -S OUTPUT
ip6tables -S INPUT
ip6tables -S OUTPUT
journalctl -b -u sshd --no-pager -n 80

Имя unit SSH уточняйте на конкретной системе (systemctl list-unit-files '*ssh*'), если sshd не найден. Попробуйте подключиться в новом окне с доверенного адреса и посмотрите, растут ли счётчики предполагаемого правила.

4. Проверка DNS, HTTPS и репозиториев¶

При базовом OUTPUT DROP источник проблемы часто находится не в INPUT, а в исходящем трафике: DNS, HTTPS, NTP и получение RPM-метаданных требуют своих явных разрешений. Проверяйте последовательно:

resolvectl query niceos.ru
getent hosts niceos.ru
ip route
iptables -L OUTPUT -n -v --line-numbers

Не подменяйте проблему DNS отсутствием маршрута: сначала запросы по IP, затем по имени, потом TCP нужного порта.

5. Чем опасна строка DROP в конце цепочки¶

У правил iptables первое совпадение определяет действие. Разрешение, добавленное через -A после терминального -j DROP, никогда не будет достигнуто. Изучайте --line-numbers и размещайте новые разрешения до запрещающих правил. Не вставляйте правило на позицию 1 без оценки уже существующих ограничений.

6. Долговременное сохранение¶

iptables-save записывает снимок в stdout. Сам по себе этот файл не доказывает, что сервис прочитает его после перезапуска. В НАЙС.ОС пакет ставит iptables.service, /etc/systemd/scripts/ip4save и ip6save, но точный режим чтения зависит от SourceN, которого нет в предоставленном архиве.

Проверьте:

systemctl cat iptables
ls -l /etc/systemd/scripts/
sed -n '1,160p' /etc/systemd/scripts/iptables
head -n 30 /etc/systemd/scripts/ip4save

Не сохраняйте изменения поверх ip4save, пока не установили формат: в разных реализациях это может быть не файл с правилами, а скрипт.

7. Как фиксировать результат¶

Сохраните исходную и конечную конфигурации, время и адрес источника теста, сервис/порт, ожидаемое и фактическое поведение. Повторите тест после reboot, только когда есть контроль через консоль. Разделы: открытие порта, NAT, conntrack, IPv6.

Источники: SPEC iptables, официальный минимальный профиль НАЙС.ОС.