Заблакаваць аднаго кліента OpenVPN з LAN, не спыняючы тунель
Прывяжыце тунельны адрас кліента да яго сертыфіката, скіньце яго трафік у LAN у пачатку FORWARD, затым праверце IPv6, адсочваныя сесіі і выжыванне пасля перазагрузкі.
Адзін кліент на вашым серверы OpenVPN павінен страціць доступ да LAN, пакуль усе астатнія тунелі працуюць. Пашукайце гэта, і лепшы адказ звычайна кажа, што дэман гэтага не можа, што праўда толькі напалову: у OpenVPN няма фаервола для кожнага кліента, але хост, які завяршае тунель, ужо фільтруе пакеты. Два рашэнні, якія маюць значэнне, — гэта асоба, якую вы блакуеце, і пазіцыя правіла. Зрабіце гэта правільна, і змена стане адным радком, які можна праверыць і выдаліць.
Прывяжыце кліента, перш чым пісаць правіла
OpenVPN выдае тунельныя адрасы з пула, таму 10.8.0.6 — гэта месца, а не чалавек. Калі сесія заканчваецца, арэнда вяртаецца і можа быць перададзена наступнаму злучэнню, а значыць правіла, напісанае супраць гэтага адраса, ідзе за месцам, а не за карыстальнікам. Таму спачатку вырашыце, што вы насамрэч блакуеце: адрас для кароткага эксперыменту ці сертыфікат для чалавека, якога хочаце не пусціць.
Каб прывязаць адрас да сертыфіката, стварыце файл у каталозе, названым client-config-dir, і дайце файлу дакладна common name сертыфіката. Змесціце ў яго адну дырэктыву, ifconfig-push 10.8.0.6 255.255.255.0, і гэты кліент захавае той жа тунельны адрас паміж перападключэннямі. Для гэтага павінны існаваць дзве налады: client-config-dir мусіць быць абвешчаны ў канфігурацыі сервера, а адрас, які перадаецца, павінен знаходзіцца ў падсетцы, якую сервер можа маршрутызаваць. Прапусціце хоць адну — і файл будзе праігнараваны без памылкі, што зробіць наступны тэст фаервола памылковым.
Часовая блакіроўка можа выкарыстоўваць адрас з пула, калі ў заяўцы запісана, якая сесія трымала яго ў той момант.
Парадак вырашае, ці выканаецца скід
На Linux-шлюзе, які перасылае паміж тунелем і LAN, пакеты праходзяць ланцуг FORWARD. Чытайце каманду ніжэй як сказ: уставіць у пачатак FORWARD, супаставіць трафік, які ўваходзіць з tun0, ад гэтага аднаго хоста, накіраваны ў падсетку LAN, і скінуць яго.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP-I — гэта тое, што прымушае правіла працаваць. Дададзенае праз -A, яно апынецца ніжэй за любы шырокі дазвол для падсеткі тунеля і ніколі не ўбачыць пакет. Праверце пазіцыю з iptables -vnL FORWARD --line-numbers і прачытайце таксама лічыльнікі: скід угары, які нічога не лічыць, азначае, што трафік прыходзіць іншым шляхам.
Уласны адрас шлюза ў LAN — гэта іншы шлях. Пакеты, накіраваныя самому блоку, ідуць у INPUT, а не ў FORWARD, таму кліент можа страціць хост у LAN і ўсё яшчэ адкрыць адмін-старонку роўтара. Дадайце адпаведнае правіла INPUT, калі гэта важна.
Што фільтр не можа ўбачыць
Фільтраванне адбываецца пры ацэнцы пакета, таму ўсталяваная TCP-сесія можа працягвацца, пакуль не закрыецца або не будзе скінута. Калі блакіроўка мусіць дзейнічаць неадкладна, ачысціце адсочваемыя патокі для гэтай крыніцы праз conntrack -D -s 10.8.0.6 пасля ўстаўкі правіла. Калі некалькі секунд перакрыцця дапушчальныя, запішыце гэты выбар, а не пакідайце яго няяўным. У любым выпадку наступнаму чалавеку трэба ведаць, ці правіла спыняе жывы трафік, ці толькі новыя злучэнні.
Трафік паміж аднагодкамі ніколі не закранае фаервол хоста. Калі client-to-client уключаны, OpenVPN перасылае гэтыя пакеты ўнутры дэмана, таму іх не бачыць ні FORWARD, ні INPUT. Адзіныя рашэнні — выключыць client-to-client або прыняць, што аднагодкі могуць дасягаць адзін аднаго; правіла iptables гэты трафік не ўбачыць.
IPv6, прашыўка і выжыванне пасля перазагрузкі
Правіла IPv4 нічога не кажа пра IPv6. Калі тунель і LAN нясуць абодва сем'і, эквівалентнае правіла павінна існаваць у ip6tables або ў наборы правіл nftables, які валодае палітыкай на гэтым хосце. Прашыўка роўтара часта хавае netfilter за сваёй абстракцыяй, таму сінтаксіс і назвы табліц, скапіяваныя з форуму, могуць не падыходзіць.
На OpenWrt дакументаваны шлях — гэта запіс канфігурацыі фаервола, а не напісаны ўручную радок iptables, і напісаны ўручную радок можа знікнуць пры перазагрузцы фаервола. Іншыя дыстрыбутывы аднаўляюць правілы праз netfilter-persistent, загрузны модуль або сховішча вытворцы, і гэтыя механізмы не ўзаемазамяняльныя. Давядзіце выбраны варыянт перазагрузкай, бо перазагрузка праводзіць іншы шлях.
Праверце па шляхах, затым акуратна адкаціце
Тэстуйце кожны шлях асобна, бо адна паспяховая праверка хавае астатнія. Заблакаваны кліент павінен па-ранейшаму дасягаць інтэрнэту праз тунель, але не дасягаць хоста ў LAN; другі кліент павінен дасягаць таго ж хоста; адрас шлюза і шлях да аднагодка патрабуюць кожны свайго назірання. Запішыце вынікі побач з правілам, каб наступная змена мела базу. Табліца ніжэй — гэта набор, які варта захаваць у заяўцы.
| Шлях | Чакана з правілам | Калі не спрацуе |
|---|---|---|
| Заблакаваны кліент да хоста ў LAN | Няма адказу | Правіла ніжэй за дазвол, або крыніца не супадае |
| Заблакаваны кліент да інтэрнэту | Працуе праз tun0 | Правіла занадта шырокае, без супадання прызначэння |
| Другі кліент да таго ж хоста ў LAN | Працуе | Правіла супала больш чым з патрэбным хостам |
| Заблакаваны кліент да адраса шлюза ў LAN | Блакуецца толькі з адпаведным правілам INPUT | Правіла INPUT адсутнічае |
| Заблакаваны кліент да тунельнага адраса аднагодка | Усё яшчэ працуе | client-to-client уключаны і па-за межамі фаервола |
Адкат — гэта выдаленне па спецыфікацыі, а не flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP выдаляе менавіта гэты запіс і пакідае астатні ланцуг цэлым. Выдаліце той жа радок з любога файла, які аднаўляе правілы пры загрузцы, перазагрузіце яго і пацвердзіце, што кліент зноў дасягае хоста ў LAN. Flush FORWARD адмяніў бы таксама правілы, якія вы не пісалі, і гэта ператварыла б адкат у другі інцыдэнт.
Перш чым закрыць заяўку, пацвердзіце тры рэчы: прывязаны адрас супадае з сертыфікатам, правіла стаіць вышэй за дазволы з ненулявым лічыльнікам, і файл захавання змяшчае тое ж правіла, якое вы тэставалі. Калі чагосьці з гэтага няма, блакіроўка — гэта ілюзія ўнутры shell-сесіі.