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