Где припада VPN NAT у 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 зависи, да дозвољава само предвиђене изворе или да даљинска администрација остаје доступна. То су одвојене рецензије, а последња заслужује другу сесију отворену пре почетка.

Изаберите алат који одговара инсталираном backend-у и породици адреса. Домаћин који покреће nft backend кроз слој компатибилности захтева одговарајућу команду, а 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 укључен јесте политика са неизреченом зависношћу. После тога учитајте још једном да докажете да радни резултат даје датотека, а не некакво преостало стање извршавања.

IPv4 NAT не говори ништа о IPv6, зато наведите предвиђено покривање за обе породице у истој напомени као правило. Циљ је кожерентна управљана политика, а фрагмент који се случајно анализирао није њен доказ.