Введение
Правила, добавленные с помощью команды iptables, изменяют работающий брандмауэр ядра, однако само по себе такое изменение не является постоянной конфигурацией. Администраторы обычно сериализуют правила IPv4 с помощью iptables-save, а затем загружают их обратно в этом формате через iptables-restore. В системах Debian и Ubuntu файл /etc/iptables/rules.v4 является стандартным местом хранения правил, если настроен соответствующий загрузчик, запускаемый при старте системы.
Представьте этот процесс как работу с тремя отдельными уровнями. Работающий набор правил — это правила, которые ядро применяет в данный момент. Сохранённый файл правил — всего лишь текстовый файл на диске, пока какая-либо программа или служба не загрузит его. Резервная копия исходного состояния — это известная начальная конфигурация, предназначенная для отката. Изменение одного уровня не обновляет автоматически два других, поэтому администратор должен явно сохранять, восстанавливать и проверять каждый переход.
В этой лабораторной работе вы сохраните исходную конфигурацию брандмауэра как точку отката, добавите и сохраните узкое правило для службы, проверите файл перед применением, смоделируете перезагрузку набора правил и в конце восстановите исходное состояние. Такой процесс позволяет чётко разделять три состояния: работающие правила, сохранённый файл правил и резервную копию для отката.
Резервное копирование работающего IPv4-брандмауэра
На этом шаге вы сохраните исходное состояние брандмауэра до внесения изменений. Резервная копия позволит вернуться к заведомо рабочей конфигурации, если последующие команды поведут себя не так, как ожидалось.
Перейдите в каталог проекта.
cd /home/labex/project
Перед изменением правил убедитесь, что тестовая служба доступна.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Это контрольная проверка. Адрес 127.0.0.1 использует интерфейс loopback, параметр --noproxy '*' гарантирует локальное выполнение запроса даже при настроенных переменных прокси, а --fail --silent возвращает чистый результат и надёжный код завершения. Зафиксированное рабочее исходное состояние упростит интерпретацию дальнейшего поведения брандмауэра.
Используйте iptables-save, чтобы вывести полный набор правил IPv4. Конвейер передаёт этот вывод команде tee, которая записывает его в baseline.v4, сохраняя возможность запускать команду от имени обычного пользователя лаборатории.
sudo iptables-save | tee baseline.v4 >/dev/null
Разделение полномочий здесь сделано намеренно: sudo iptables-save считывает защищённый набор правил ядра, а tee без повышенных привилегий записывает файл в каталог проекта. Последнее перенаправление отправляет дубликат вывода tee с экрана в /dev/null; оно не очищает файл. Полученная резервная копия содержит все сериализованные таблицы и цепочки IPv4, обнаруженные на этом узле, а не только правило, которое вы добавите позже.
Просмотрите начало сохранённого файла.
head -n 12 baseline.v4
Точные значения счётчиков могут различаться, но файл использует формат iptables-restore, организованный по разделам таблиц. Минимальный раздел filter выглядит примерно так:
*filter
:INPUT ACCEPT ...
...
COMMIT
Каждый раздел начинается с имени таблицы, например *filter, затем объявляет цепочки и политики, содержит правила и завершается строкой COMMIT. iptables-restore применяет раздел таблицы только после достижения этого маркера. Не воспринимайте такой файл как произвольный список отдельных команд оболочки.
Убедитесь, что файл содержит маркер таблицы filter и маркер фиксации изменений.
grep -E '^\*filter$|^COMMIT$' baseline.v4
Добавление и сохранение правила службы
На этом шаге вы добавите в работающий брандмауэр явное разрешающее правило и сохраните полученный набор правил по стандартному пути хранения правил IPv4.
Вставьте в начало цепочки INPUT правило, разрешающее TCP-трафик через loopback-интерфейс к порту 18087. Ограничения по интерфейсу и порту делают правило специфичным для этой лабораторной работы.
sudo iptables -I INPUT 1 -i lo -p tcp --dport 18087 -j ACCEPT
Цепочка INPUT обрабатывает трафик, адресованный самому хосту. Параметр -I INPUT 1 помещает правило на первое место, -i lo ограничивает его интерфейсом loopback, -p tcp --dport 18087 выбирает тестовую службу, а -j ACCEPT разрешает соответствующий трафик. Явное правило с узкой областью действия проще проверять и удалять, чем широкое правило, разрешающее множество служб.
Проверьте наличие правила в работающей конфигурации. Нулевой код завершения означает, что точное условие и целевое действие существуют; реализация на основе nftables, используемая на этом хосте, также выводит нормализованное представление найденного правила.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Сохраните полный работающий набор правил IPv4. Команда sudo tee необходима, поскольку каталог /etc/iptables требует прав администратора на запись.
sudo iptables-save | sudo tee /etc/iptables/rules.v4 >/dev/null
Эта команда создаёт новый снимок после добавления правила. sudo требуется с обеих сторон конвейера, но по разным причинам: левая часть считывает состояние брандмауэра, а правая открывает файл назначения, принадлежащий root. Простое создание rules.v4 не активирует правила и не планирует их загрузку; оно лишь подготавливает файл, который впоследствии может использовать команда восстановления или служба, запускаемая при загрузке системы.
Найдите порт службы в сохранённом файле. Параметр -- после grep завершает разбор параметров, что полезно, если искомый шаблон может начинаться с дефиса.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
В выводе должна присутствовать строка правила INPUT, завершающаяся параметром -j ACCEPT. На этом этапе и работающий набор правил, и сохранённый файл содержат нужное правило.
Не сравнивайте новый файл с резервной копией побайтно. Счётчики пакетов и правила, поддерживаемые другим программным обеспечением, могут закономерно изменяться. В рамках этой работы важно подтвердить наличие нужного правила и в работающей конфигурации, и в сохранённом файле.
Проверка и восстановление сохранённого набора правил
На этом шаге вы удалите работающее правило, проверите сохранённый файл без его применения, а затем загрузите его обратно. Это моделирует важную часть восстановления правил при перезагрузке, не покидая текущего сеанса лаборатории.
Удалите правило из работающей цепочки INPUT.
sudo iptables -D INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Удаление изменяет только текущий набор правил ядра. Файл /etc/iptables/rules.v4 при этом не редактируется, поэтому сохранённое правило можно восстановить следующей командой. Это намеренное расхождение наглядно показывает разницу между работающим и сохранённым состоянием.
Убедитесь, что правило отсутствует. Проверка должна завершиться ошибкой, поэтому оператор || выводит сообщение и позволяет продолжить работу.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Live rule is absent"
Перед применением сохранённой конфигурации брандмауэра используйте iptables-restore --test. Эта команда разбирает весь файл и сообщает об ошибках синтаксиса, не заменяя работающий набор правил.
sudo iptables-restore --test < /etc/iptables/rules.v4
Оператор < передаёт файл в стандартный ввод iptables-restore. Отсутствие вывода означает, что синтаксис принят; это не означает, что файл уже применён. Проверка — важная мера безопасности, поскольку повреждённый или неполный набор правил после восстановления может нарушить сетевое подключение.
Успешная проверка завершается без вывода. Теперь восстановите сохранённые правила в работающем брандмауэре.
sudo iptables-restore < /etc/iptables/rules.v4
В отличие от добавления одного правила через iptables, команда iptables-restore обрабатывает все разделы таблиц, присутствующие в файле. Относитесь к ней как к административной операции с серьёзными последствиями: сначала проверяйте файл, храните резервную копию для отката и сразу после восстановления проверяйте критически важный доступ. В этой контролируемой лабораторной работе файл был создан на том же хосте всего несколько минут назад.
Проверьте, что правило службы появилось снова.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Убедитесь, что приложение остаётся доступным после восстановления.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Возврат к исходному состоянию
На этом шаге вы используете резервную копию из первого шага, чтобы удалить изменения лабораторной работы из работающего брандмауэра, сохранив целевой набор правил для последующего просмотра.
Проверьте исходную конфигурацию перед её применением.
sudo iptables-restore --test < baseline.v4
Файлы baseline.v4 и /etc/iptables/rules.v4 намеренно имеют разные назначения. Резервная копия описывает исходное работающее состояние, а rules.v4 — целевое состояние, содержащее правило службы. Восстановление одного файла не изменяет другой.
Восстановите исходный работающий набор правил.
sudo iptables-restore < baseline.v4
Убедитесь, что правило лабораторной работы больше не действует.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Original firewall baseline restored"
Сохранённый целевой файл является отдельным артефактом и по-прежнему содержит правило, восстановление которого вы отрабатывали.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
Эта проверка наиболее наглядно подтверждает разделение состояний: работающий брандмауэр возвращён к исходной конфигурации, но файл постоянного хранения по-прежнему содержит целевое правило. Администратор сможет восстановить его позднее или настроить службу, которая загрузит его при запуске системы.
В конце убедитесь, что после возврата к исходной разрешающей конфигурации локальная служба остаётся доступной.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
В рабочей среде обязательно выясните, какая служба загружает файл постоянного хранения дистрибутива при запуске. Например, в системах на базе Debian часто используются пакет iptables-persistent и служба netfilter-persistent, однако их наличие и политика настройки зависят от конкретного хоста. Сохранение корректного файла rules.v4 подготавливает набор правил; автоматически ли он будет восстановлен, определяет установленный и включённый загрузчик.
Итоги
Вы создали резервную копию работающего IPv4-брандмауэра, добавили и сохранили целевое правило службы, проверили сериализованный набор правил с помощью iptables-restore --test, загрузили его в ядро и вернулись к исходной конфигурации. Кроме того, вы научились различать работающий брандмауэр, файл постоянного хранения правил и резервную копию для отката — это важная привычка перед изменением или восстановлением состояния фильтрации пакетов.
