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