iptables: дазволіць кліентам VPN даходзіць толькі да аднаго хаста

Два звароты ў падтрымку, якія выглядаюць незвязанымі, маюць адну прычыну. У першым адміністратар хоча, каб сервер прымаў злучэнні толькі з тунэля; у другім карыстальнікі VPN павінны дасягаць аднаго ўнутранага хаста і нічога больш. Абедзве палітыкі належаць FORWARD, і абедзве звычайна спрабуюць рэалізаваць у INPUT. Вынік выглядае як файрвол, а паводзіць сябе як заглушка.

Які ланцуг адказвае на ваша пытанне

Пакеты, якія кліент VPN дасылае хасту ў LAN або далей у інтэрнэт, перасылаюцца ядром і ацэньваюцца ў FORWARD. INPUT і OUTPUT бачаць толькі трафік, які завяршаецца на серверы або паходзіць з яго. Таму адхіленне ўсяго, што не прыходзіць на tun0, абараняе ўласныя слухачы сервера і таксама абарве ваш сеанс SSH, калі спачатку не дазволіць усталяваныя патоку. Гэта ніяк не змяняе таго, куды кліентам дазволена хадзіць.

Спачатку назвіце пытанне: хто можа дасягаць сервера або куды могуць ісці кліенты. Большасці сетак патрэбныя абодва адказы, у розных ланцугах.

Спачатку стан, потым дазвол, потым адмова

Спіс дазволаў працуе, толькі калі канкрэтны дазвол стаіць вышэй за агульную адмову і калі зваротны трафік дазволены вышэй за абодва. Устаўце правілы на яўныя пазіцыі, затым выведзіце ланцуг праз iptables -S FORWARD, каб парадак быў бачны, а не меркаваны.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Дзве дэталі вырашаюць, ці вытрымае гэта сутыкненне з рэальным трафікам. Без правіла стану адказы на злучэнні, якія вы толькі што дазволілі, самі ацэньваюцца супраць адмовы і адкідаюцца. Правіла LOG без абмежавання можа вычарпаць невялікі раздзел пры першым жа сканаванні, таму дадайце -m limit --limit 10/min, перш чым працягваць лагаванне. REJECT вяртае памылку адразу, што зручней, пакуль вы наладжваеце спіс; DROP адкідае маўкліва, таму кожная памылка выглядае як тайм-аўт. Выберыце адзін свядома і запішыце выбар у запіс пра змену.

Перасылка і NAT павінны ўжо працаваць

Фільтраванне не можа даказаць, што шлях існуе. Спачатку пераканайцеся, што ядро наогул перасылае, і зрабіце гэту наладу пастаяннай, а не разавай камандай у абалонцы. Фільтр — апошні слой, а не першы.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Месца маскарада залежыць ад таго, адкуль выходзяць кліенты. Калі яны выходзяць праз тунэль у аддаленую сетку, правіла NAT ставіцца на гэтым інтэрфейсе, а не на WAN. Затым сачыце за лічыльнікамі: калі лічыльнік POSTROUTING не рухаецца, а колькасць дазволаў FORWARD расце, зваротны шлях зламаны, а фільтр у парадку. Такое чытанне эканоміць паўдня на перапісванне правілаў, якія ніколі не былі праблемай.

Блок пошты належыць на адзін ланцуг вышэй

Блакаванне порта 25 у INPUT спыняе толькі пошту, адрасаваную серверу VPN. Скампраметаваны кліент, які адпраўляе пошту праз тунэль, перасылаецца, таму блок павінен стаяць у FORWARD побач з 465 і 587. Калі адна праграма законна рэтранслюе пошту, змясціце яе прызначэнне і порт вышэй за гэтае правіла.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Дайце лічыльніку адмоў працаваць тыдзень, перш чым што-небудзь яшчэ ўшчыльняць. Лік, які перастае расці, — гэта законны паток, які вы толькі што зламалі.

Прачытайце назад, затым дакажыце з кліента

Чытайце набор правілаў так, як яго паведамляе ядро, а не так, як яго напісаў ваш скрыпт. Пачніце з iptables -S FORWARD, затым табліца NAT праз iptables -t nat -L POSTROUTING -n -v, затым запіс conntrack для патоку, які вы правяраеце. Трымайце каманду адкату або запланаваную ачыстку, пакуль праца не завершыцца. Кожны выклік патрабуе -w, інакш два адміністратары сутыкнуцца на замку xtables. Нішто з гэтага не з’яўляецца неабавязковым у акне зменаў.

Скончыце тэстам з кліента ўнутры пула і з кліента па-за ім. Правіла, якое працуе толькі з машыны, на якой вы яго набралі, — не палітыка.