Ограничете шлюз на OpenVPN до една локална мрежа с правила на UFW

Решете разрешението, преди да отворите файл на защитната стена: удостоверените клиенти могат да отварят връзки към една конкретна подмрежа, а шлюзът трябва да отказва всеки друг транзитен път, дори когато клиент добави допълнителни маршрути. Това изречение е проектът и всяко правило по-долу съществува, за да го наложи. Нещо по-широко, например цялото частно адресно пространство, изход към интернет през тунела или равноправен трафик, е различен проект, който изисква собствено решение. Правилата са и умишлено скучни, защото умната защитна стена е тази, която никой не може да одитира по-късно.

Първо запишете топологията и разрешението

Примерът използва сървър Community OpenVPN с TUN устройство в потребителско пространство, наречено tun0, пул от клиенти 10.77.0.0/24, и една свързана подмрежа 192.168.60.0/24 на lan0. Препращането на IPv4 вече работи и локалната мрежа вече има обратен маршрут към пула, така че нищо тук не зависи от транслация между тях.

Защитната стена на този хост се управлява от 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. Поставянето на втора филтърна таблица или изтриването на несвързани правила е начинът, по който промяна на защитната стена се превръща в прекъсване, а файлът е на едно рестартиране от това да стане единственото копие, което има значение.

Прочетете какво допуска и отказва всяка защита

Първата верига продължава обработката само когато източникът е в пула, дестинацията е единствената подмрежа, изходният интерфейс е локалната мрежа и пакетът пътува в първоначалната посока на своя поток. Всичко останало, пристигащо от тунела, се отхвърля, включително източник извън пула и всяка дестинация отвъд разрешената подмрежа.

Равноправен пакет влиза и излиза през 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, поради което операторите заключават, че правило липсва, когато то всъщност е заредено. Четете суровия списък отгоре надолу, вместо да търсите фрагмент. Ако защитите се появят след разрешение за състояние, границата не прави това, което файлът подсказва.

След това тествайте поведение, а не текст. Отворете нова връзка към разрешен хост и наблюдавайте отговора, насочете безвредна заявка към дестинация извън подмрежата и потвърдете, че умира, опитайте равноправна връзка, опитайте услуга, локална за шлюза, и опитайте непоискана връзка от локалната мрежа към клиент. Включете един поток извън обхвата, който е съществувал преди промяната, и изчистете само този поток, вместо да изчиствате цялата таблица за проследяване на машината.

Запишете ограниченията до правилата: това ограничава транзита и нищо друго. Не спира клиент да използва собствената си интернет връзка, не спира разрешен хост в локалната мрежа да препраща трафик нататък и не заменя удостоверяването вътре в разрешените услуги.