Форвардинг в файрволле OpenWRT, или «surprise motherfucker!»

Там же написано, почему так сделано. И трекинга нет только в случае отсутствия маскарадинга (а он есть у 99% юзеров). И что, включить - это проблема?

Да нет, не проблема. Просто я не пойму, нельзя было включать ct автоматически при появлении правил форвардинга из/в зону? Потому что сейчас такая весёлая ситуация получается, что через гуй форвардинг настроить можно, но работать он внезапно не будет — нужно править конфиг руками.

Ну, справедливости ради, для нормального функционирования фаервола на роутере, трекинг соединений нужен далеко не всегда. Да, с ним удобнее писать правила (используя состояния ESTABLISHED и RELATED), но скорость достаточно критична для таких девайсов (а ведь conntrack - это практически dpi). Правда, могут возникнуть проблемы или неочевидности с некоторыми протоколами (типа ftp), но ведь ни кто возможность трекинга не выбрасывал.

Это понятно. Но там есть гуй для настройки форвардинга. Он добавляет в таблицу FORWARD правило ACCEPT в одну сторону (из одного интерфейса в другой). И как бы без ct эта штука бесполезна, т. к. ответы тупо не дойдут.

Вопрос в том, нормально ли это — я чесал репу полчаса (хотя админ из меня херовый, согласен), а что скажет обычный «уверенный пользователь»?

Он добавляет в таблицу FORWARD правило ACCEPT в одну сторону (из одного интерфейса в другой).

Можно добавить ответное правило в обратную сторону.

а что скажет обычный «уверенный пользователь»?

А я сюда каким боком?

Думаю, обычный, уверенный пользователь не задумывается над тем, что такое conntrack, iptables (и уж тем более - цели и цепочки в нём), и вся остальная дребедень. И уж тем более не станет вкорячивать openwrt.

Кстати, по поводу уверенного пользователя. Меня тут на днях убило наповал, когда я узнал, что в вендовом фаерволе отсутствует трекинг udp, и для работы openvpn клиента понадобилось создать правило для входящего (!!!) трафика.

И уж тем более не станет вкорячивать openwrt.

А если представить себе такого, который может поставить openwrt и работать с админским гуём, но не умеет в SSH и консоль?

Думаю, обычный, уверенный пользователь не задумывается над тем, что такое conntrack, iptables (и уж тем более - цели и цепочки в нём), и вся остальная дребедень.

Ну вот об этом и речь. Гипотетический пользователь читает доку, лезет в гуй и создаёт правило форвардинга из сети A в сеть B, наивно думая, что так он сможет открывать соединения из A в B, но не наоборот. Типичный такой примитивный юзкейс: «однонаправленная дверь». А получается, что он вообще никуда не может создавать соединения, потому что «by default, the firewall will disable connection tracking».

Гипотетический пользователь читает доку, лезет в гуй и создаёт правило форвардинга из сети A в сеть B, наивно думая, что так он сможет открывать соединения из A в B, но не наоборот.

Неа, не верю. Обычные пользователи этим не занимаются. Или ты про обычных пользователей OpenWRT?

А получается, что он вообще никуда не может создавать соединения, потому что «by default, the firewall will disable connection tracking».

Дык я же говорю, можно и без трекинга, только нужно 2 правила, а не 1.

Обычные пользователи этим не занимаются. Или ты про обычных пользователей OpenWRT?

Я про обычных пользователей OpenWRT, ага.

Дык я же говорю, можно и без трекинга, только нужно 2 правила, а не 1.

Тогда это будет «дверь, открывающаяся в обе стороны». Не то.

Тогда это будет «дверь, открывающаяся в обе стороны». Не то.

Для tcp есть флаг SYN, который установлен в первом пакете (запрос на соединение). У iptables есть параметр --tcp-flags, где можно установить, какие флаги должны быть. Для icmp есть параметр --icmp-type, где можно указать необходимый тип (например, echo-reply). А вот с UDP - немного сложнее. Можно писать правила без учёта направления установки соединения, но с учётом номеров портов источника и назначения. Например, для DNS в одну сторону идут пакеты на 53 порт с порта >=1024, а в другую - на порт >=1024 с 53.

Да, а ещё на счётах можно H.265 декодировать (за конечное время), или совершать перректальную гландэктомию автогеном, но тред-то про юзабилити и принцип наименьшего удивления.

Ещё раз, OpenWRT - это не десктопный дистр. Те устройства, куда он ставится, обладают довольно слабыми процессорами (это, кстати, будет заменто, например, если через роутер торренты покачать, ещё больше будет заметно, если это сделать через vpn соединение). А с учётом того, что никакого аппаратного ускорения сетевого стека в OpenWRT не используется (в отличие от прошивок от вендоров устройств), отключение жрущего процессор conntrack, выглядит довольно здравой идеей. И в том, что я написал в своём предыдущем сообщении, нет никакого rocket science.

То, что трекинг нельзя включить через luci, это, конечно, не очень хорошо.

