Къде се поставя NAT за VPN в before.rules на 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, затова посочете предвиденото покритие за двете семейства в същата бележка като правилото. Целта е последователна управлявана политика, а фрагмент, който случайно се е анализирал, не е доказателство за нея.