XoRe Опубликовано 15 марта, 2007 · Жалоба Стоит машинка на FreeBSD 6.0. У машинки 3 линка в интернет (у 2 линков реальные ип адреса, у третьего ип из сети 10.0.0.0, выходит в интернет через НАТ провайдера). Причем один линк (который через НАТ) указан, как default gateway. А на каждый из двух других линков прописано по некоторому количеству статических маршрутов. И есть линк в локальную сеть 192.168. А в локальной сети стоит ещё одна машинка. Допустим, адреса на линках в интернет такие: 1.1.1.1, 2.2.2.2 и 10.0.0.3. И допустим, внутренний ип-адрес машинки 192.168.0.1. А ип-адрес ещё одной машинки в локалке 192.168.0.2. Задача: пробросить в локальную сеть пару портов на 192.168.0.2. Причем нужно, чтобы 192.168.0.2 видел, с какого адреса из интернета к нему идет подключение. Кажется простым делом, с которым справляется ipfw+natd благодаря опции redirect-port. Он отлично справляется, если все идет через один канал. А когда несколько каналов, то получается вот что: Приходит пакет с какого-то адреса в интернете (допустим с адреса 5.5.5.5) на адрес 1.1.1.1. (пакет 5.5.5.5 -> 1.1.1.1). Проходит внутрь локалки, становясь пакетом вида 5.5.5.5 -> 192.168.0.2. Машинка в локальной сети отвечает пакетом 192.168.0.2 -> 5.5.5.5. И тут начинаются грабли. Если ответный пакет уйдет в интернет с линка 1.1.1.1, то он преобразуется в пакет 1.1.1.1 -> 5.5.5.5. И все будет нормально, ушел пакет 5.5.5.5 -> 1.1.1.1, пришел пакет 1.1.1.1 -> 5.5.5.5, соединение установлено. А если ответный пакет уйдет с линка 2.2.2.2 или 10.0.0.3, то компьтеру придет ответный пакет 2.2.2.2 -> 5.5.5.5 или 10.0.0.3 -> 5.5.5.5, что довольно сложно опознать, как ответ на пакет 5.5.5.5 -> 1.1.1.1. Сейчас это делается посредством программы redir (/usr/ports/net/redir). Но у этой программы есть один нюанс. При посылке пакета вида 5.5.5.5 -> 1.1.1.1 при прохождении через нашу машинку пакет преобразовывается в 192.168.0.1 -> 192.168.0.2. Т.е. для машины 192.168.0.2 все соединения идут с адреса 192.168.0.1. На пробрасываемый порт будут обращаться из разных точек интернета. И ответ на них идет по тому линку, который указан в таблице маршрутизации. Список точек неизвестен, поэтому жестко прописать маршрутизацию или fwd на них не получится. Сам по себе policy based routing на основе fwd давно настроен и работает. Доступ к серверу с любого из линков и работа клиентов в инете работает на ура. Необходимо сделать проброс так, чтоб 192.168.0.2 видел, с какого адреса из интернета к нему идет подключение. Подскажите, пожалуйста, решение для сей ситуации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 15 марта, 2007 · Жалоба Насколько знаю, fwd в ipfw и rdr в pf - это stateful правила (в последнем - так уж точно). А stateful как раз и позволяет определить, как отправлять ответный пакет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XoRe Опубликовано 16 марта, 2007 · Жалоба Статья http://www.opennet.ru/base/net/nat_jump.txt.html натолкнула на решение. Для примера буду использовать адреса выше, а пробрасываемые порты пусть будут 10000 и 20000. Решение: В ipfw у меня НАТ описан так: ${ipfw} add 16010 divert 8668 ip from not me to any via fxp0 ${ipfw} add 16020 divert 8669 ip from not me to any via fxp1 ${ipfw} add 16030 divert 8672 ip from not me to any via fxp2 Нужно прописать такое правило: ${ipfw} add 15610 divert 8669 tcp from 192.168.0.2 10000,20000 to any out Причем, как видно из номера правила, его нужно прописать ПЕРЕД правилами с обычным натом. Суть решения в том, что тогда даже если пакет собирается уйти наружу через другой интерфейс, он все равно будет завернут на нат того интерфейса, через который должен выходить. После ната у исходящего пакета будет нужный внешний адрес, т.е. 1.1.1.1. Ну а с помощью правил: ${ipfw} add 23010 fwd 1.1.1.2 ip from 1.1.1.1 to any ${ipfw} add 23030 fwd 2.2.2.3 ip from 2.2.2.2 to any ${ipfw} add 23040 fwd 10.0.0.4 ip from 10.0.0.3 to any Пакет уйдет через тот линк, через который нужно. fwd правила - это реализация policy based routing. В целом решение получается такое: Определиться с интерфейсом, на котором пробрасывать порты. Такой интерфейс должен быть один. Настроить на нем редирек портов вида: -redirect_port tcp 192.168.0.2:10000 20000 Ну и добавить в фаерволл правило, которое будет подхватывать исходящие пакеты с пробрасываемого порта и прописывать им нужный внешний адрес. 2GateKeeper: Динамическому равилу fwd неоткуда создаться при такой настройке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 17 марта, 2007 (изменено) · Жалоба Да. Перечитал man ipfw - fwd работает как надо только для редиректов на собственные адреса. Нужное умеет только pf. rdr on $if1 proto tcp from any to ($if1) port 123 -> 192.168.0.2 port 123 rdr on $if2 proto tcp from any to ($if2) port 123 -> 192.168.0.2 port 123 rdr on $if3 proto tcp from any to ($if3) port 123 -> 192.168.0.2 port 123 Да, кстати, народ. Завязывайте уже с natd. Ей богу. Изменено 17 марта, 2007 пользователем GateKeeper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kuzmich Опубликовано 22 марта, 2007 · Жалоба Да. Перечитал man ipfw - fwd работает как надо только для редиректов на собственные адреса. Нужное умеет только pf. Никогда не говори никогда. Связка ipfw2 + natd умеет почти всё. Давай упростим задачу: забудем вообще про NAT, и задача свернется к следующему: Если пакет от удаленного хоста пришел через интерфейс 1, то ответные пакеты на этот хост должны идти через интерфейс 1, несмотря на то, что таблица маршрутизации желает отправлять их через интерфейс 2. Нереализуемо? Реализуемо. Пусть eth0 - локалка (192.168.0.1) eth1 - 1.1.1.1, шлюз провайдера 1.1.1.254 eth2 - 2.2.2.1, шлюх провайдера 2.2.2.254 10000 check-state 10100 skipto 50100 ip from any to any in via eth1 keep-state 10200 skipto 50200 ip from any to any in via eth2 keep-state ..... 50000 deny ip from any to any 50100 allow ip from any to any in via eth1 50110 fwd 1.1.1.254 ip from any to any 50200 allow ip from any to any in via eth2 50210 fwd 2.2.2.254 ip from any to any Обвязку секурностью и nat'ами оставляю в качестве домашнего задания. P.S. Для шестой ветки ядро должно быть с IPFIREWALL_FORWARD, а не FORWARD_EXTENDED.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 22 марта, 2007 · Жалоба The fwd action does not change the contents of the packet at all. In particular, the destination address remains unmodified, so packets forwarded to another system will usually be rejected by that system unless there is a matching rule on that system to capture them. For packets forwarded locally, the local address это про ipfw fwd. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kuzmich Опубликовано 22 марта, 2007 · Жалоба Домашнее задание не выполнено. fwd действительно не меняет содержимое пакета, а только "выкидывает" это пакет в нужном направлении (либо в локальный сокет, либо (сюрприз!) из интерфеса, обернув его в новый эзернет-фрейм, с MAC-адресом того, чей адрес указан после fwd). А что сделает РОУТЕР, если к нему придет пакет, для него не предназначенный? Правильно, пошлет по назначению... и не не три буквы, а по таблице маршрутов (правда, не исключено, что в таблице маршрутов будут как раз три буквы, вернее чуть больше - blackhole) Подсказка к домашнему заданию: 1000 divert 8668 ip from any to me in via eth1 1100 divert 8669 ip from any to me in via eth2 вопрос на 5 - куда поставить divert ... from any to any out via eth1 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 22 марта, 2007 · Жалоба Kuzmich, давай я тебе щас пару заданий бредовых накину, а потом так же за невыполнение отчитывать буду? Сказал же: завязывайте с natd. Есть ничем не хуже pf и ipnat. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kuzmich Опубликовано 23 марта, 2007 · Жалоба Вот когда я сморожу очередную фигню типа "неможет быть, потому что не может быть никогда" - тогда и накидаешь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 23 марта, 2007 · Жалоба Kuzmich. Тыкаю носом в фигню: на слова "ipfw не умеет" начались пространные разглагольствования на тему "вот если бы еще присобачить вот это и сверху прикрутить такой костыль, а костыль подпереть такой-то чугунной чушкой...", и при этом какие-то попытки всучить вот эти извращения в качестве "домашнего задания"... "Лечиться тебе надо, дядя Фёдор". Да, совсем на пальцах: natd, помимо того, что userspace'овый, еще и ни одного раза не является компонентой ipfw. Так что, домашнее задание: читать man pf, man ipnat и много-много думать. Заодно перевести у твоего преподавателя по английскому вышепроцитированный текст из мана ipfw. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kuzmich Опубликовано 26 марта, 2007 (изменено) · Жалоба Kuzmich. Тыкаю носом в фигню: на слова "ipfw не умеет" начались пространные разглагольствования на тему "вот если бы еще присобачить вот это и сверху прикрутить такой костыль, а костыль подпереть такой-то чугунной чушкой..." Сэр, если pf был коммерческим продуктом, мне пришлось бы подумать, что вы рекламный агент, причем плохой. Ваше заявление "Нужное умеет только pf.", простите, сродни самой дешевой и лживой рекламе. Что, миллионы человекочасов, оплаченные компанией Cisco Systems, пошли прахом? Если бы вы написали "я знаю решение на pf, оно короткое и красивое" - никаких вопросов бы не возникло. У автора же используется ipfw, и "Сам по себе policy based routing на основе fwd давно настроен и работает". Ваше безапеляционное заявление призывает автора сломать работающую систему, и построить всё заново на "Вашей любимой игрушке" только потому, что вы не умеете читать маны, и, к сожалению, Вашего абстрактного мышления не хватает на то, чтобы пройти чуть дальше, чем написано в мане. Не говоря уже о том, что откровенно ложное заявление, если его не опровергнуть, породит заблуждения у десятков новичков, его прочитавших. Итак, переведем предложенный вами огрызок мана: Действие "fwd" никак не изменяет содержимое пакета. В частности, адрес назначения пакета остается неизмененным, таким образом пакеты, forwarded в другую систему, скорее всего будут ей отвергнуты, если на этой системе нет специальных настроек, позволяющих обработать такие пакеты. Извини, к преподавателю английского обращаться нет времени. Как и к нотариусу для заверения перевода. Из вышеприведенного огрызка, путем несложных логических заключений следует, что пакет, путь и неизмененный, дойдет до системы назначения. Теперь немножко почитаем... блин, даже не знаю какой man... лучше книжку какую-нибудь. Хоть тех же Олиферов. На предмет того, как работает маршрутизация протокола IP. Маршрутизатор, получив пакет, в заголовке которого адрес назначения не совпадает с каким-либо из адресов самого маршрутизатора, должен доставить этот пакет по назначению в соответствии со своей таблицей маршрутов. Вот оно и есть "специальная настройка" (или, если возвращаться обратно к man'у, a matching rule), которая позволит "another system'у" этот пакет не "reject'ить". Подтверждение тому - Сам по себе policy based routing на основе fwd давно настроен и работает.. Не верите - возьмите tcpdump. Разобрались? Да, совсем на пальцах: natd, помимо того, что userspace'овый, еще и ни одного раза не является компонентой ipfw. И ЧТО ИЗ ЭТОГО? Он не работает? Да, он медленее, чем ipnat, но, очевидно, XoRe его производительности хватает, и он умеет им пользоваться. Кстати, от natd переходить нужно скорее на netgraph, а не на ipnat (IMHO). У XoRe проблема вовсе не в том, что он пользуется ipfw, а в том, что ему не хватает идеи, как совместить nat и динамические правила ipfw в одну стройную систему. Еще более конкретно - не хватает знаний, что конструкция skipto ... keep-state - работает именно так, как ожидается. Сказал же: завязывайте с natd. Есть ничем не хуже pf и ipnat.1. Ты типа командир?2. Завязывай с FreeBSD. Есть ничем не хуже Cisco и Juniper. 3. Кстати, опять безапеляционное заявление. Уверен, что совсем-совсем ничем не хуже? Изменено 26 марта, 2007 пользователем Kuzmich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 26 марта, 2007 · Жалоба Kuzmich, относительно твоих "домашних заданий" - таки да, командир. Относительно твоего "настроено и работает" - вот давеча в одной дискуссии упоминали SELECT по смещению в MS SQL. Таки да, работает, но говорят, что прикручивание сего идёт через ректоскопию головного мозга. А работает ведь. Читали про проблемы программистов, которые плохо организуют свой код (особенно, если это ООП) и которые потом рвут волосы далеко не на голове, когда приходится делать рефакторинг? А теперь на пальцах: вешать трапперы для форварднутых пакетов на конечных адресатах форвардов, как в варианте с ipfw, называется в народе "через ж*пу". Когда вдруг случится ситуация с переадресацией домена, вместо одного конфига придётся править десятки (хотя, конечно, зависит от количества маскированных таким образом компов). И теперь отсюда сделаем вывод: дабы человек не влез в коровий помёт изначально, будучи обманут улыбчивыми микки маусами, раздающими налево-направо листовки с "Как заработать миллионы за 10 минут" и бесплатной же "жувачкой", я лучше расскажу сразу человеку, что есть только один путь ДАО. Он его освоит, примет и реализует. После же, если не в болоте живёт, он может попробовать и варианты с ректоскопией, и даже, может быть, ему это понравится, но то будет чисто на его совести. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kuzmich Опубликовано 27 марта, 2007 · Жалоба Интересные у тебя пальцы, на которых ты объясняешь. Насыпать псевдопрофессионального жаргона, обвязав предлогами, и "типа в шоколаде". Особенно если по существу сказать нечего... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XoRe Опубликовано 6 сентября, 2007 · Жалоба 2GateKeeper: Про свободу выбора что-нибудь слышали? 2Kuzmich: Дело не в динамических правилах. Я вообще не использую динамические правила в своих фаерволлах. Во первых, не чувстую в них нужды. Во вторых, при возникновении проблем, не хочу добавлять себе работы с тестированием опций sysctl: net.inet.ip.fw.dyn_keepalive net.inet.ip.fw.dyn_short_lifetime net.inet.ip.fw.dyn_udp_lifetime net.inet.ip.fw.dyn_rst_lifetime net.inet.ip.fw.dyn_fin_lifetime net.inet.ip.fw.dyn_syn_lifetime net.inet.ip.fw.dyn_ack_lifetime net.inet.ip.fw.dyn_max net.inet.ip.fw.dyn_count net.inet.ip.fw.curr_dyn_buckets net.inet.ip.fw.dyn_buckets А мне 100% пришлось бы их тестировать, когда я доказывал одному из наших провайдеров, что проблема не на моей стороне. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...