Запретить NAT'ы внутри сети. Есть идеи?



  • Добрый день, уважаемые знатоки!

    Интересуют ваши способы ограничения NAT'ов внутри локалки.
    Мне вот пришла в голову идея о урезания TTL пакетов, идущих в локальную сеть до 1. Таким образом первый уровень будет получать все что надо и радоваться, а на втором нате пакеты будут дропаться. Конечно, не сложно настроить и второй роутер так, чтобы он не уменьшал значение ttl, либо увеличивал его. Но все же это выход.
    Погуглив данный вопрос, я обнаружил лишь обратный функционал от моей задачи. Выставление min-ttl. Это конечно клево, но я не поверю, чтобы возможности pf не позволяли делать обратного. У кого-нибудь есть идеи? (кроме переписывания и пересобирания pf'a с добавлением возможностей. Это я врятли сейчас осилю)))
    Но, конечно, я рад выслушать и другие Ваши интересные предложения!
    Спасибо!



  • Неужели никто не знает как? Повторюсь, мне нужен аналог опции iptables у pf:
    iptables -t mangle -A PREROUTING -i eth0 -j TTL –ttl-set 1



  • Можно использовать опцию 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



  • @goliy:

    Неужели никто не знает как? Повторюсь, мне нужен аналог опции iptables у pf:
    iptables -t mangle -A PREROUTING -i eth0 -j TTL –ttl-set 1

    :) Шибко смахивает на МикроТик'овское правило.



  • goliy  - почитал топик, но не понял смысла затеи.
    для чего нужно такое ограничение?



  • @alexandrnew:

    goliy  - почитал топик, но не понял смысла затеи.
    для чего нужно такое ограничение?

    По-моему, в названии топика все сказано. Смысл - сделать так, чтобы NATов(роутеров, и прочих "раздавал") внутни сети было как можно меньше, или не было совсем.



  • т.е. имеете ввиду, что бы юзер, у которого есть анлимный инет, не поставил у себя прокси\не включил нат и не раздавал инет кому то?
    в таком случае -
    тогда идея с ттл -поможет максимум от ната… но не поможет от прокси (никто же не запрещает и прозрачную?).
    опять таки -не факт что поможет от ната... ттл разве на нат влияет? вроде только на роутинг... нату пофик ттл... нат- "обертка" одних пактов другими.
    вы проверяли идею с ттл для ограничения ната? а не роутинга



  • @alexandrnew:

    т.е. имеете ввиду, что бы юзер, у которого есть анлимный инет, не поставил у себя прокси\не включил нат и не раздавал инет кому то?
    в таком случае -
    тогда идея с ттл -поможет максимум от ната… но не поможет от прокси (никто же не запрещает и прозрачную?).
    опять таки -не факт что поможет от ната... ттл разве на нат влияет? вроде только на роутинг... нату пофик ттл... нат- "обертка" одних пактов другими.
    вы проверяли идею с ттл для ограничения ната? а не роутинга

    Поможет. Любой пакет проходящий через доп. узел получает минуc 1 значение TTL. Когда на комп приходит пакет со значением TTL 1, он обрабатывается, а дальше уже не передается, т.к. TTL становится равным 0.
    Конечно, его можно увеличить. Но вопрос в том, что этим нужно озоботиться, а юзеры, покупающие роутер за 2к, и настраивающее его 1 раз по визарду, определенно не додумаются до этого.
    Я же написал - запретить НАТ полностью этим не получится, но значительно снизить его кол-во - как раз то, что нужно



  • хм, только что проверил:
    установил на роутере линуховом правило, по вашему примеру,
    1 - на моем ноуте виртуалка, выходит по нату, нат пашет…
    2 - поставил роутер, 804й длнк (стоит не 2к баксов :) ) - за ним подключил ноут - пакеты ходят...



  • @alexandrnew:

    хм, только что проверил:
    установил на роутере линуховом правило, по вашему примеру,
    1 - на моем ноуте виртуалка, выходит по нату, нат пашет…
    2 - поставил роутер, 804й длнк (стоит не 2к баксов :) ) - за ним подключил ноут - пакеты ходят...

    Извиняюсь, может я привел не правильное правило iptables, т.к. не имел с ним дело.
    Проверьте чтобы правило было применимо ко всем пакетам, выходящим из локального интерфейса.
    Теория не работать просто не может. Так устроен стек tcp\ip



  • еще раз спрашиваю - вы сами то свою теорию проверяли?
    каким образом ттл1 не даст работать нату? если вы видите пакеты от имени роутера, и роутеру достаточно что бы они дошли до него? (в большинстве даже сохо роутеров используется баналый маскардинг, он меняет внутрение ипы на свои.



  • Я считаю, что это не требует проверки.
    Объясняю еще раз, по стандарту rfc1009 любой роутер уменьшает значение TTL на еденицу. При установленном в IP-пакете роутером параметра TTL=1 пакет декрементируется на единицу в следующем узле и в нём же трагично погибает.
    Тут совершенно не имеет значение что роутер делает с пакетом. Использует ли он NAPT, NAT Overload, PAT или просто маршрутизирует пакеты, всегда узел сети уменьшает TTL, если в нем специально не задано иное действие.
    Я рад, что вы решили в этом убедиться, но не смогли. Скорее всего, из-за некорректных настроек iptables. Но я не очень хочу тратить время на очевидную вещь.


Log in to reply