[XoRe]

Стоит машинка на 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 видел, с какого адреса из интернета к нему идет подключение.

Подскажите, пожалуйста, решение для сей ситуации.

[GateKeeper]

Насколько знаю, fwd в ipfw и rdr в pf - это stateful правила (в последнем - так уж точно). А stateful как раз и позволяет определить, как отправлять ответный пакет.

[XoRe]

Статья 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 неоткуда создаться при такой настройке.

[GateKeeper]

Да. Перечитал 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

[Kuzmich]

Да. Перечитал 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....

[GateKeeper]

             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.

[Kuzmich]

Домашнее задание не выполнено.

 

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 ?

[GateKeeper]

Kuzmich, давай я тебе щас пару заданий бредовых накину, а потом так же за невыполнение отчитывать буду?

 

Сказал же: завязывайте с natd. Есть ничем не хуже pf и ipnat.

[Kuzmich]

Вот когда я сморожу очередную фигню типа "неможет быть, потому что не может быть никогда" - тогда и накидаешь.

[GateKeeper]

Kuzmich. Тыкаю носом в фигню: на слова "ipfw не умеет" начались пространные разглагольствования на тему "вот если бы еще присобачить вот это и сверху прикрутить такой костыль, а костыль подпереть такой-то чугунной чушкой...", и при этом какие-то попытки всучить вот эти извращения в качестве "домашнего задания"... "Лечиться тебе надо, дядя Фёдор".

 

Да, совсем на пальцах: natd, помимо того, что userspace'овый, еще и ни одного раза не является компонентой ipfw.

 

Так что, домашнее задание: читать man pf, man ipnat и много-много думать. Заодно перевести у твоего преподавателя по английскому вышепроцитированный текст из мана ipfw.

[Kuzmich]

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

[GateKeeper]

Kuzmich, относительно твоих "домашних заданий" - таки да, командир.

 

Относительно твоего "настроено и работает" - вот давеча в одной дискуссии упоминали SELECT по смещению в MS SQL. Таки да, работает, но говорят, что прикручивание сего идёт через ректоскопию головного мозга. А работает ведь.

 

Читали про проблемы программистов, которые плохо организуют свой код (особенно, если это ООП) и которые потом рвут волосы далеко не на голове, когда приходится делать рефакторинг?

 

А теперь на пальцах: вешать трапперы для форварднутых пакетов на конечных адресатах форвардов, как в варианте с ipfw, называется в народе "через ж*пу". Когда вдруг случится ситуация с переадресацией домена, вместо одного конфига придётся править десятки (хотя, конечно, зависит от количества маскированных таким образом компов). И теперь отсюда сделаем вывод: дабы человек не влез в коровий помёт изначально, будучи обманут улыбчивыми микки маусами, раздающими налево-направо листовки с "Как заработать миллионы за 10 минут" и бесплатной же "жувачкой", я лучше расскажу сразу человеку, что есть только один путь ДАО. Он его освоит, примет и реализует. После же, если не в болоте живёт, он может попробовать и варианты с ректоскопией, и даже, может быть, ему это понравится, но то будет чисто на его совести.

[Kuzmich]

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

[XoRe]

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% пришлось бы их тестировать, когда я доказывал одному из наших провайдеров, что проблема не на моей стороне.