Пакет брандмауера встановлено, правила зникли після перезавантаження

Пакет встановився чисто, правила протестовано, а після наступного перезавантаження шлюз був повністю відкритий. Ніщо в транзакції не зазнало невдачі; невдачею було те, що вважалося постійним. Встановлення інструментів брандмауера, рішення, які правила мають пережити, і їх відновлення в потрібний момент це три окремі завдання.

Що насправді говорить вам симптом

Набір правил, який зникає під час перезавантаження, має одного з трьох власників: ніхто його не зберіг, щось інше його замінило, або його відновлено раніше, ніж з'явилося те, від чого він залежить. Перші два видно в конфігурації; третій проявляється лише в порядку. Саме тому перезавантаження може виглядати як втрата даних, хоча насправді це проблема послідовності.

Почніть із запису того, що було істинним до перезавантаження: яка служба тримала правила, який файл або базу вона читала під час запуску і чи це джерело колись записувалося. Живий набір правил, який ніхто не зберіг, це слушне пояснення і найпоширеніше.

Не починайте з перевстановлення пакета.

Прочитайте інструмент збереження перед використанням

Інструменти Debian розглядають постійність як проблему плагінів: кожен плагін знає, як записати власні правила, і один обгортковий скрипт їх викликає. Його дія збереження записує все, що завантажено в цей момент, а дія запуску знову завантажує цей знімок. Жодна з дій не переглядає, що саме вона зберігає.

Це знімок, а не перевірка. Забутий дозвіл із сеансу налагодження, незавершений експеримент або поблажливе правило, вставлене іншим помічником, усе це назавжди стає частиною політики, яку ви хотіли зберегти. Збереження стану й затвердження стану це різні дії, і лише одна з них потребує судження. Спершу прочитайте завантажений набір, а потім вирішуйте, які рядки варті того, щоб пережити.

Зберігайте усвідомлено, після прочитання того, що завантажено.

Вирішіть, що має пережити

Деякі правила належать до життєвого циклу інтерфейсу і мають зникати разом із ним. Інші мусять пережити тунель, і найясніший приклад це обмеження, яке забороняє трафіку клієнтів повертатися на фізичний інтерфейс, коли тунель падає. Ці дві категорії потребують різних тригерів відновлення, а не одного спільного знімка.

Запишіть бажаний результат для трьох моментів: запуск, активація VPN і втрата тунелю. Потім перевірте, чи обраний інструмент може виразити кожен із них. Пакет збереження, що перезавантажує статичний знімок, дає раду першому і, можливо, жодному з решти, бо знімок не знає, коли змінився стан тунелю. Якщо він не може їх виразити, прогалина належить іншому компоненту.

Відповідь визначає політика, а не пакет.

Перевірте порядок відновлення

Відновити файл це не те саме, що володіти результатом. Інший менеджер може замінити правила, попередній accept може їх затінити, або клієнти можуть почати надсилати раніше, ніж обмеження набуде чинності. Перегляньте поведінку під час запуску та повторного підключення, а не лише наявність збереженого файлу.

systemctl status netfilter-persistent
iptables -S

Не припускайте, що зупинка служби збереження нешкідлива, бо пакет документує умовне очищення під час зупинки. Встановіть фактичну конфігурацію служби, перш ніж використовувати stop або restart як експеримент на шлюзі, яким керуєте віддалено. Консольний сеанс і задокументоване відкочення це мінімум перед таким тестом.

Порядок це властивість працюючої системи, а не файлу на диску.

Прийміть три окремі результати

Запишіть встановлення пакета, завантажений набір правил і застосовану політику як окремі факти. Назва пакета в темі підтримки відповідає лише на перше, і саме воно рідко має значення.

nft list ruleset

Потім перевірте дозволену операцію й обов'язкову відмову.

Якщо відмова тримається після перезавантаження і після падіння тунелю, політика пережила. Якщо вона тримається лише в одному з цих станів, ви знайшли проблему порядку, а не виправили її.