iptables: дайте на VPN клиентите достъп само до един хост

Правилото, което ви трябва, е във FORWARD, а не в INPUT. Разрешете една дестинация за VPN пула, отхвърлете останалите и след това го докажете с броячи и команда за връщане назад.

Две заявки в поддръжката, които изглеждат несвързани, се оказва, че имат една причина. В първата администратор иска сървърът да приема връзки само от тунела; във втората потребителите на VPN трябва да достигат един вътрешен хост и нищо повече. И двете политики принадлежат на FORWARD и обикновено се опитват в INPUT. Резултатът изглежда като защитна стена и се държи като запълващ елемент.

Коя верига отговаря на въпроса ви

Пакетите, които VPN клиент изпраща до хост в LAN или нататък към интернет, се препращат от ядрото и се оценяват във FORWARD. INPUT и OUTPUT виждат само трафик, който завършва на сървъра или произхожда от него. Затова отхвърлянето на всичко, което не пристига на tun0, защитава собствените слушатели на сървъра и също ще прекрати SSH сесията ви, освен ако установените потоци не бъдат допуснати първи. То не променя нищо относно това накъде могат да ходят клиентите.

Първо назовете въпроса: кой може да достига сървъра или накъде могат да ходят клиентите. Повечето мрежи се нуждаят от двата отговора, в различни вериги.

Първо състоянието, после разрешението, после отказът

Списък с разрешения работи само ако конкретното разрешение стои над общия отказ и ако обратният трафик е разрешен над двете. Вмъкнете правилата на явни позиции, след което изведете веригата с iptables -S FORWARD, така че редът да е видим, а не предполагаем.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Два детайла решават дали това ще устои при сблъсък с реален трафик. Без правилото за състоянието отговорите на връзките, които току-що разрешихте, сами се оценяват срещу отказа и се изхвърлят. Правило LOG без ограничение може да изчерпи малък дял при първото сканиране, затова добавете -m limit --limit 10/min, преди да продължите да логвате. REJECT връща грешка веднага, което е по-дружелюбно, докато настройвате списъка; DROP изхвърля безшумно, така че всяка грешка изглежда като изтичане на времето. Изберете едно нарочно и запишете избора в записа за промяната.

Препращането и NAT трябва вече да работят

Филтрирането не може да докаже, че път съществува. Първо потвърдете, че ядрото изобщо препраща, и направете тази настройка постоянна, а не еднократна команда в обвивката. Филтърът е последният слой, не първият.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Къде принадлежи маскарадът зависи от това откъде излизат клиентите. Ако излизат през тунела към отдалечена мрежа, NAT правилото отива на този интерфейс, а не на WAN интерфейса. След това наблюдавайте броячите: ако броячът на POSTROUTING никога не се движи, докато броят на приетите във FORWARD расте, обратният път е счупен и филтърът е наред. Това четене спестява следобед преписване на правила, които никога не са били проблемът.

Блокът за поща принадлежи една верига по-нагоре

Блокирането на порт 25 в INPUT спира само пощата, адресирана до VPN сървъра. Компрометиран клиент, който изпраща поща през тунела, се препраща, затова блокът трябва да е във FORWARD до 465 и 587. Ако едно приложение законно препраща поща, поставете неговата дестинация и порт над това правило.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

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

Прочетете го обратно, после го докажете от клиент

Четете набора от правила така, както ядрото го отчита, а не както го е написал скриптът ви. Започнете с iptables -S FORWARD, после таблицата NAT с iptables -t nat -L POSTROUTING -n -v, после записа в conntrack за потока, който проверявате. Пазете команда за връщане назад или планирано изчистване, докато работата продължава. Всяко извикване се нуждае от -w, иначе двама администратори ще се сблъскат на ключалката на xtables. Нищо от това не е по избор в прозорец за промяна.

Завършете с тест от клиент вътре в пула и от такъв извън него. Правило, което работи само от машината, на която сте го набрали, не е политика.

Подобни статии