Ограничете OpenVPN порта на една LAN со правила на UFW

Дозволете на клиентите на тунелот да достигнат една подмрежа и ништо друго. Стражи во синџири пред раните прифаќања на 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 домаќин да препраќа сообраќај понатаму, и не ја заменува автентикацијата внатре во дозволените услуги.

Поврзани статии