Запретить NAT'ы внутри сети. Есть идеи?
-
Можно использовать опцию Source OS = Windows (MAC OS) для разрешения трафика с рабочих станций при условии, что на рабочих станциях только указанные ОС, и умные юзеры не догадаются использовать общий доступ (TI/KERIO) для натирования трафика.
Дополнительно опции:
Максимальное число установленных соединений на каждый хост
Максимальное число записей State на каждый хост -
Доп.опции нам не подходят, т.к. не первая, не вторая конкретно не решит задачу, а просто порежет пользователю канал.
А вот Сурс Ось выглядит очень заманчиво! Но это только на первый взгляд. Тут сразу и проблема. Во-первых, сквид, со своим бронебойным 80м портом отменяет фильтрацию по нему.
А во-вторых, вы, уважаемый dvserg, почему-то не учли, что Непосредственно Клиентские машины-то на винде\Выставлением Сурс ОСи на Только винду, к примеру, я запрещу только непосредственно подключения по tcp C Самого роутера. Через же него ходят пакеты из винды, и изменен в них только адрес отправителя, та часть пакета, по которой pf судит винда это или нет, роутером не затрагивается. Так что вариант клевый, но, к сожалению, не работающий.продолжаем брэиншторм, господа! Решения так и нет\
-
продолжаем брэиншторм, господа! Решения так и нет\
Аналога приведенной выше функции в PF я не вижу. Возможно Вам стоит подумать об альтернативном дистрибутиве на Linux.
-
блин, я боялся этого. Но если варианты исчерпаны - тогда другой вопрос: программисты С, есть ли тут кто из джедаев, кто за вознаграждение готов взяться за дописывание сурсов pf?
-
за дописывание сурсов pf?
а смысл? Есть некоторое количество решений с гораздо большим функционалом и меньшим количеством проблем чем сенс.
"… пилите, Шура, пилите, они золотые... (С)" :D -
Да мне и не нужен Гораздо Больший Функционал. Для меня и в ПФе много чего лишнего, зато он чрезвычайно четок и уже как родной.
Можете посоветовать что-нибудь, с такой же стабильностью, управляемостью, хорошим шейпингом, возможностью 2х Wan'ов, симпотичными RRD графиками и тп.
потому что я так ничего стоящего не нашел.
ClearOS, Zentyal?
На мой взгляд это какие-то переростки по 700метров дистр.
мне позарез нужен довольно ограниченный функционал NAT+firewall+squid&squidguard(для отображения страницы об оплате инета)+dnsmasq+dhcp+havp(необязательно)+чтонибудь типа ntop'а, тока, блин Работающее. Без всяких доп. наворотов(или устанавливающихся посредством дополнений) Просто я был большим евангелистом freebsd, когда выбирал дистрибутив, 2.5 года назад) и ни на что другое, "линуховое", не смотрел. Сейчас у меня на 1.2.3 работают уже скрипты, куча конфигов переписана)) эх, как я его докручивал.
Но сейчас готов выслушать совет опытного человека) Покажите Вы, на что можно посмотреть.
Но даже если почитать http://forum.ru-board.com/topic.cgi?forum=8&topic=24052&start=120 (Software Routers&Firewalls), то там тоже в основном pf рекомендуют) -
Кому интересно поучаствовать в разработке нашего любимого Packet Filter'а, вот вам Баунти за это) Как видно из описание, оно изменчиво в бОльшую сторону.
http://forum.pfsense.org/index.php/topic,42068.0.html -
Неужели никто не знает как? Повторюсь, мне нужен аналог опции iptables у pf:
iptables -t mangle -A PREROUTING -i eth0 -j TTL –ttl-set 1:) Шибко смахивает на МикроТик'овское правило.
-
goliy - почитал топик, но не понял смысла затеи.
для чего нужно такое ограничение? -
goliy - почитал топик, но не понял смысла затеи.
для чего нужно такое ограничение?По-моему, в названии топика все сказано. Смысл - сделать так, чтобы NATов(роутеров, и прочих "раздавал") внутни сети было как можно меньше, или не было совсем.
-
т.е. имеете ввиду, что бы юзер, у которого есть анлимный инет, не поставил у себя прокси\не включил нат и не раздавал инет кому то?
в таком случае -
тогда идея с ттл -поможет максимум от ната… но не поможет от прокси (никто же не запрещает и прозрачную?).
опять таки -не факт что поможет от ната... ттл разве на нат влияет? вроде только на роутинг... нату пофик ттл... нат- "обертка" одних пактов другими.
вы проверяли идею с ттл для ограничения ната? а не роутинга -
т.е. имеете ввиду, что бы юзер, у которого есть анлимный инет, не поставил у себя прокси\не включил нат и не раздавал инет кому то?
в таком случае -
тогда идея с ттл -поможет максимум от ната… но не поможет от прокси (никто же не запрещает и прозрачную?).
опять таки -не факт что поможет от ната... ттл разве на нат влияет? вроде только на роутинг... нату пофик ттл... нат- "обертка" одних пактов другими.
вы проверяли идею с ттл для ограничения ната? а не роутингаПоможет. Любой пакет проходящий через доп. узел получает минуc 1 значение TTL. Когда на комп приходит пакет со значением TTL 1, он обрабатывается, а дальше уже не передается, т.к. TTL становится равным 0.
Конечно, его можно увеличить. Но вопрос в том, что этим нужно озоботиться, а юзеры, покупающие роутер за 2к, и настраивающее его 1 раз по визарду, определенно не додумаются до этого.
Я же написал - запретить НАТ полностью этим не получится, но значительно снизить его кол-во - как раз то, что нужно -
хм, только что проверил:
установил на роутере линуховом правило, по вашему примеру,
1 - на моем ноуте виртуалка, выходит по нату, нат пашет…
2 - поставил роутер, 804й длнк (стоит не 2к баксов :) ) - за ним подключил ноут - пакеты ходят... -
хм, только что проверил:
установил на роутере линуховом правило, по вашему примеру,
1 - на моем ноуте виртуалка, выходит по нату, нат пашет…
2 - поставил роутер, 804й длнк (стоит не 2к баксов :) ) - за ним подключил ноут - пакеты ходят...Извиняюсь, может я привел не правильное правило iptables, т.к. не имел с ним дело.
Проверьте чтобы правило было применимо ко всем пакетам, выходящим из локального интерфейса.
Теория не работать просто не может. Так устроен стек tcp\ip -
еще раз спрашиваю - вы сами то свою теорию проверяли?
каким образом ттл1 не даст работать нату? если вы видите пакеты от имени роутера, и роутеру достаточно что бы они дошли до него? (в большинстве даже сохо роутеров используется баналый маскардинг, он меняет внутрение ипы на свои. -
Я считаю, что это не требует проверки.
Объясняю еще раз, по стандарту rfc1009 любой роутер уменьшает значение TTL на еденицу. При установленном в IP-пакете роутером параметра TTL=1 пакет декрементируется на единицу в следующем узле и в нём же трагично погибает.
Тут совершенно не имеет значение что роутер делает с пакетом. Использует ли он NAPT, NAT Overload, PAT или просто маршрутизирует пакеты, всегда узел сети уменьшает TTL, если в нем специально не задано иное действие.
Я рад, что вы решили в этом убедиться, но не смогли. Скорее всего, из-за некорректных настроек iptables. Но я не очень хочу тратить время на очевидную вещь.