Дзе 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 і палітыку доступу асобна

Трансляцыя крыніц вырашае праблему адрасацыі і нічога не дае. Перанакіраванне — асобнае дазвол, якое кіруецца сістэмным параметрам і табліцай фільтра, і менавіта пра яго забываюць, калі тунель маршрутызуе, але не прапускае трафік. Палітыка доступу — трэцяе рашэнне пра тое, якія крыніцы могуць дасягаць якіх службаў, і ні адно правіла 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, таму ўкажыце меркаванае пакрыццё для абодвух сямействаў у той жа нататцы, што і правіла. Мэта — узгодненая кіраваная палітыка, а фрагмент, які выпадкова разьбярэцца, не з'яўляецца доказам яе наяўнасці.

Падобныя артыкулы