Проверка изменений межсетевого экрана без потери доступа
Расставьте пути восстановления по приоритету до применения правила, а затем проверяйте потоком, который должна оценить новая политика, а не сеансом, который уцелел.
Правило применяется, уже открытый терминал продолжает отвечать, а следующий вход отклоняется. Именно этот зазор и есть вся сложность проверки изменения межсетевого экрана через то соединение, которое вы меняете. Отслеживание соединений решает один раз и затем перестаёт смотреть, поэтому установившийся поток — единственная проверка, которая не может увидеть новую политику. Далее сравниваются три пути назад, а затем определяется порядок, в котором менять и проверять правила.
Почему уцелевший сеанс — самое слабое доказательство
Межсетевой экран с сохранением состояния оценивает первый пакет потока и держит этот вердикт, пока запись жива. Правила, добавленные позже, действуют на потоки, которые начинаются позже, поэтому окно, в котором вы печатаете, остаётся рабочим, а всех остальных отклоняют. То, что вы из него узнаёте, описывает политику, действовавшую несколько минут назад. Даже запись, снятая на этом потоке, показывает решение, которое машина уже приняла.
Относитесь к работающему сеансу как к аварийному выходу, а не как к измерению. Каждая осмысленная проверка должна открыть новый поток из источника, который оценит новое правило, и первой должна быть та проверка, провал которой будет больнее всего. Когда этот сеанс — единственный путь внутрь, изменение ещё не готово к применению.
Три пути назад, упорядоченные по тому, от чего зависит каждый
Упорядочьте варианты по тому, насколько они зависят от проверяемого устройства, потому что именно к этому порядку вы прибегаете, когда правило оказывается неверным. Консоль, которая никогда не проходит через межсетевой экран, независима, отработанный откат почти таков, а уже открытый сеанс — нет.
| Way back in | What it survives | Where it fails |
|---|---|---|
| out-of-band or hypervisor console | a policy that blocks new logins | needs separate access you have already tried |
| rollback rehearsed on that platform | a rule that breaks remote access | fails when nobody ever ran it |
| the session that is already open | the change itself | cannot show whether new flows work |
Перед изменением войдите через консоль и докажите, что она работает, потому что путь вне основного канала, которым вы никогда не пользовались, — это схема, а не запасной вариант. Откат заслуживает своего места только после тренировки на этой платформе, с этим набором правил, по утверждённой процедуре, а не импровизации на живой машине. Запишите шаги и попросите кого-нибудь другого прочитать их вслух. Если для завершения последовательности нужна ваша память, это не план.
Одно изменение, затем соединение, которое нужно оценить
Сохраните работающий набор правил и файл, который им владеет, а затем сделайте одну узкую правку. Одно изменение на проверку позволяет отнести результат на счёт конкретной правки; два сразу оставляют работающую машину и никакого понимания, какая правка сработала. Там, где платформа умеет разбирать конфигурацию без загрузки, сделайте это первым, чтобы опечатка выявилась, пока ничего не поставлено на карту.
nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.confЗатем начните новый сеанс из источника, которому будет соответствовать изменённое правило, пока консоль ещё подключена. Повторите один раз, если получилось, потому что первая попытка может попасть в запись, которая уже была в таблице. Если не получилось, у вас остаются путь внутрь и решение, которое можно отменить, и это самый дешёвый плохой исход из доступных.
Счётчики, состояние и файл отвечают на разные вопросы
Каждое из трёх наблюдений может по отдельности выглядеть убедительно и вводить в заблуждение насчёт двух других. Счётчики показывают, достиг ли только что созданный поток той правки, которую вы внесли. Таблица состояний показывает, какие потоки машина считает уже установленными, и именно так сломанное правило может выглядеть здоровым. Сохранённый файл показывает, что устройство сделает после следующей перезагрузки, и это может быть не то, что делает работающий набор правил сейчас.
ss -tn state establishedЧитайте счётчики как приращение, а не как сумму, потому что единственное важное число — то, которое сдвинул ваш тестовый поток. Правило, счётчик которого никогда не растёт, не совпадает, как бы верно оно ни выглядело на бумаге. Подтвердите и случай отказа: политика, которая ни разу ничего не отклонила, ни разу не доказала, что отклоняет то, что вы хотели заблокировать. Пройдите по одному интерфейсу в каждом семействе, которое развёртывание действительно несёт, потому что правило v4 ничего не говорит о потоке v6.
Восстановите из сохранённого набора правил, затем приведите файл в соответствие
Когда изменение не удалось, загрузите сохранённый набор правил вместо добавления разрешающих правил, пока входы не заработают снова. Каждое лишнее разрешение успокаивает симптом и оставляет дыру, которая переживёт инцидент и память о нём. Восстановите, переподключитесь, а затем держите неудачное сравнение рядом с записью о том, что вы пробовали.
После успешного изменения файл на диске должен описывать работающий набор правил, и подтвердите, что перезагрузка его воспроизводит. Работающий набор правил, ушедший от собственного файла конфигурации, — это ловушка, поставленная на следующую перезагрузку.