Хост 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: зрабіце так, каб яно перажыло загрузку і сямейства адрасоў

Правілы, уведзеныя ўручную, знікаюць пры перазагрузцы, таму загружайце іх з службы файрвола дыстрыбутыва або юніта, які запускаецца пасля з'яўлення інтэрфейса тунеля. Спасылка на tun_work у скрыпце, што выконваецца да старту OpenVPN, — распаўсюджаны спосаб атрымаць цыкл загрузкі са скінутым трафікам.

Затым праверце IPv6 асобна, бо добрая палітыка прадвызначанай забароны для IPv4 нічога не гаворыць пра іншае сямейства. ip -6 route пакажа, ці мае хост маршрут, які мог бы несці трафік у абыход тунеля, што апрацоўвае толькі IPv4, а ip6tables або nftables патрабуе ўласных эквівалентных правілаў. Тэстуйце з прызначэннем IPv6-only, а не спадзейцеся на сіметрыю набору правілаў.

Крок 6: праверце і будзьце гатовы аднавіць

Узніміце тунель, пераканайцеся, што патрэбная служба працуе, затым паспрабуйце нешта, што палітыка павінна адхіліць. Аднавіце праз iptables-restore < /root/iptables.pre, калі адказ вас здзівіць, і толькі тады пачынайце правіць правілы. Захаванне разам з правераным шляхам аднаўлення — гэта тое, што робіць гэта змяненне такім, якое можна зрабіць двойчы.