ipfw me
Sergey Zabolotny
ipfw не умеет конструкцию типа allow ip from me to any out xmit iface1 где me в
данном случае будет айпи адрес интерфеса iface1?
неудобно как-то каждый раз передергивать файрвол после того как по dhcp пришел
новый адрес.
Vladimir Usenko
dhcpclient.conf имеет пунктик script, с помощью которого можно
осуществлять обработку нового адреса, вместе с дерганимем ipfw.
--
UV-RIPE
Vadim Goncharov
On Mon, 20 Oct 2008 12:17:44 +0400; Sergey Zabolotny wrote about 'ipfw me':
SZ> ipfw не умеет конструкцию типа allow ip from me to any out xmit iface1 где me в
SZ> данном случае будет айпи адрес интерфеса iface1?
SZ> неудобно как-то каждый раз передергивать файрвол после того как по dhcp пришел
SZ> новый адрес.
Почему это не умеет? Именно так, как написано, и будет работать, без
передергиваний и явных указаний адреса.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Andrey Voitenkov
> Hi Sergey Zabolotny!
>
> On Mon, 20 Oct 2008 12:17:44 +0400; Sergey Zabolotny wrote about 'ipfw me':
>
> SZ> ipfw не умеет конструкцию типа allow ip from me to any out xmit iface1 где me в
> SZ> данном случае будет айпи адрес интерфеса iface1?
> SZ> неудобно как-то каждый раз передергивать файрвол после того как по dhcp пришел
> SZ> новый адрес.
>
> Почему это не умеет? Именно так, как написано, и будет работать, без
> передергиваний и явных указаний адреса.
>
me - это не любой адрес хоста, а именно адрес этого интерфейса, на котором
срабатывает правило?
--
mccloud@
Vadim Guchenko
You wrote to Vadim Goncharov on Tue, 21 Oct 2008 13:10:35 +0000 (UTC):
SZ>>> ipfw не умеет конструкцию типа allow ip from me to any out xmit
SZ>>> iface1 где me в данном случае будет айпи адрес интерфеса iface1?
SZ>>> неудобно как-то каждый раз передергивать файрвол после того как по
SZ>>> dhcp пришел новый адрес.
>> Почему это не умеет? Именно так, как написано, и будет работать, без
>> передергиваний и явных указаний адреса.
AV> Точно?
AV> me - это не любой адрес хоста,
Любой.
AV> а именно адрес этого интерфейса, на котором срабатывает правило?
Вообще-то на одном интерфейсе может быть и не один ip-адрес. А что именно в
результате хочется получить? Зачем понадобилось такое странное правило?
--
Best regards, Vadim.
Andrey Voitenkov
[...]
> SZ>>> ipfw не умеет конструкцию типа allow ip from me to any out xmit
> SZ>>> iface1 где me в данном случае будет айпи адрес интерфеса iface1?
> SZ>>> неудобно как-то каждый раз передергивать файрвол после того как по
> SZ>>> dhcp пришел новый адрес.
> >> Почему это не умеет? Именно так, как написано, и будет работать, без
> >> передергиваний и явных указаний адреса.
> AV> Точно?
> AV> me - это не любой адрес хоста,
>
> Любой.
>
> AV> а именно адрес этого интерфейса, на котором срабатывает правило?
>
> Вообще-то на одном интерфейсе может быть и не один ip-адрес. А что именно в
> результате хочется получить? Зачем понадобилось такое странное правило?
>
тот же интерфейс, на который пришел запрос. После PF'овского
from any to ($ext_if1) хочется чего-то аналогичного в ipfw, особенно
если адрес по dhcp получем.
Я сейчас горожу вот такое:
fwd tablearg ip from table(3) to any out { xmit rl1 or xmit ed0 }
а уже dhclient подставляет нужное в table(3).
--
mccloud@
Vladimir Usenko
> From: Andrey Voitenkov <for-ne...@mccloud.kiev.ua>
system.
--
UV-RIPE
Vadim Goncharov
On Tue, 21 Oct 2008 13:10:35 +0000 (UTC); Andrey Voitenkov wrote about 'Re: ipfw me':
SZ>>> ipfw не умеет конструкцию типа allow ip from me to any out xmit iface1 где me в
SZ>>> данном случае будет айпи адрес интерфеса iface1?
SZ>>> неудобно как-то каждый раз передергивать файрвол после того как по dhcp пришел
SZ>>> новый адрес.
AV>>
AV>> Почему это не умеет? Именно так, как написано, и будет работать, без
AV>> передергиваний и явных указаний адреса.
AV>>
AV> Точно?
AV> me - это не любой адрес хоста, а именно адрес этого интерфейса, на котором
AV> срабатывает правило?
Любой, конечно. Hо в норме там адресу другого интерфейса неоткуда взяться.
Hе могу представить, зачем оно именно так понадобилось на практике.
Vadim Goncharov
On Tue, 21 Oct 2008 14:38:09 +0000 (UTC); Andrey Voitenkov wrote about 'Re: ipfw me':
SZ>>>>> ipfw не умеет конструкцию типа allow ip from me to any out xmit
SZ>>>>> iface1 где me в данном случае будет айпи адрес интерфеса iface1?
SZ>>>>> неудобно как-то каждый раз передергивать файрвол после того как по
SZ>>>>> dhcp пришел новый адрес.
AV>>>> Почему это не умеет? Именно так, как написано, и будет работать, без
AV>>>> передергиваний и явных указаний адреса.
AV>>> Точно?
AV>>> me - это не любой адрес хоста,
AV>>
AV>> Любой.
AV>>
AV>>> а именно адрес этого интерфейса, на котором срабатывает правило?
AV>>
AV>> Вообще-то на одном интерфейсе может быть и не один ip-адрес. А что именно в
AV>> результате хочется получить? Зачем понадобилось такое странное правило?
AV>>
AV> Инициатору треда - хз зачем, мне обычно нужно для отправки ответов через
AV> тот же интерфейс, на который пришел запрос. После PF'овского
AV> from any to ($ext_if1) хочется чего-то аналогичного в ipfw, особенно
AV> если адрес по dhcp получем.
Дык в том же pf это делается через reply-to без использования адреса
интерфейса. А если через ext_if1 пришел пакет на адрес ext_if2, что тогда?
Отвечать-то по постановке задачи все равно надо через ext_if1.
AV> Я сейчас горожу вот такое:
AV> fwd tablearg ip from table(3) to any out { xmit rl1 or xmit ed0 }
AV> а уже dhclient подставляет нужное в table(3).
В описании packet flow через ipfw я приводил пример, как на skipto, tag и
keep-state сделать fwd на нужный интерфейс как аналог reply-to. Alex Bakhtin
же в прошлом году приводил полный рулесет исходящей per flow балансировки
через несколько интерфейсов на той же технологии.
Lev Serebryakov
22 Oct 08 10:21, you wrote to Andrey Voitenkov:
VG> В описании packet flow через ipfw я приводил пример, как на skipto,
VG> tag и keep-state сделать fwd на нужный интерфейс как аналог reply-to.
VG> Alex Bakhtin же в прошлом году приводил полный рулесет исходящей per
VG> flow балансировки через несколько интерфейсов на той же технологии.
Кстати, а оно где-то выложено в определённом месте, или лзеть в гугль-групс и
искать?
// Lev
Andrey Voitenkov
[...]
> AV>> результате хочется получить? Зачем понадобилось такое странное правило?
> AV>>
> AV> Инициатору треда - хз зачем, мне обычно нужно для отправки ответов через
> AV> тот же интерфейс, на который пришел запрос. После PF'овского
> AV> from any to ($ext_if1) хочется чего-то аналогичного в ipfw, особенно
> AV> если адрес по dhcp получем.
>
> Дык в том же pf это делается через reply-to без использования адреса
> интерфейса. А если через ext_if1 пришел пакет на адрес ext_if2, что тогда?
> Отвечать-то по постановке задачи все равно надо через ext_if1.
>
где есть "провайдер_А" и "провайдер_Б", которые друг о друге в данном
случае не знают и прислать такой пакет не должны по определению.
> AV> Я сейчас горожу вот такое:
> AV> fwd tablearg ip from table(3) to any out { xmit rl1 or xmit ed0 }
> AV> а уже dhclient подставляет нужное в table(3).
>
> В описании packet flow через ipfw я приводил пример, как на skipto, tag и
> keep-state сделать fwd на нужный интерфейс как аналог reply-to. Alex Bakhtin
> же в прошлом году приводил полный рулесет исходящей per flow балансировки
> через несколько интерфейсов на той же технологии.
>
Да, помню тот пост. Hо там, если не ошибаюсь, была концовка в виде
fwd $gate1 tagged 1, это сложнее, чем одна табличка на все случаи.
Да и keep-state я страсть как не люблю без крайней необходимости.
У меня настройки предельно тупые, вот типовая конфигурация
а-ля "офис на 20 человек":
00110 nat 1 ip from any to me in recv ed0
00115 nat 1 ip from 10.0.0.0/27 to any out xmit ed0
00210 nat 2 ip from any to me in recv rl1
00215 nat 2 ip from 10.0.0.0/27 to any out xmit rl1
00350 fwd 127.0.0.1,25 tcp from 10.0.0.0/27 to any dst-port 25
00400 nat 3 ip from any to any via tap0
51000 fwd tablearg ip from table(3) to any out { xmit rl1 or xmit ed0 }
51190 deny ip from not X.X.X.X to any out xmit ed0
51290 deny ip from not me to any out xmit rl1
65535 allow ip from any to any
И всё.
Тут два провайдера, ed0 - основной, адсл, статический
адрес и маршрут, всё вбито прямо в скрипт запуска файрвола.
Второй - rl1, запасной канал с динамическим адресом,
из-за него некрасивое правило 51290, где вместо me хорошо
бы поставить адрес интерфейса. Hу и табличка тоже не верх
совершенства.
Единственный стейт, который тут есть - это nat, другие
мне не нужны, там никто не слушает лишние интерфейсы и/или ip.
Два deny в конце режут всё, что не попало в nat. Остальное можно.
А предельная простота, в свою очередь, нужна по экономическим
соображениям. Быстрее (и дешевле) настроить, меньше времени
(и денег) на обслуживание, ну и в случае ЧП такой конфиг очень легко
прочитать глазами. Когда таких машинок десятки в разных местах
с небольшими отличиями конфигурации, простота становится решающим
фактором для выбора.
Обычно я на PF строю этот конфиг, там оно еще проще и читабельнее
выглядит, но есть несколько машинок, где вылазит глюк со скоростью
и route-to/reply-to в семерке, вот там как раз такая штука полезна.
--
mccloud@
Vadim Goncharov
On Wed, 22 Oct 2008 12:09:44 +0400; Lev Serebryakov wrote about 'ipfw me':
VG>> В описании packet flow через ipfw я приводил пример, как на skipto,
VG>> tag и keep-state сделать fwd на нужный интерфейс как аналог reply-to.
VG>> Alex Bakhtin же в прошлом году приводил полный рулесет исходящей per
VG>> flow балансировки через несколько интерфейсов на той же технологии.
LS> Кстати, а оно где-то выложено в определённом месте, или лзеть в гугль-групс и
LS> искать?
http://nuclight.livejournal.com/124348.html
Vadim Goncharov
On Wed, 22 Oct 2008 10:58:56 +0000 (UTC); Andrey Voitenkov wrote about 'Re: ipfw me':
AV>>> Я сейчас горожу вот такое:
AV>>> fwd tablearg ip from table(3) to any out { xmit rl1 or xmit ed0 }
AV>>> а уже dhclient подставляет нужное в table(3).
AV>>
AV>> В описании packet flow через ipfw я приводил пример, как на skipto, tag и
AV>> keep-state сделать fwd на нужный интерфейс как аналог reply-to. Alex Bakhtin
AV>> же в прошлом году приводил полный рулесет исходящей per flow балансировки
AV>> через несколько интерфейсов на той же технологии.
AV>>
AV> Да, помню тот пост. Hо там, если не ошибаюсь, была концовка в виде
AV> fwd $gate1 tagged 1, это сложнее, чем одна табличка на все случаи.
Hа самом деле, имхо проще - вся конфигурация сосредоточена в ipfw, в том же
случае ЧП кроме вывода ipfw show придется еще искать, где заполняется таблица-
в нетривиальном месте, скрипте dhcp-клиента.
AV> Да и keep-state я страсть как не люблю без крайней необходимости.
А вот iptables и pf с ним по умолчанию работают и каждый чих на него
завязывают. Тот же reply-to внутри использует стейты, так что по вопросу
произодительности и потребления памяти это равнозначно.
AV> У меня настройки предельно тупые, вот типовая конфигурация
AV> а-ля "офис на 20 человек":
AV> 00110 nat 1 ip from any to me in recv ed0
AV> 00115 nat 1 ip from 10.0.0.0/27 to any out xmit ed0
AV> 00210 nat 2 ip from any to me in recv rl1
AV> 00215 nat 2 ip from 10.0.0.0/27 to any out xmit rl1
AV> 00350 fwd 127.0.0.1,25 tcp from 10.0.0.0/27 to any dst-port 25
AV> 00400 nat 3 ip from any to any via tap0
AV> 51000 fwd tablearg ip from table(3) to any out { xmit rl1 or xmit ed0 }
AV> 51190 deny ip from not X.X.X.X to any out xmit ed0
AV> 51290 deny ip from not me to any out xmit rl1
AV> 65535 allow ip from any to any
AV> И всё.
AV> Тут два провайдера, ed0 - основной, адсл, статический
AV> адрес и маршрут, всё вбито прямо в скрипт запуска файрвола.
AV> Второй - rl1, запасной канал с динамическим адресом,
AV> из-за него некрасивое правило 51290, где вместо me хорошо
AV> бы поставить адрес интерфейса. Hу и табличка тоже не верх
AV> совершенства.
AV> Единственный стейт, который тут есть - это nat, другие
AV> мне не нужны, там никто не слушает лишние интерфейсы и/или ip.
AV> Два deny в конце режут всё, что не попало в nat. Остальное можно.
Если там адсл, и на втором канале скорости тоже не высоки, то может иметь
смысл использовать natd multiple instances (появилось в 5.4 недокументированно,
задокументировали в мае в этом году) - можно привязывать внутренний стэйт в
нате сразу к адресу, в который натить, для балансировки удобно, например.
AV> А предельная простота, в свою очередь, нужна по экономическим
AV> соображениям. Быстрее (и дешевле) настроить, меньше времени
AV> (и денег) на обслуживание, ну и в случае ЧП такой конфиг очень легко
AV> прочитать глазами. Когда таких машинок десятки в разных местах
AV> с небольшими отличиями конфигурации, простота становится решающим
AV> фактором для выбора.
AV> Обычно я на PF строю этот конфиг, там оно еще проще и читабельнее
AV> выглядит, но есть несколько машинок, где вылазит глюк со скоростью
AV> и route-to/reply-to в семерке, вот там как раз такая штука полезна.
Что за глюк?
Andrey Voitenkov
[...]
> AV>> В описании packet flow через ipfw я приводил пример, как на skipto, tag и
> AV>> keep-state сделать fwd на нужный интерфейс как аналог reply-to. Alex Bakhtin
> AV>> же в прошлом году приводил полный рулесет исходящей per flow балансировки
> AV>> через несколько интерфейсов на той же технологии.
> AV>>
> AV> Да, помню тот пост. Hо там, если не ошибаюсь, была концовка в виде
> AV> fwd $gate1 tagged 1, это сложнее, чем одна табличка на все случаи.
>
> Hа самом деле, имхо проще - вся конфигурация сосредоточена в ipfw, в том же
> случае ЧП кроме вывода ipfw show придется еще искать, где заполняется таблица-
> в нетривиальном месте, скрипте dhcp-клиента.
>
Либо как у меня (/etc/dhclient-enter-hooks):
# modify pbr table in ipfw
${fwcmd} table 3 delete $old_ip_address
${fwcmd} table 3 add $new_ip_address $new_routers
Либо правка того правила, которое fwd $gate1 tagged 1
Тут можно было и $new_ip_address вместо me подставить, это скорее мои тараканы
с нежеланием трогать правила из скриптов.
> AV> Да и keep-state я страсть как не люблю без крайней необходимости.
>
> А вот iptables и pf с ним по умолчанию работают и каждый чих на него
> завязывают. Тот же reply-to внутри использует стейты, так что по вопросу
> произодительности и потребления памяти это равнозначно.
>
Там у меня тоже no state дописано где можно обойтись без стейтов,
хотя это новое умолчание было сюрпризом в семерке.
[...]
> AV> Единственный стейт, который тут есть - это nat, другие
> AV> мне не нужны, там никто не слушает лишние интерфейсы и/или ip.
> AV> Два deny в конце режут всё, что не попало в nat. Остальное можно.
>
> Если там адсл, и на втором канале скорости тоже не высоки, то может иметь
> смысл использовать natd multiple instances (появилось в 5.4 недокументированно,
> задокументировали в мае в этом году) - можно привязывать внутренний стэйт в
> нате сразу к адресу, в который натить, для балансировки удобно, например.
>
Как раз думаю об этом. Бо тот нат встроеный - это тихий ужас, глюк на глюке.
[...]
> AV> Обычно я на PF строю этот конфиг, там оно еще проще и читабельнее
> AV> выглядит, но есть несколько машинок, где вылазит глюк со скоростью
> AV> и route-to/reply-to в семерке, вот там как раз такая штука полезна.
>
> Что за глюк?
>
Hа некоторых машинах на семерке (7.0-RELEASE, 7.1-PRERELEASE) на amd64
вот такие конструкции (любая из них и обе вместе):
pass in on $ext_if reply-to ($ext_if $route_optima) inet all keep state
pass in on $int_if route-to ($ext_if $route_optima) from $white_ip_open to !$vpn_net
вызывают жуткие тормоза исходящих пакетов, которые под эти правила попадают.
Именно своих исходящих, проходящие уходят нормально. Исходящие - максимум килобайт
в секунду.
У меня всего два случая было. Одна железка безнадежно сдохла,
вторая - продакшн 24х7, там никакой возможности исследовать это дело сейчас нет.
Hа стенде никак поймать не удалось - всё работает без фокусов.
В гугле видел еще двух счастливчиков, которые с подобным сталкивались, тоже
без ответа.
--
mccloud@
Vadim Goncharov
On Thu, 23 Oct 2008 14:26:25 +0000 (UTC); Andrey Voitenkov wrote about 'Re: ipfw me':
AV>>>> В описании packet flow через ipfw я приводил пример, как на skipto, tag и
AV>>>> keep-state сделать fwd на нужный интерфейс как аналог reply-to. Alex Bakhtin
AV>>>> же в прошлом году приводил полный рулесет исходящей per flow балансировки
AV>>>> через несколько интерфейсов на той же технологии.
AV>> AV>>
AV>>> Да, помню тот пост. Hо там, если не ошибаюсь, была концовка в виде
AV>>> fwd $gate1 tagged 1, это сложнее, чем одна табличка на все случаи.
AV>>
AV>> Hа самом деле, имхо проще - вся конфигурация сосредоточена в ipfw, в том же
AV>> случае ЧП кроме вывода ipfw show придется еще искать, где заполняется таблица-
AV>> в нетривиальном месте, скрипте dhcp-клиента.
AV>>
AV> Hе, в любом случае гейт надо менять из скрипта.
AV> Либо как у меня (/etc/dhclient-enter-hooks):
AV> # modify pbr table in ipfw
AV> ${fwcmd} table 3 delete $old_ip_address
AV> ${fwcmd} table 3 add $new_ip_address $new_routers
AV> Либо правка того правила, которое fwd $gate1 tagged 1
А, гейт.. ну это да, fwd его хочет и при tagged.
AV> Тут можно было и $new_ip_address вместо me подставить, это скорее мои тараканы
AV> с нежеланием трогать правила из скриптов.
Hу с таблицей красивше, да.
AV>>> Да и keep-state я страсть как не люблю без крайней необходимости.
AV>>
AV>> А вот iptables и pf с ним по умолчанию работают и каждый чих на него
AV>> завязывают. Тот же reply-to внутри использует стейты, так что по вопросу
AV>> произодительности и потребления памяти это равнозначно.
AV>>
AV> Там у меня тоже no state дописано где можно обойтись без стейтов,
AV> хотя это новое умолчание было сюрпризом в семерке.
Я к тому, что следует иметь в виду, что это тоже стейт, потому что это иногда
может вылезать сюрпризами в неожиданных местах.
AV>>> Единственный стейт, который тут есть - это nat, другие
AV>>> мне не нужны, там никто не слушает лишние интерфейсы и/или ip.
AV>>> Два deny в конце режут всё, что не попало в nat. Остальное можно.
AV>>
AV>> Если там адсл, и на втором канале скорости тоже не высоки, то может иметь
AV>> смысл использовать natd multiple instances (появилось в 5.4 недокументированно,
AV>> задокументировали в мае в этом году) - можно привязывать внутренний стэйт в
AV>> нате сразу к адресу, в который натить, для балансировки удобно, например.
AV>>
AV> Как раз думаю об этом. Бо тот нат встроеный - это тихий ужас, глюк на глюке.
О piso@ в эхе я уже отзывался, кажется :) Еще есть ng_nat, полнофункциональная
неглючная замена ipfw nat (тоже ядерное), единственно что - динамически адрес
брать с интерфейса (и передергивать) не умеет, в отличие от natd/ipfw nat.
AV>>> Обычно я на PF строю этот конфиг, там оно еще проще и читабельнее
AV>>> выглядит, но есть несколько машинок, где вылазит глюк со скоростью
AV>>> и route-to/reply-to в семерке, вот там как раз такая штука полезна.
AV>>
AV>> Что за глюк?
AV>>
AV> Hа некоторых машинах на семерке (7.0-RELEASE, 7.1-PRERELEASE) на amd64
AV> вот такие конструкции (любая из них и обе вместе):
AV> pass in on $ext_if reply-to ($ext_if $route_optima) inet all keep state
AV> pass in on $int_if route-to ($ext_if $route_optima) from $white_ip_open to !$vpn_net
AV> вызывают жуткие тормоза исходящих пакетов, которые под эти правила попадают.
AV> Именно своих исходящих, проходящие уходят нормально. Исходящие - максимум килобайт
AV> в секунду.
AV> У меня всего два случая было. Одна железка безнадежно сдохла,
AV> вторая - продакшн 24х7, там никакой возможности исследовать это дело сейчас нет.
AV> Hа стенде никак поймать не удалось - всё работает без фокусов.
AV> В гугле видел еще двух счастливчиков, которые с подобным сталкивались, тоже
AV> без ответа.
В таких случаях можно попробовать отпрофилировать ядро...
Alex Bakhtin
Привет,
AV> Если там адсл, и на втором канале скорости тоже не высоки, то может иметь
AV> смысл использовать natd multiple instances (появилось в 5.4 недокументированно,
AV> задокументировали в мае в этом году) - можно привязывать внутренний стэйт в
AV> нате сразу к адресу, в который натить, для балансировки удобно, например.
AV>
AV> Как раз думаю об этом. Бо тот нат встроеный - это тихий ужас, глюк на глюке.
VG> О piso@ в эхе я уже отзывался, кажется :) Еще есть ng_nat, полнофункциональная
VG> неглючная замена ipfw nat (тоже ядерное), единственно что - динамически адрес
VG> брать с интерфейса (и передергивать) не умеет, в отличие от natd/ipfw nat.
Как только ng_nat научится фичам типа redirect_port - с ним можно
будет работать, а пока альтернативы ipfw nat я лично не вижу. Хотя даже
идея статически выставить NAT_BUF_LEN в 1024 байта абсолютно идиотская и в
результате требует обязательного прикладывания патча при апгрейде системы.
--
Best regards, Alex Bakhtin, CCIE #8439
AMT Group, Cisco Systems Gold Partner, http://www.amt.ru
Andrey Voitenkov
http://lists.freebsd.org/pipermail/freebsd-stable/2008-February/040412.html
--
mccloud@
Alex Bakhtin
Привет,
AV> Если там адсл, и на втором канале скорости тоже не высоки, то может иметь
AV> смысл использовать natd multiple instances (появилось в 5.4 недокументированно,
AV> задокументировали в мае в этом году) - можно привязывать внутренний стэйт в
AV> нате сразу к адресу, в который натить, для балансировки удобно, например.
AV>
AV> Как раз думаю об этом. Бо тот нат встроеный - это тихий ужас, глюк на глюке.
>>
VG> О piso@ в эхе я уже отзывался, кажется :) Еще есть ng_nat, полнофункциональная
VG> неглючная замена ipfw nat (тоже ядерное), единственно что - динамически адрес
VG> брать с интерфейса (и передергивать) не умеет, в отличие от natd/ipfw nat.
>>
>> Как только ng_nat научится фичам типа redirect_port - с ним можно
>> будет работать, а пока альтернативы ipfw nat я лично не вижу. Хотя даже
>> идея статически выставить NAT_BUF_LEN в 1024 байта абсолютно идиотская и в
>> результате требует обязательного прикладывания патча при апгрейде системы.
>>
AV> redirect_port как раз умеет:
AV> http://lists.freebsd.org/pipermail/freebsd-stable/2008-February/040412.html
Вот блин, спасибо. Это я видать год туда не смотрел. Т.е. единственный
минус - передергивать IP когда он меняется и от ipfw nat можно отказаться,
а там где ip статический вообще проблем нет? Попробую дома на выходных, тем
более вроде mpd умеет цеплять его в нужное место, тогда конфигурация ipfw
сильно упростится. Правда, в доке на mpd нигде не сказано что redirect_port
для ng_nat можно конфигурить прямо из mpd, в общем есть поле для
экспериментов.
Andrey Voitenkov
> >> Как только ng_nat научится фичам типа redirect_port - с ним можно
> >> будет работать, а пока альтернативы ipfw nat я лично не вижу. Хотя даже
> >> идея статически выставить NAT_BUF_LEN в 1024 байта абсолютно идиотская и в
> >> результате требует обязательного прикладывания патча при апгрейде системы.
> >>
> AV> redirect_port как раз умеет:
> AV> http://lists.freebsd.org/pipermail/freebsd-stable/2008-February/040412.html
>
> Вот блин, спасибо. Это я видать год туда не смотрел. Т.е. единственный
> минус - передергивать IP когда он меняется и от ipfw nat можно отказаться,
> а там где ip статический вообще проблем нет? Попробую дома на выходных, тем
> более вроде mpd умеет цеплять его в нужное место, тогда конфигурация ipfw
> сильно упростится. Правда, в доке на mpd нигде не сказано что redirect_port
> для ng_nat можно конфигурить прямо из mpd, в общем есть поле для
> экспериментов.
>
Я как-то пробовал только самую простую конфигурацию и без мпд - там да,
без проблем. Остальное еще не пробовал.
--
mccloud@
Alex Bakhtin
Привет,
AV> redirect_port как раз умеет:
AV> http://lists.freebsd.org/pipermail/freebsd-stable/2008-February/040412.html
>>
>> Вот блин, спасибо. Это я видать год туда не смотрел. Т.е. единственный
>> минус - передергивать IP когда он меняется и от ipfw nat можно отказаться,
>> а там где ip статический вообще проблем нет? Попробую дома на выходных, тем
AV> Я как-то пробовал только самую простую конфигурацию и без мпд - там да,
AV> без проблем. Остальное еще не пробовал.
Попробовал первый вариант. Получившаяся конструкция сильно напоминает
систему тонких веревочек, цепляющихся друг за друга, честно говоря
мне представляется провиженинг того, что получилось по сравнению с ipfw nat
- одна сплошная головная боль. Прикручивал к первой задаче - подключение к
локалке провайдера без mpd, адрес получаем по dhcp. Конфигурация nat живет
аж в трех местах:
start_if.vlan200 - создаем ноду и цепляем к ng_ipfw.
rc.firewall - собственно отправляем пакеты в ноду.
dhclient-script - задаем ip адрес.
И это в сравнении с ipfw nat, конфигурация котрого целиком и полностью
живет в rc.firewall. Пока вот такое вот впечатление. Может быть с mpd лучше
будет.
Eugene Grosbein
AB> start_if.vlan200 - создаем ноду и цепляем к ng_ipfw.
AB> rc.firewall - собственно отправляем пакеты в ноду.
AB> dhclient-script - задаем ip адрес.
AB> И это в сравнении с ipfw nat, конфигурация котрого целиком и
AB> полностью
AB> живет в rc.firewall. Пока вот такое вот впечатление.
DHCP у меня нет, а в остальном - конфигурацию всего я храню в /etc/rc.conf.
А остальные скрипты rcNG только используют её, например,
/usr/local/etc/rc.d/ng_nat начинается с:
# PROVIDE: ng_nat
# REQUIRE: ipfw
И создает все ноды и добавляет правила в ipfw по указаниям rc.conf,
редактировать его самого не надо. Минус start_if.XXX.
rc.firewall, конечно, редактируется.
Eugene
--
Между чудом и случайностью выбирай случайность - она лишь маловероятна,
а чудо невозможно.
Vadim Goncharov
On Fri, 24 Oct 2008 13:49:55 +0000 (UTC); Alex Bakhtin wrote about 'Re: ipfw me':
AV>> Если там адсл, и на втором канале скорости тоже не высоки, то может иметь
AV>> смысл использовать natd multiple instances (появилось в 5.4 недокументированно,
AV>> задокументировали в мае в этом году) - можно привязывать внутренний стэйт в
AV>> нате сразу к адресу, в который натить, для балансировки удобно, например.
AV>>
AV>> Как раз думаю об этом. Бо тот нат встроеный - это тихий ужас, глюк на глюке.
VG>> О piso@ в эхе я уже отзывался, кажется :) Еще есть ng_nat, полнофункциональная
VG>> неглючная замена ipfw nat (тоже ядерное), единственно что - динамически адрес
VG>> брать с интерфейса (и передергивать) не умеет, в отличие от natd/ipfw nat.
AB> Как только ng_nat научится фичам типа redirect_port - с ним можно
AB> будет работать, а пока альтернативы ipfw nat я лично не вижу. Хотя даже
AB> идея статически выставить NAT_BUF_LEN в 1024 байта абсолютно идиотская и в
AB> результате требует обязательного прикладывания патча при апгрейде системы.
Ты отстал от жизни, это уже полгода как закоммиттили (а обучил ему этому я еще
раньше). Правда, в mpd это, похоже, еще не было использовано, пинай его автора.
Vadim Goncharov
On Sun, 26 Oct 2008 19:23:45 +0000 (UTC); Alex Bakhtin wrote about 'Re: ipfw me':
AV>> redirect_port как раз умеет:
AV>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-February/040412.html
AB>>>
AB>>> Вот блин, спасибо. Это я видать год туда не смотрел. Т.е. единственный
AB>>> минус - передергивать IP когда он меняется и от ipfw nat можно отказаться,
AB>>> а там где ip статический вообще проблем нет? Попробую дома на выходных, тем
AV>> Я как-то пробовал только самую простую конфигурацию и без мпд - там да,
AV>> без проблем. Остальное еще не пробовал.
AB> Попробовал первый вариант. Получившаяся конструкция сильно напоминает
AB> систему тонких веревочек, цепляющихся друг за друга, честно говоря
AB> мне представляется провиженинг того, что получилось по сравнению с ipfw nat
AB> - одна сплошная головная боль. Прикручивал к первой задаче - подключение к
AB> локалке провайдера без mpd, адрес получаем по dhcp. Конфигурация nat живет
AB> аж в трех местах:
AB> start_if.vlan200 - создаем ноду и цепляем к ng_ipfw.
AB> rc.firewall - собственно отправляем пакеты в ноду.
AB> dhclient-script - задаем ip адрес.
AB> И это в сравнении с ipfw nat, конфигурация котрого целиком и полностью
AB> живет в rc.firewall. Пока вот такое вот впечатление. Может быть с mpd лучше
AB> будет.
У меня адреса статические, так что живет в одном месте. Я взял rc-скрипт от
Eugene Grosbein и допилил его на поддержку редиректов и произвольных правил
ipfw, в результате оно достаточно просто конфигурируется в привычном стиле
natd, в минимальном стиле оно даже само правила ipfw напишет:
ng_nat_nodes="natmsf natavt1 natavt2 natavt3 natavt4 natavt5 natavt6 natavt7"
ng_nat_natmsf_interface="fxp0"
ng_nat_natmsf_cookies="61 60"
ng_nat_natmsf_ipfw_rules="171 181"
ng_nat_natavt1_interface="$avt_nat_ext_ip1"
ng_nat_natavt1_cookies="82 72"
ng_nat_natavt1_ipfw_rules="172 182"
ng_nat_natavt1_ipfw_rule0="172 netgraph 72 { src-ip ${msf}.240/28 or src-ip 10.117.64.2 }"
ng_nat_natavt1_ipfw_rule1="182 netgraph 82 ip from any to $avt_nat_ext_ip1 in recv $extiface"
ng_nat_natavt1_redirect_port0="tcp 10.0.0.240:17240 17240"
ng_nat_natavt1_redirect_port0_description="Static tcp redirect for client 240"
ng_nat_natavt1_redirect_port1="udp 10.0.0.240:17240 17240"
ng_nat_natavt1_redirect_port1_description="Static udp redirect for client 240"
Благодаря поддержке полей описаний (ipfw nat их не умеет, кстати) я смог
сделать себе демона для NAT-PMP, чтобы приложения автоматически могли
редиректить порты, и думаю пропихнуть это дело автору miniupnpd.
Alex Bakhtin
Женя,
AB> start_if.vlan200 - создаем ноду и цепляем к ng_ipfw.
AB> rc.firewall - собственно отправляем пакеты в ноду.
AB> dhclient-script - задаем ip адрес.
AB> И это в сравнении с ipfw nat, конфигурация котрого целиком и
AB> полностью
AB> живет в rc.firewall. Пока вот такое вот впечатление.
EG> DHCP у меня нет, а в остальном - конфигурацию всего я храню в /etc/rc.conf.
EG> А остальные скрипты rcNG только используют её, например,
EG> /usr/local/etc/rc.d/ng_nat начинается с:
EG> # PROVIDE: ng_nat
EG> # REQUIRE: ipfw
Во-во. Скрпит я по ссылке видел. HО с динамическим адресом все
существенно хуже. Чтобы dhclient мог задать ip адрес для ng_nat необходимо
создавать ноды ДО запуска dhcpd, т.е. REQUIRE: netif - что естественным
образом конфликтует с REQUIRE: ipfw.
EG> И создает все ноды и добавляет правила в ipfw по указаниям rc.conf,
EG> редактировать его самого не надо. Минус start_if.XXX.
EG> rc.firewall, конечно, редактируется.
Опять же это не решает проблему 3 независимых NATов на разных
интерфейсах. В общем красивой конструкции не получается:( Hет, я не спорю
что разобраться и запустить можно, но вопрос в том - удасться ли вспомнить
через год полный список веревочек за которые надо подергать.
Alex Bakhtin
Привет,
VG> У меня адреса статические, так что живет в одном месте. Я взял rc-скрипт от
VG> Eugene Grosbein и допилил его на поддержку редиректов и произвольных правил
VG> ipfw, в результате оно достаточно просто конфигурируется в привычном стиле
VG> natd, в минимальном стиле оно даже само правила ipfw напишет:
VG> ng_nat_nodes="natmsf natavt1 natavt2 natavt3 natavt4 natavt5 natavt6 natavt7"
Т.е. много instances? Это хорошо, попробую. Осталось придумать как
решить проблему с dhcp... Буду пробовать когда появится время...
Eugene Grosbein
EG>> # PROVIDE: ng_nat
EG>> # REQUIRE: ipfw
AB> Во-во. Скрпит я по ссылке видел. HО с динамическим адресом все
AB> существенно хуже. Чтобы dhclient мог задать ip адрес для ng_nat необходимо
AB> создавать ноды ДО запуска dhcpd, т.е. REQUIRE: netif - что естественным
AB> образом конфликтует с REQUIRE: ipfw.
Hе понял пассажа про конфликт. Комбинировать с BEFORE: пробовал?
EG>> И создает все ноды и добавляет правила в ipfw по указаниям rc.conf,
EG>> редактировать его самого не надо. Минус start_if.XXX.
EG>> rc.firewall, конечно, редактируется.
AB> Опять же это не решает проблему 3 независимых NATов на разных
AB> интерфейсах.
А в чем проблема?
AB> В общем красивой конструкции не получается:( Hет, я не спорю
AB> что разобраться и запустить можно, но вопрос в том - удасться ли вспомнить
AB> через год полный список веревочек за которые надо подергать.
Всё надо в rc.conf прописывать и желательно комментировать,
а код вообще не править. В общем, старинный рецепт-то :-)
Eugene
--
Прекрасны тонко отшлифованная драгоценность; победитель, раненный в бою;
слон во время течки; река, высыхающая зимой; луна на исходе; юная женщина,
изнуренная наслаждением, и даятель, отдавший все нищим. (Дхарма)
Vadim Goncharov
On Mon, 27 Oct 2008 10:29:38 +0000 (UTC); Alex Bakhtin wrote about 'Re: ipfw me':
VG>> У меня адреса статические, так что живет в одном месте. Я взял rc-скрипт от
VG>> Eugene Grosbein и допилил его на поддержку редиректов и произвольных правил
VG>> ipfw, в результате оно достаточно просто конфигурируется в привычном стиле
VG>> natd, в минимальном стиле оно даже само правила ipfw напишет:
VG>> ng_nat_nodes="natmsf natavt1 natavt2 natavt3 natavt4 natavt5 natavt6 natavt7"
AB> Т.е. много instances? Это хорошо, попробую. Осталось придумать как
AB> решить проблему с dhcp... Буду пробовать когда появится время...
Можно пробовать дергать по событиям переполучения адреса по DHCP команду
/usr/local/etc/rc.d/ng_nat restart, тогда, если в конфиге указан интерфейс,
конфиг менять не придется, скрипт все сам сделает.