| 1.1, Христо Топов (?), 05:21, 01/11/2003 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А как разпределит трафик динамически между ети двумями входящими каналов для всех хостам в сети | | |
| |
| 2.2, McLone (?), 07:38, 11/11/2003 [^] [^^] [^^^] [ответить]
| +/– |
 Возможно придется вскоре строить такое у себя, напишу сюда чё и как... Заюзаю, пожалуй, ipf/ipnat методом round-robin по state-записям, наверное... (имеется ввиду и statefull-ICMP тоже :-) Aли OpenBSD'шный pf... Хотя глядя на сорцы/динамику development'a ipf 4.0 betas, надеюсь что доделают... | | |
|
| 1.3, Khul (?), 16:28, 23/04/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Все хорошо, красиво и удобно. Только работать не хочет.
"- Также не забудем "обратный" divert
ipfw add 60 divert 8672 ip from any to 212.1.1.1"
вот это правило молчит как партизан. Обратные пакеты уходят в неизвестном направлении. Не могу понять почему. | | |
| |
| 2.7, Phil (??), 12:17, 21/02/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Такая же проблема - они уходят не в неизвестном направлении а с дефаулт роутера =( ... соответственно твое правило не срабатывает. Бъюсь 3 день над этим - как разберусь - отпишу. | | |
| |
| 3.8, Phil (??), 12:45, 21/02/2007 [^] [^^] [^^^] [ответить]
| +/– |
По этой теме:
IPFIREWALL_FORWARD_EXTENDED нужно добавить в опции при сборке ядра. Иначе все будет ходить через дефаулт роутер (tcpdump ом проверьте), по этому и не срабатывает правило диверта обратного с дополнительного канала. Угробил на это 3 дня - Сарумян лучший =).
| | |
|
|
| 1.4, Мстислав (?), 17:43, 23/04/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Хочу сделать у себя подобное. Имеется машина с 3-мя сетевыми интерфейсами. 1-й внутренный (10.x.x.x), 2-й и 3-й внешние (линки на разных провов). Демон natd висит на одном из внешних. На второй внешний вешаться не хочет...Ессно, добавлять второго демона пытаюсь с ключами -a,-p и -n.
Что я делаю не так? Или так вообще работать не будет? | | |
| 1.6, Валера (??), 05:02, 26/04/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Привет.Не могу Нат настроить, для ппп...
Везде читаю для Фри 4.Х, а для 6?
Для ФРИБСД 4.4. все описывается вот так:
/sbin/ipfw add divert natd all from 192.168.11.199 to any via ng0
Но у МЕНЯ 6.0.!!!
Детальней:
подключение к Инету:tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 193.238.152.25 --> 193.238.152.1 netmask 0xffffffff
Подключение к mpd:
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1400
inet 192.168.10.1 --> 192.168.11.200 netmask 0xffffffff
ng1: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1400
inet 192.168.10.1 --> 192.168.11.199 netmask 0xffffffff
ng2 и т.д.
Надо натить: ng0,ng1,ng2...ngXX==>tun0
ИП известны для каждого отдельного ngXX и для каждого можно запустить свое правило(свой скрипт).
Это скорее постановка задачи, которую не могу решить...
ЗЫ:ОСЬ FreeBSD+ipfw+natd(хотя не принципиально)
А вопрос звучит так:
есть множество ngXX и tun0, надо что бы каждый из ngXX мог ходить в Сеть за tun0...
Помогите с реализацией? | | |
| |
| 2.11, dj_gans (?), 20:05, 02/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Привет.Не могу Нат настроить, для ппп...
>Везде читаю для Фри 4.Х, а для 6?
Была точно такая же задача, но немного другие условия:
локалка 192.168.0.1/27, на нее смотрит сетевуха xl0 с адресом 192.168.0.1
внешка через VPN 10.10.0.1, не нее смотрит fxp0 с адресом 10.10.12.22
прописываем mpd адреса нашей локалки:
pptp0:
new -i ng0 pptp0 pptp0
set ipcp ranges 192.168.0.1/32 192.168.0.21/32
load pptp_standart
и т.п.
далее рулим их из-под ната во внешку, на которую смотрит fxp0:
/sbin/ipfw add 1 divert natd all from 192.168.0.0/27 to any out via fxp0
/sbin/ipfw add 2 divert natd all from any to 10.10.12.22 in via fxp0
т.е. при входящем подключении через mpd клиент попалает в локалку, а из нее, как все, во внешку. замечания/предложения приветствуются.
| | |
|
| 1.9, Artem (??), 15:25, 07/08/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 IPFIREWALL_FORWARD_EXTENDED при попытке добавить в ядро этой опции отвечает
unknown option "IPFIREWALL_FORWARD_EXTENDED"
FreeBSD 6.2
| | |
| |
| 2.10, togkskbr (??), 17:13, 02/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>IPFIREWALL_FORWARD_EXTENDED при попытке добавить в ядро этой опции отвечает
>unknown option "IPFIREWALL_FORWARD_EXTENDED"
>FreeBSD 6.2
почитай файл NOTES (расположение читай в аннотации к GENERIC)
| | |
|
| 1.13, Серей (?), 18:27, 23/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 здраствуйте, ситуация идентичная, только нат у меня 1 и его весь хочу отправить через альтернативный шлюз. Но как ни старался, все что получается - это все запросы идут через дефолтовый (после ната), а возврат идет через альтернативный. Причем адрес источника - айпишник альтернативного интерфейса(нат отрабатывает красиво). По какойто причине не срабатывает форвард. На альтернативном интерфейсе нет ниодного исходящего пакета. Хелп.
| | |
| |
| |
| 3.15, zuborg (?), 14:28, 21/04/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Скорей всего проблема не в том что fwd не работает, а в том что tcpdump этого не показывает
Сам целый день голову ломал, как починить.
Оказалось, что если на локал-хосте смотреть через tcpdump, то можно видеть что траф идет через default интерфейс, или вообще никудой не идет, тогда как fwd отрабатывает нормально и пакеты идут так как настроено.
Проверить можно tcpdump-ом на удаленной стороне, или даже банальным выдергиванием кабеля из вторичного интерфейса - пакеты перестанут проходить (хотя раньше проходили и tcpdump показывал что они шли и идут через основной интерфейс)
Проверено для 7.0, другие не проверял
| | |
|
|
| 1.16, Alex (??), 10:19, 23/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Здравствуйте! Проблема с natd. На сервере 2 сетевых карты, для локалки и интернета, кроме того есть туннель через gif0. Не могу настроить чтобы трафик заворачивался из туннеля. Мой трафик туда уходит, ответы tcpdump показывает, но они не попадают в divert а исчезают бесследно.
Правила ipfw:
00010 count log logamount 500 ip from any to any via gif0
00100 count ip from any to any in recv dc0
00200 count ip from any to any out xmit dc0
00300 count tcp from any to me 25 in recv dc0
00310 count tcp from any 80,443 to me in recv dc0
00410 allow ip from any to any via lo0
00510 allow ip from 194.39.131.174 to any
00610 allow ip from any to 194.39.131.174
00710 allow esp from any to any
00810 allow ipencap from any to any
00910 allow udp from any to any 500
01010 divert 8765 log logamount 500 ip from 192.168.10.203 to 194.117.106.129 out xmit gif0
01110 divert 8765 log logamount 500 ip from 194.117.106.129 to any
4 дня провел за чтением манов и поиском информации в Интернете. Ничего не помогло...
| | |
| |
| 2.17, Alex (??), 06:54, 25/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
Дополнение: туннель ipsec.
Проблема решилась пересборкой ядра с параметром IPSEC_FITERGIF.
| | |
|
| 1.18, Евгений (??), 11:10, 08/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Здравствуйте!
У меня вопрос. А если у меня NAT построен не на natd, а на ipnat (ipf)? Пишу в ipfw правило ipfw add 15 fwd x.x.x.1 all from y.y.y.y/32 to not me in recv xl0 (xl0 - локалка, xl1 - основной канал, xl2 - дополнительный)
map xl1 y.y.y.0/24 -> z.z.z.z/32 proxy port ftp ftp/tcp
map xl1 y.y.y.0/24 -> z.z.z.z/32 portmap tcp/udp 40000:65000
map xl1 y.y.y.0/24 -> z.z.z.z/32
map xl2 y.y.y.0/24 -> x.x.x.2/32 proxy port ftp ftp/tcp
map xl2 y.y.y.0/24 -> x.x.x.2/32 portmap tcp/udp 40000:65000
map xl2 y.y.y.0/24 -> x.x.x.2/32
tcpdump показывает, что пакеты форвардятся, но предварительно пройдя через нат и получив IP = z.z.z.z, тот который на основном интерфейсе xl1
udp пакеты (traceroute) при этом бегают так как и хотелось бы, а вот tcp :( Как побороть эту проблему?
| | |
|
