Абмежаваць шлюз OpenVPN адной лакальнай сеткай з дапамогай правілаў UFW

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

Спачатку запішыце тапалогію і дазвол

Прыклад выкарыстоўвае сервер Community OpenVPN з прыладай TUN у прасторы карыстальніка пад назвай tun0, пул кліентаў 10.77.0.0/24, і адну далучаную падсетку 192.168.60.0/24 на lan0. Перасылка IPv4 ужо працуе, і лакальная сетка ўжо мае зваротны маршрут да пула, таму нішто тут не залежыць ад трансляцыі паміж імі.

Міжсеткавы экран на гэтым хасте належыць UFW, і ні набор правілаў кантэйнера, ні асобная табліца nftables не могуць усталяваць ранейшы шлях прыняцця. Кароткі шлях праз разгрузку патоку, які абыходзіць фільтр, зрабіў бы ланцугі аховы дэкаратыўнымі, таму пераканайцеся, што ніводзін не актыўны. Пакіньце ўласную перасылку OpenVPN client-to-client адключанай, бо аднарангавы трафік, які ніколі не перасякае фільтр аперацыйнай сістэмы не можа быць абмежаваны ёю. Знешні слухач і правілы адміністравання застаюцца як ёсць, бо гэта змена кіруе расшыфраваным трафікам тунеля, а не замяняе міжсеткавы экран.

Размясціце ахову перад раннімі прыняццямі UFW

Дазволу маршруту з наступнай адмовай недастаткова для строгай мяжы. Стандартныя правілы before прымаюць усталяваны трафік і асобныя ICMP да таго, як будзе разгледжана любое карыстальніцкае правіла, таму паток, дазволены на прошлым тыдні, можа застацца па-за новым абмежаваннем прызначэння толькі таму, што ў яго яшчэ ёсць стан. Зрабіце рэзервовую копію файлаў UFW і трымайце па-запалосную кансоль адкрытай перад рэдагаваннем.

У раздзеле *filter файла /etc/ufw/before.rules аб'явіце два ланцугі побач з існуючымі аб'явамі і перад любым радком правіла.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

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

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

Прачытайце, што кожны ахоўны ланцуг прымае і адхіляе

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

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

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

Дазвольце падсетку і зачыніце бакавыя дзверы

Спачатку папярэдне прагледзьце дазвол маршруту, потым зніміце сцяжок папярэдняга прагляду, каб ужыць яго: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Пасля гэтага праглядзіце парадак карыстальніцкіх правілаў, бо ранейшая адмова ўсё яшчэ перамагае позняе прыняцце. Дазвол на ўсю падсетку таксама няправільная форма, калі павінен быць дасяжны толькі HTTPS-порт аднаго хаста.

Звярніце ўвагу, што робіць скід уваходу: кліенты тунеля не могуць дасягнуць ніводнай паслугі на самім шлюзе, уключаючы слухач DNS, прывязаны да яго адраса ў лакальнай сетцы. Размяшчэнне DNS там патрабуе наўмыснага выключэння перад скідам і перагледжанага кантракта дазволу. Калі UFW кіруе IPv6, дадайце адпаведныя скіды для tun0 у before6.rules таксама, бо спіс прызначэнняў IPv4 нічога не кажа пра пакеты IPv6.

Праверце загружаную палітыку, а не папярэдні прагляд

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

sudo ufw --dry-run reload
sudo ufw show raw

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

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

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