Ограничити OpenVPN пролаз на једну LAN правилима UFW-а

Одлучите дозволу пре него што отворите датотеку заштитног зида: аутентификовани клијенти смеју отварати везе ка једној одређеној подмрежи, а пролаз мора одбити сваки други транзитни пут чак и када клијент инсталира додатне руте. Та реченица је нацрт, и свако правило испод постоји да га спроведе. Нешто шире, попут целог приватног адресног простора, изласка на интернет кроз тунел или саобраћаја између равноправних рачунара, други је нацрт који тражи сопствену одлуку. Правила су и намерно досадна, јер је паметан заштитни зид онај који нико не може касније да ревидира.

Прво запишите топологију и дозволу

Пример користи Community OpenVPN сервер са TUN уређајем у корисничком простору названим tun0, базен клијената 10.77.0.0/24, и једну прикључену подмрежу 192.168.60.0/24 на lan0. IPv4 прослеђивање већ ради и LAN већ има повратну руту до базена, па ништа овде не зависи од превода између њих.

Заштитним зидом на овом хосту управља UFW, и ниједан скуп правила у контејнеру ни засебна nftables табела не сме поставити ранији пут прихватања. Пречица за растерећење тока која прескаче филтер учинила би заштитне ланце украснима, зато потврдите да ниједан није активан. Оставите сопствено прослеђивање client-to-client OpenVPN-а искљученим, јер се саобраћај између равноправних рачунара који никада не прелази филтер оперативног система не може њиме ограничити. Спољни слушалац и административна правила остају какви јесу, јер ова промена уређује дешифровани саобраћај тунела уместо да замењује заштитни зид.

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

Прочитајте шта свака заштита пропушта и одбија

Први ланац наставља обраду само када је извор у базену, одредиште је та једна подмрежа, излазно сучеље је LAN и пакет путује у изворном смеру свог тока. Све остало што долази из тунела одбацује се, укључујући извор изван базена и свако одредиште изван дозвољене подмреже.

Пакет између равноправних рачунара улази и излази кроз tun0, па пада на тесту сучеља LAN-а пре него што се уопште дође до провере одредишта. Нове везе са LAN-а према клијентима такође падају на тесту смера одговора, што по задатом затвара обрнути пут повратног позива.

Мета 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 слушалац везан за његову LAN адресу. Угошћивање DNS-а тамо тражи намерно изузеће пре одбацивања и ревидиран уговор о дозволи. Ако UFW управља IPv6, додајте одговарајућа одбацивања за tun0 у before6.rules такође, јер списак одредишта IPv4 не говори ништа о пакетима IPv6.

Проверите учитану политику, не преглед

Прегледајте поновно учитавање, примените га у прозору за одржавање и прочитајте живи скуп правила.

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

Потврдите да се заштите тунела појављују пре задатих дозвола за стање и ICMP. Обичан ufw status не приказује ручно уређена before правила, зато оператери закључе да правило недостаје када је оно заправо учитано. Читајте сирови списак одозго надоле уместо да тражите одломак. Ако се заштите појаве после дозволе за стање, граница не ради оно што датотека сугерише.

Затим тестирајте понашање, а не текст. Отворите нову везу ка дозвољеном хосту и посматрајте одговор, усмерите безопасан захтев ка одредишту изван подмреже и потврдите да умире, испробајте везу између равноправних рачунара, испробајте услугу локалну за пролаз и испробајте нежељену везу са LAN-а према клијенту. Укључите један ток изван опсега који је постојао пре промене и обришите само тај ток уместо да испразните целу табелу праћења машине.

Запишите ограничења уз правила: ово ограничава транзит и ништа друго. Не спречава клијента да користи сопствену интернет везу, не спречава дозвољени LAN хост да даље прослеђује саобраћај и не замењује аутентификацију унутар дозвољених услуга.