Блокирајте еден опсег на дестинација за секој VPN клиентски базен

Едно правило може да го држи дозволениот VPN базен подалеку од опсег на дестинација, без да вознемири нешто друго што го прави портата. Самото правило е кратко; деловите што одлучуваат дали работи се куката во која живее и нејзината позиција во синџирот. Ако згрешите во тие две, добивате огнен ѕид што изгледа исправно и се однесува неконзистентно. Започнете од тоа што го прави пакетот кога правилото го гледа.

Што всушност споредува правилото

Правилото споредува три работи истовремено: влезен интерфејс, префикс на извор и префикс на дестинација. Сите три мора да бидат точни пред да се примени drop, и тоа го држи тесно. Да се чита како еден израз е полесно отколку како три одделни политики.

Споредувањето на интерфејсот е она што го разликува проследениот клиентски сообраќај од сопствените врски на портата. Без него, правило што го наведува само изворниот базен би влијаело и на пакетите што самата порта ги создава од таа адреса, ако тоа некогаш се случи. Префиксот на извор ја ограничува политиката на дозволени клиенти, а префиксот на дестинација на еден опсег. Читајте го правилото како пресек, а не како список.

Запишете ги трите вредности пред да промените нешто: името на тунелскиот интерфејс, базенот што го дели серверот и префиксот што имате намера да го одбиете. Печатна грешка во која било од нив дава правило што се парсира чисто и не штити ништо. Чувајте ги тие три вредности во записот за промената покрај правилото.

Куката одлучува на кого се применува правилото

netfilter синџирот е прикачен на кука, и куката одлучува кои пакети воопшто ги гледа синџирот. Куката forward гледа сообраќај што се рутира низ портата, а тоа е сообраќајот од клиент до дестинација. Сè друго во синџирот е насочено кон друга публика.

Куката input гледа сообраќај адресиран до самата порта, па правило поставено таму управува со пристапот до нејзините сопствени услуги, а не со транзитот. Куката output гледа сообраќај што портата сама го создава, што е спротивно од она што му е потребно на политика за клиентски базен. Имињата на синџирите се произволни ознаки избрани од тој што го напишал множеството правила, затоа не ја изведувајте куката од името. Проверете каде е прикачен синџирот пред да претпоставите што може да спореди.

Читањето на прикачувањето е проверка во еден ред што спречува правило да слета во синџир што никогаш не го гледа пакетот.

Поставете го правилото пред широкиот accept

Правилата се оценуваат по ред и првата пресуда победува. Широк accept порано во синџирот ја завршува оценката за пакетите што ги споредува, така што drop додаден подоцна никогаш не се извршува за нив. Тоа правило за редот е целата причина зошто исправно изгледачко правило може да нема ефект.

Вметнете го правилото пред accept наместо да го додадете на крајот. Ако синџирот веќе содржи општ accept за тунелскиот интерфејс, новото правило мора да биде пред него, инаку е само украс. Проверете го добиениот ред, а не датотеката што ја уредивте, бидејќи множество правила составено од неколку датотеки може да не одговара на ниту една од нив. Потоа потврдете со тест пакет од базенот.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

Третата команда ја парсира датотеката без да ја примени, што ги фаќа синтаксичките грешки пред да станат прекин. Применете со план за враќање, бидејќи погрешно правило во forward синџир може да го пресече тунелот преку кој работите.

Постојните текови не се грижат за вашето ново правило

conntrack запис создаден пред правилото да постои продолжува да одговара на претходниот accept. Затоа новиот drop понекогаш изгледа дека работи за свежи врски и не прави ништо за таа што се тестира.

Прочитајте го споредувањето на состојбата на врвот на синџирот. Ако прима established и related сообраќај пред вашето правило, секој тек што е веќе во тек продолжува да тече додека не се затвори. Обично тоа е однесувањето што го сакате за итно правило, и збунува кога очекувате моментално прекинување. Одлучете каков ефект сакате пред да го распоредите. Тест што повторно користи отворена врска ќе ви раскаже погрешна приказна.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

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

Што не е ова правило

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

Секое од нив бара свој механизам. Блокирањето домен мора да решава имиња, што филтерот на пакети не го прави. IPv6 сообраќајот бара свое споредување, бидејќи изразот ip не кажува ништо за ip6 пакетите. Ограничувањето на ниво на апликација и припаѓа на услугата или на автентифициран прокси, а не на споредување на префикс. Токму одвојувањето на тие барања спречува од едно тесно правило да се бараат четири работи.

Договорот што го дава ова правило е прецизен: сообраќајот од дозволен базен кон еден префикс на дестинација се одбива, додека неповрзаниот сообраќај на портата ја задржува својата постојна политика. Напишете ја таа реченица покрај правилото и следниот човек ќе знае за што било.