Где место NAT для VPN в before.rules UFW и как это проверить

Строка NAT в before.rules должна находиться внутри допустимого раздела таблицы с COMMIT. Проверьте кандидат с помощью iptables-restore --test, прежде чем перезагружать UFW.

Правило NAT, которое работает при вводе в оболочке, ломается при вставке в before.rules, потому что этот файл не скрипт. Это документ в формате восстановления с разделами таблиц, объявлениями цепочек и маркером COMMIT для каждой таблицы. Строка не на месте либо прерывает всё восстановление, либо молча отбрасывает правила, которые вы считали существующими. Приведённая ниже инструкция ставит фрагмент туда, где его ждёт каркас, и доказывает результат до следующей перезагрузки.

Команда оболочки — не файл восстановления

Строка, начинающаяся с iptables -t nat, — это инструкция для бинарника iptables, тогда как файл, который читает UFW, — описание полного набора правил. Разница не косметическая: формат восстановления должен знать, в какой таблице он находится, какие цепочки существуют и где таблица заканчивается. Команда, вставленная в этот документ, — либо синтаксическая ошибка, либо, что хуже, правило, привязанное не к той таблице. Каркас загружает эти файлы через инструменты восстановления именно потому, что они декларативны, а не последовательны.

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

Поместите фрагмент в существующий раздел таблицы

Фрагмент NAT имеет форму, и форма важнее текста правила внутри него. Заголовок таблицы открывает раздел, объявления цепочек устанавливают счётчики, далее идут правила, а COMMIT закрывает раздел.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Пул и интерфейс выше — это заменители ваших значений; копировать стоит именно структуру. Если файл уже содержит раздел *nat, добавьте правило внутрь этого раздела, а не открывайте второй, потому что формат ожидает один COMMIT на таблицу, а два раздела для одной таблицы — это ремонт, ожидающий своего часа. Сохраните определения цепочек дистрибутива нетронутыми, включая те, что поставщик добавил для своей интеграции. Руководство по каркасу UFW описывает файлы before, user и after вместе с требованием соответствующего COMMIT.

Если файл окажется пустым, не заполняйте его по руководству. Уточните, какому пакету он принадлежит и какова реальная действующая политика, потому что пустой постоянный файл не доказывает, что в ядре нет правил, а загруженный набор правил не доказывает, что при следующей перезагрузке будет полный файл для чтения. Сначала восстановите поддерживаемую базовую линию, затем повторно примените поверх неё изменения площадки.

Проверьте кандидат, не применяя его

Инструмент восстановления может разобрать и построить набор правил, не применяя его, и это самый дешёвый доступный тест. Запустите его на защищённой копии, а не на рабочем файле, и читайте текст ошибки, а не только код выхода. Сбой разбора называет строку и обычно таблицу, а это больше, чем скажет неудачная перезагрузка.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Прохождение этой проверки доказывает, что документ разбирается, и ничего больше. Оно не доказывает, что кандидат по-прежнему содержит каждую цепочку, от которой зависит UFW, что он разрешает только задуманные источники или что удалённое администрирование остаётся доступным. Это отдельные проверки, и последняя заслуживает второй сессии, открытой до начала работы.

Выберите инструмент, соответствующий установленному бэкенду и семейству адресов. Хост, запускающий бэкенд nft через слой совместимости, нуждается в соответствующей команде, а правила IPv6 живут в совершенно другом файле.

Держите пересылку, NAT и политику доступа отдельно

Трансляция источника решает проблему адресации и ничего не даёт. Пересылка — отдельное разрешение, управляемое sysctl и таблицей фильтра, и именно о нём забывают, когда туннель маршрутизирует, но не пропускает трафик. Политика доступа — третье решение о том, какие источники могут достигать каких служб, и ни одно правило NAT её не выражает. Именно разделение этих трёх делает сбой диагностируемым, а не единым расплывчатым симптомом.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Читайте эти три вывода вместе, а не по одному. Правило masquerade с отключённой пересылкой создаёт клиента, который подключается и никуда не попадает, что со стороны клиента выглядит точно как сбой маршрутизации и отправляет людей к неверному файлу. Таблица фильтра — ещё и место, где прячется слишком широкий accept, поэтому проверьте там и её политику по умолчанию.

Проверьте перезагрузку, отказ и потерю VPN

Три наблюдения составляют полный приёмочный тест: перезагрузка удаётся, разрешённая операция клиента работает, а запрос, который должен быть отклонён, действительно отклоняется. Именно третий пропускают, и это единственное доказательство того, что политика вообще что-то делает.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Затем проверьте отказ, для которого вы проектировали. Уроните туннель и посмотрите, что делает хост, потому что политика, работающая только пока включён VPN, — это политика с неоговорённой зависимостью. После этого перезагрузите ещё раз, чтобы доказать, что работающий результат даёт файл, а не какое-то оставшееся состояние выполнения.

NAT для IPv4 ничего не говорит об IPv6, поэтому укажите предполагаемое покрытие для обоих семейств в той же заметке, что и правило. Цель — согласованная управляемая политика, а фрагмент, который случайно разобрался, не является её доказательством.

Похожие статьи