А если представить себе такого, который может поставить openwrt и работать с админским гуём, но не умеет в SSH и консоль?

то есть, он в полной несознанке качает с репозитория сорцы, патчит их под нужную архитектуру, добавляет в репозитории LuCI, апдейтит пакеты, запускает конфиг, выставляет стопицот настроек, включая особенности хардвары, включает веб-морду в образ, собирает это всё, прошивает через tftp, перегружает железяку, подцепляется к ней и - упс! - забыл, как ssh юзать?
в большинстве девайсов, на которых работает OpenWRT, никакой глубокий анализ пакетов не нужен, ибо чаще всего это очень мелкие и довольно слабые процессоры и такая нагрузка их просто прибьёт. ну а если проц мощный и есть желание заморочиться - пожалуйста, настройка всего, включая кернел, там доступна.

Лол потому что юзать павила с этими всякими ESTABLISHED это нубство, а нубы должны страдать.

юзать павила с этими всякими ESTABLISHED это нубство

А вот здесь поподробнее. В чём нубство? Это, во-первых, довольно удобно, а во-вторых, без этого иногда вообще никак. Протоколы бывают разные, и далеко не всегда достаточно того, что я написал выше. Расскажи, например, как ты без RELATED и без conntrack будешь пропускать ftp active?

А есть ещё и протоколы IP телефонии, где всё намного хуже.

Во первых опенврт это поделка для домашних мыльниц, и там нужно только одно правило — натить все подряд. Ну разве что минимальная фильтрация. Во вторых, приведи пример подобного правила и объясни что оно делает.

Так чтобы поставить openwrt на поддерживаемую железку, достаточно просто выкачать пресобранный образ фирмвари и залить его на оную железку через штатную веб-админку.

Ну и тред не об этом, а об очень сильно протекающей абстракции «форвардинг между зонами», которую придумали в опенврт.

Давай, расскажи мне, как ты обходишься без conntrack, иксперд ты наш.

Без коннтрак трудно натить, но я говорю о ненужности другого, и мы оба знаем чего.

Во вторых, приведи пример подобного правила и объясни что оно делает.

Клиент за фаерволлом, сервер в инете. FTP active - это режим, в котором _сервер_ отправляет данные на указанный клиентом порт, и ты заранее не знаешь, какой порт он выберет. Более того, ты можешь не знать и адрес сервера.

В общем, для корректной работы сети за фаерволлом тебе придется открывать весь range динамических портов для всего интернета для tcp и udp, плюс все остальные протоколы, используемые в твоей сети. Так, собственно, раньше и делали, но только до тех пор, пока не появились stateful фаерволлы, в которых это решалось одним правилом с ESTABLISHED,RELATED.

Чего-то я вот тоже вас не понимаю. Окэ, даже если забыть про нат NEW, ESTABLISHED для udp этого мало?

Точно точно, так и было. И еще в случае nat ftp активный няработал поэтому придумали пассивный режим.

Ну и тред не об этом, а об очень сильно протекающей абстракции «форвардинг между зонами», которую придумали в опенврт.

OpenWRT - это, в первую очередь, инструмент для сборки образов под всякие-разные железки. как собирать и настраивать - дело вкуса. ну а если умения/желания собирать и настраивать нет, тогда приходится опускаться до уровня «ешь, что дают» и пользоваться готовыми прошивками. а там тонкости никто не учитывает, делают типовые прошивки для обычного юзера. но это уже больше смахивает на юзеров проприетарщины.
вообще, OpenWRT очень гибкий. я знаю, что там есть некоторые недочёты в системе скриптов, но это мои придирки. совсем непроходимых проблем там всё-таки нет. я его собирала и по работе, и дома, много раз. там всё настраивается, если нужно - дописывается без проблем. можно писать свои патчи на ядро или любые пакеты. в целом, довольно удобный конструктор прошивок под разное железо. в нём можно собирать тулчейны под разные процы, что тоже бывает полезно.
что касается conntrack, то, по-моему, в OpenWRT он попадает в концепцию firewall
https://wiki.openwrt.org/doc/uci/firewall
и выглядит как фильтр между «зонами». зоны можно назначать в виде групп сетевых интерфейсов. по-моему, не такая плохая концепция.
насчёт «включения автоматически» опций ядра - нелепое требование. на ходу это нереально, а по дефолту в OpenWRT слишком жирные опции ядра отключены, чтобы размер образа был меньше и чтобы ядро не съедало проц. если хочешь свистелки и перделки - собирай образ сам и выставляй, что тебе нужно. только убедись, что он потом влезет в твою железяку и поднимется на ней.

Да тут не про ядро совсем.

conntrack вкомпилен в ядро, но выключен в рантайме. И тред о том, что его было бы неплохо автоматически включать, если юзер делает однонаправленный форвардинг между зонами — иначе ответы тупо не будут доходить, и форвардинг будет по сути неработоспособен

Речь не о том, что я чего-то не умею, а о том, что у них в файрволле абстракции протекают.

