Чаму nftables не бачыць трафік OpenVPN паміж кліентамі

Два кліенты на адным серверы абменьваюцца файламі, перадача ўдаецца, і кожнае правіла перасылкі, якое вы скіроўваеце на тунель, паведамляе пра нуль пакетаў. Правілы не зламаныя, і ланцуг не змешчаны. Калі перасылка паміж аднарангавымі вузламі ўключана, пакет перадаецца ўнутры працэсу сервера, а стэк хоста не робіцца маршрутызатарам, таму брандмаўэру ядра няма чаго лічыць. Разуменне гэтага падзелу вырашае, ці пакінеце вы кароткі шлях, ці перабудуеце шлях праз ядро.

Прасочыце адзін пакет праз сервер

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

Кароткі шлях прыбірае хост з сярэдзіны. Расшыфраваны пакет аднаго сеансу перадаецца іншаму сеансу ўнутры дэмана, і ўнутраны пакет ніколі не выпускаецца на прыладу тунелю і не маршрутызуецца хостам. Інкапсуляваны трафік па-ранейшаму перасякае фізічны інтэрфейс, таму знешні захоп выглядае занятым, пакуль унутраныя правілы маўчаць. Захоп, зроблены на прыладзе тунелю, не паказвае наогул нічога, што здзіўляе ўсяго, хто чакае ўбачыць перадачу там. Гэтая асіметрыя — самы хуткі спосаб пазнаць кароткі шлях знешне ад дэмана.

Тэст лічыльнікам, які вырашае, які шлях быў

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

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Калі перадача ўдаецца, а лічыльнік застаецца на нулі, ядро ніколі не апрацоўвала гэтыя пакеты, і ніякае рэдагаванне правілаў гэтага не зменіць. Паўтарыце той жа тэст супраць службы на самім серверы, бо гэты паток сапраўды перасякае стэк хоста і яго лічыльнік рухаецца. Менавіта параўнанне двух вынікаў дае адказ.

Дзве дэталі прадухіляюць памылковае чытанне. Назва інтэрфейса, запісаная ў этыкетцы ланцуга, сама па сабе нічога не фільтруе, бо супадзенне адбываецца па палях інтэрфейса ўнутры правілаў. А маставая схема 2-га ўзроўню паводзіць сябе яшчэ інакш: там кліенты дзеляць адзін шырокавяшчальны дамен, таму выяўленне аднарангавых вузлоў чакаецца, а не памылка маршрутызацыі.

Камутатар — гэта не спіс доступу

Гэта тая частка, якая каштуе паўдня. Перасылка паміж аднарангавымі вузламі — адна налада ўключыць або выключыць, і пакуль яна ўключана, дэман з'яўляецца адзіным пунктам перасылкі. Брандмаўэр хоста не можа выразіць, каму да каго можна дабрацца, а файлы па кожным кліенце не ператвараюць камутатар у матрыцу палітык.

Калі вам патрэбны правілы па кожным вузле, выбар паміж адмовай ад кароткага шляху і адмовай ад брандмаўэра хоста як сродку кантролю. Выключэнне аднаўляе перасылку праз ядро, што патрабуе ўключэння перасылкі IP на серверы і яўных правілаў для патрэбных патокаў. Калі пакінуць уключаным, палітыка жыве ў канфігурацыі дэмана, а гэта на практыцы або ўсе вузлы, або ніводнага.

Асобныя працэсы сервера з уласнымі пуламі адрасоў і партамі — гэта працаздольная сярэдзіна. Кожны працэс нясе роўна адно рашэнне аб доступе, таму дзве групы могуць мець розныя правілы без матрыцы палітык. Хост можа маршрутызаваць паміж пуламі, калі гэта задумана, і тады брандмаўэр бачыць гэтыя патокі, бо яны перасякаюць хост. Кошт — дадатковыя парты, дадатковыя сертыфікаты і профіль на кожную групу.

Выбар пункта перасылкі

Выбірайце перасылку праз ядро, калі брандмаўэр з'яўляецца рухавіком палітыкі, калі патрэбна журналізацыя па кожным патоку або калі важны ўлік. Кошт — прапускная здольнасць праз стэк хоста і больш правілаў для падтрымкі. Перавага ў тым, што кожны існуючы інструмент, ад лічыльнікаў да экспарцёраў патокаў, зноў апісвае трафік. На невялікім серверы гэты кошт незаўважны; на занятым рэле — не.

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

Што б вы ні выбралі, запішыце гэта побач з правіламі брандмаўэра. Набор правілаў, які выглядае так, нібы дазваляе трафік паміж вузламі, пакуль дэман усё роўна вырашае сам, уводзіць у зман наступнага чалавека, які будзе адладжваць няўдалую перадачу. Кожны, хто чытае толькі правілы, будзе меркаваць, што брама — гэта ядро.

Што праверыць перад зменай правілаў

Чытайце канфігурацыю, якую сервер сапраўды загрузіў, а не файл, які вы памятаеце рэдагаваным, і пацвердзіце, ці прысутнічае опцыя вузлоў. Калі вы яе змянілі, пераканайцеся, што служба перазагрузілася, а не проста перазапісала файл на дыску.

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