iptables хост само с VPN: назовете устройството tun, а не tun+

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

Стъпка 1: запишете правилата, които имате сега

Преди да промените политика по подразбиране, запазете текущото състояние, така че връщането да е команда, а не спомен. iptables-save > /root/iptables.pre записва всяка таблица във файл, който можете да възстановите, а втори терминал с отворена root сесия не е параноя, когато политиката, която ще зададете, прекъсне връзката, която я носи. Ако работите отдалечено, планирайте и flush като авариен превключвател.

След това избройте интерфейсите, защото име, което сте предположили, е име, което е трябвало да прочетете: ip -br link показва какво съществува точно сега, а тунелът няма да се появи, докато не е вдигнат. Записвайте имената на устройствата, докато ги четете.

Стъпка 2: дайте на тунела собствено име

OpenVPN приема dev tun_work в клиентската конфигурация и тогава Linux създава интерфейс точно с това име, вместо да разпределя tun0. Името остава стабилно между повторните свързвания, докато нищо друго не го заявява, и точно това прави правилото, което назовава устройството, смислено.

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

Стъпка 3: напишете политиката с изключението за endpoint първо

Хост само с VPN е хост със забрана по подразбиране и кратък списък с изключения, а изключението, което е най-важно, е това, което позволява на тунела да съществува. Изградете го в този ред, с правилото за endpoint преди правилото за устройството на тунела, за да има къде да отиде ръкостискането:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Буквалният адрес на endpoint и портът принадлежат на вашия доставчик, не на тази страница. Ако endpoint е име на хост, разрешете го веднъж и фиксирайте резултата, защото правилото не може да търси име, а променящият се отговор ще счупи политиката тихо след следващата промяна в DNS. Проверете и порта, защото доставчиците, които ви местят на TCP 443, иначе ще имат нужда от правило, което никой не е записал. Тунел, който работи само по един протокол, обикновено е точно това пропускане, а не дефект на защитната стена.

На рутер същата форма отива във веригата FORWARD за клиентите зад него, а собственият трафик на рутера се нуждае от собствени правила. Набор правила, който покрива само препратените пакети, оставя SSH и DNS по стария път и точно така рутерът става недостъпен в момента, в който тунелът се вдигне.

Стъпка 4: проверете реда, не само наличието

Правилата се оценяват последователно, така че ACCEPT, който идва по-рано, просто скрива REJECT, добавен след него. Съпоставянето established и related позволява на отговорите на вашите изходящи заявки да се върнат, без да се отваря общ входящ път, а поставянето му след приемането на тунела означава, че свален тунел все още пропуска обратен трафик по своя интерфейс.

Дръжте броя правила достатъчно малък, за да се прочете на един екран. Набор правила, който не можете да одитирате, е такъв, който ще кърпите, добавяйки изключения в горната част, и точно така политиките със забрана по подразбиране постепенно придобиват ръб на разрешаване по подразбиране. Пребройте ACCEPT преди и след промяната.

Стъпка 5: направете го да преживее зареждането и семейството от адреси

Правила, въведени на ръка, изчезват при рестартиране, затова ги зареждайте от услугата за защитна стена на дистрибуцията или от unit, който се изпълнява след съществуването на тунелния интерфейс. Позоваването на tun_work в скрипт, който се изпълнява преди OpenVPN да стартира, е чест начин да се получи цикъл на зареждане с отпаднал трафик.

След това проверете IPv6 отделно, защото добра политика на забрана по подразбиране за IPv4 не казва нищо за другото семейство. ip -6 route ще ви каже дали хостът има маршрут, който би могъл да носи трафик около тунел, който обработва само IPv4, а ip6tables или nftables се нуждае от собствени еквивалентни правила. Тествайте с дестинация IPv6-only, вместо да се доверявате на симетрията на набора правила.

Стъпка 6: проверете и бъдете готови да възстановите

Вдигнете тунела, потвърдете, че желаната услуга работи, след което опитайте нещо, което политиката трябва да откаже. Възстановете с iptables-restore < /root/iptables.pre, ако отговорът ви изненада, и само тогава започнете да редактирате правила. Устойчивостта плюс тестван път за възстановяване е това, което прави тази промяна такава, която можете да направите два пъти.