OpenWRT
Принцип наименьшей неожиданности нервно курит в сторонке.

все посередине скучно и избыточно.

Во первых опенврт это поделка для домашних мыльниц, и там нужно только одно правило — натить все подряд.

Я рад за тебя, что ты лучше меня знаешь о том, что мне нужно.

приведи пример подобного правила и объясни что оно делает.

Какой пример тебе привести? Для ftp? Но тебе тогда нужно прочитать, как работает этот протокол. Прочитаешь - приходи, покажу, как ftp active проходит через фаервол.

Все работает и без этих правил.

У меня такое чувство что это тебе стоит почитать о том как работает нат фтп в линуксе.

Ты заявил о ненужности conntrack. Весь остальной контекст и уточнения прозвучали только в твоей голове. Это раз.

В контексте данного треда можно извернуться и статически разрешить в обратную сторону пакеты, которые похожи на ответы на уже установленные соединения, но ты должен понимать, что это гораздо более слабое условие, чем конкретно ответы на уже установленные соединения. При рассмотрении достаточно большого спектра протоколов такое решение ничем не отличается от тупого разрешения форвардинга в обе стороны, что очевидно неприемлемо. Это два.

Так что ты там хотел сказать?

Я понял, ты просто не понимаешь разницы между трекингом и правилами в айпитаблицах. Ну удачи тебе, чо.

Я прекрасно понимаю «разницу между трекингом и правилами». Тебе есть что возразить на вышесказанное по существу?

Нет, не понимаешь.

Какой пример тебе привести? Для ftp?

Не важно для чего, ты приведи а я объясню почему оно не нужно.

Давай же, засунь своё ЧСВ себе в зад и расскажи мне, чего я не понимаю.

Если кто-то говорит что что либо нужно, то он и должен объяснить для чего, верно?

Где пример правила RELATED/ESTABLISHED которое «нужно»?

У меня такое чувство что это тебе стоит почитать о том как работает нат фтп в линуксе.

Спасибо, я знаю, как он работает. А при чём здесь NAT? Я про него не писал. А вот тебе советую почитать. Расскажи-ка мне, как ты без conntrack собрался пропускать active ftp.

Я объяснил — настолько подробно, насколько позволяет моя (не)компетентность. Жду с твоей стороны указания на то, где в объяснении ошибка(-и). Пример правила очень простой:

iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Или чуть более подробно:

iptables -A FORWARD -i tun0 -o br-lan -j ACCEPT \
    --comment "forward vpn_admin -> main"
iptables -A FORWARD -i br-lan -o tun0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT \
    --comment "forward replies main -> vpn_admin"

Кстати, раз уж ты заговорил про nat ftp, ты, наверное, имел ввиду модуль nf_nat_ftp. Так вот. Ты, конечно, сильно удивишься, но этот модуль требует загрузки модуля nf_conntrack_ftp. Сюрприз!

Не важно для чего, ты приведи а я объясню почему оно не нужно.

Хорошо. Вот пример: есть 2 сети, разделённые фаерволом. Никакого nat нет. Между 2 сетями надо пропускать только sip звонки. Разрешать диапазон портов - не допустимо. Разрешать весь трафик для конкретных хостов - тоже недопустимо. Реши задачу без RELATED и ESTABLISHED.

Все работает без этих правил. У тебя не работает? Пробовал не делать -P FORWARD DROP?

Еще один не знает разницы между коннтраком и правилами содержащими слово RELATED. Удачи и тебе.

Мы тут говорим о том, как настроить файрволл, а не о том, как его выключить. Давай ты будешь троллить где-нибудь в другом месте?

Я прекрасно знаю разницу. Правила, содержащие RELATED, используют conntrack. Ещё раз: реши эту задачу без ESTABLISHED и RELATED. Не сможешь? Тогда зачем здесь балаболишь?

Недопустимость пропускания портов высосана из пальца. Более того, такого рода блокировки легко обходятся. Нужно объяснять как сымитировать сип звонок чтобы добавить нужную запись в коннтрак таблицу?

Все что нужно в твоем фаерволе это

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

Давай ты будешь строить из себя админа пентагона в другом месте?

Кроме шуток, эти ваши полотна из релейтедов, кастомный цепочек и прочих каляк-маляк на поверку ничем не отличаются от одного единственного вышеприведенного правила.

Недопустимость пропускания портов высосана из пальца.

Нет таковы требования. А в случае с ftp ты предложишь открыть всё, что >=1024?

Более того, такого рода блокировки легко обходятся. Нужно объяснять как сымитировать сип звонок чтобы добавить нужную запись в коннтрак таблицу?

Я тебе привёл конкретную задачу. Ты её решать собираешься?

А. Я понял. conntrack используют нубы. Настоящие суровые админы просто разрешают все соединения. Вопросов больше не имею.

Я тебе привёл конкретную задачу.

Задача некорректна.

Я тебе привёл конкретную задачу.

Задача некорректна.

redixin ★★★ (21.01.2016 12:46:44) царь от /Admin/