Де місце 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, тож укажіть передбачене покриття для обох родин у тій самій нотатці, що й правило. Мета — узгоджена керована політика, а фрагмент, який випадково розібрався, не є її доказом.

Схожі статті