Paolo Pisati в списке рассылки freebsd-hackers сообщил (http://lists.freebsd.org/pipermail/freebsd-hackers/2005-Sept...) о завершении работ по улучшению libalias во FreeBSD.
Paolo работал над libalias в рамках программы Google "Summer of Code", основные направления его работы:
- перенос libalias в kernel mode;
- интеграция с ipfw;
- изменение организации библиотеки для более простого расширения.
URL: http://lists.freebsd.org/pipermail/freebsd-hackers/2005-Sept...
Новость: http://www.opennet.me/opennews/art.shtml?num=6038
Отличная новость!
а чем оно примечательно?
Просветите плиз.
здорово!!!!!!
тем что нат'ить будет в ядре а не в юзермоде -- соответсвенно, производительность гораздо выше. И natd не нужен
А в 6.0 релизе это будет?
В 6.0 есть ng_nat ;-)
наконется во фре можно будет натить без переключения контекстов
Очень давно можно было. IPFilter рулит!
pf опять же
pf не умеет менять порядок трансляция-фильтрация в зависимости от направления прохождения пакета. Только из-за этого его в топку, несмотря а все вкусности.
Это кто-ж тебе такое сказал ???
Примеры на бочку !
Какие тебе примеры, man читай. Мне нужно, чтобы для входящих пакетов сначала была трансляция, потом фильтрация, для исходящих наоборот. Причины, надеюсь, понятны?Жду примеров от вас.
причина непонятна....
....а вообще-то
man(5)pf.conf
на предмет set require-order
Именно поэтому и читайте ман. Порядок жестко задан, независимо от направления прохождения пакетов. Если не понятна причина - разговаривать не о чем.
Ок! вижу читать надо группой и вслух (для особо глухих/слепых/немых)...
итак
>man 5 pf.conf->
STATEMENT ORDER
There are seven types of statements in pf.conf:Macros
User-defined variables may be defined and used later, simplifying
the configuration file. Macros must be defined before they are
referenced in pf.conf.Tables
Tables provide a mechanism for increasing the performance and flex-
ibility of rules with large numbers of source or destination ad-
dresses.Options
Options tune the behaviour of the packet filtering engine.Traffic Normalization (e.g. scrub)
Traffic normalization protects internal machines against inconsis-
tencies in Internet protocols and implementations.Queueing
Queueing provides rule-based bandwidth control.Translation (Various forms of NAT)
Translation rules specify how addresses are to be mapped or redi-
rected to other addresses.Packet Filtering
Stateful and stateless packet filtering provides rule-based block-
ing or passing of packets.With the exception of macros and tables, the types of statements should
be grouped and appear in pf.conf in the order shown above, as this match-
es the operation of the underlying packet filtering engine. By default
pfctl(8) enforces this order (see set require-order below).
->
видим, что нас отсылают смотреть ниже set require-order, если нас вдруг не устраивает нормальный ход вещей....
->
set require-order
By default pfctl(8) enforces an ordering of the statement types in
the ruleset to: options, normalization, queueing, translation,
filtering. Setting this option to no disables this enforcement.
There may be non-trivial and non-obvious implications to an out of
order ruleset. Consider carefully before disabling the order en-
forcement.
->
обращаем внимание на вполне разумное предостережение "...non-trivial and non-obvious...",
и если после этого мы еще всетаки очень хотим этого, то как говорится в каком-то посте ниже "...включаем фантазию...", попутно полезно перечитать ман на предмет quick anchor skip on in|out etc., и вперед за фантазией....
>Какие тебе примеры, man читай. Мне нужно, чтобы для входящих пакетов сначала
>была трансляция, потом фильтрация, для исходящих наоборот. Причины, надеюсь, понятны?
Man-ы все читать умеют, а вот <...> не всегда.
" - хотел покрасить корову в синий металлик нитрокраской, но корова от этого сдохла, значит нитрокраску ф топку"
Вопрос в том зачем красить корову, а не какую краску выбрать.
По этому и просил пример, какую _рабочую_ задачу реализовать не получается и откуда такая задача возникает, в противном случае см. пример про корову.
>Какие тебе примеры, man читай. Мне нужно, чтобы для входящих пакетов сначала
>была трансляция, потом фильтрация, для исходящих наоборот. Причины, надеюсь, понятны?
>
>Жду примеров от вас.
Не вижу никаких сложностей, читайте ман и включайте фантазию.
NATD нормально отрабатывал пинги из внутренней локалки до одного и того же внешнего хоста, ipnat и pfnat мне не удалось заставить -- пингует только один из внутренних хостов, точнее ipnat и pfnat не раздают icmp от одной машины на несколько хостов.Если кто решил проблему -- поделитесь.
Ничего не понял. Кто на ком стоял... вернее кто кого пингал? У меня с PF всё замечательно пингуется - и внешнее и внутреннее.
Две машины за машиной с pfnat пингуют одновременно одну внешний хост. Пинги раздаются pfnat'ом только на одну из этих машин, по крайней мере у меня на ipnat и pfnat так. Кто подскажет в чем загвоздка буду крайне благодарен.
Странно как-то, у меня все нормально: OpenBSD & PF
Две машины из 192.168.0.0 отправляют ICMP echo request на 1.2.3.4 через NAT.
Происходит примерно следующее:gw#sh ip nat tra | incl 1.2.3.4
icmp 84.145.41.116:512 192.168.0.65:512 1.2.3.4:512 1.2.3.4:512
icmp 84.145.41.116:538 192.168.0.3:512 1.2.3.4:512 1.2.3.4:538Понимаете, да?
Так вот, если NATящий хост имеет кривую реализацию NAT, он не догадается изменить номер порта. (Для ICMP это поле смысла не несет, поэтому там стоит по умолчанию "512".)
В ICMP пакете поля "порт" нет. Вообще нет. За ненадобностью.
Спасибо, я как бы в курсе. Тем не менее, NAT overload, он же NPAT, он же "маскарадинг" оперирует понятием порта для мультиплексирования пакетов. Собственно, иначе оно и быть не может.
Т.е. вы хотите сказать, что в ipnat и pfnat кривая реализация? Может это просто фича и надо где-то ее включить?
>Т.е. вы хотите сказать, что в ipnat и pfnat кривая реализация? Может
>это просто фича и надо где-то ее включить?
Скорее всего речь идет о вот этом.
pf.c Revision 1.502 Mon Aug 22 11:54:25 2005 UTC by dhartmei
| when nat'ing icmp 'connections', replace icmp id with proxy values
| (similar to proxy ports for tcp/udp). not all clients use
| per-invokation random ids, this allows multiple concurrent
| connections from such clients.
| thanks for testing to Rod Whitworth, "looks ok" markus@
>В ICMP пакете поля "порт" нет. Вообще нет. За ненадобностью.зато есть понятие очереди, что по сути - тот же самый порт, только
один на двоих. В смысле при передаче UDP или TCP пакета порт
присутствует как у отправителя, так и у получателя. А у ICMP есть
понятие идентификатора очереди (Identifier) и номер пакета в этой
очереди (Sequence Number). См. формат кадра для ICMP пакетов с типом
echo message и echo replay message в rfc792.
На многочисленных серверах стоит связка ipfilter(+ipnat) и отлично справляется с фильтрацией и с трансляцией адресов.
Особо примечательно, что на очень слабых (386/486) машинах можно буквально за 10 минут поставить полноценный межсетевой экран и трансляцию адресов. Причём никакой пересборки ядра или чего-либо ещё не требуется (чтобы добавить DIVERT в ядро, для natd, например)! И работает очень быстро...
>Особо примечательно, что на очень слабых (386/486) машинах можно буквально за 10
>минут поставить полноценный межсетевой экран и трансляцию адресов. Причём никакой пересборки
>ядра или чего-либо ещё не требуется (чтобы добавить DIVERT в ядро,
>для natd, например)! И работает очень быстро...На OpenBSD ?
> pfnat не раздают icmp от одной машины на несколько хостов.в PF слова "keep state" на правиле, которое пропускает ICMP, стереть не пробовали?
Здесь все работает, и на Free- и на Open-.
Таки в RELENG_5 не пашет до сих пор (я не заметил - у меня другие версии этих файлов _ИЛИ_ random ID enforcement). Вот сторо заMFCят следующие версии, и будет Вам счастье:From: Max Laier <max at love2party dotnet>
To: freebsd-pf at freebsd dotorg
Date: Sep 6, 2005 5:47 PM
Subject: Bugfixes from OpenBSDI am going to import the following bugfixes from OpenBSD shortly:
...
pf.c Revision 1.502 Mon Aug 22 11:54:25 2005 UTC by dhartmei
| when nat'ing icmp 'connections', replace icmp id with proxy values
| (similar to proxy ports for tcp/udp). not all clients use per-invokation
| random ids, this allows multiple concurrent connections from such clients.
| thanks for testing to Rod Whitworth, "looks ok" markus@
divert можно добавить без пересборки ядра. и dummynet тоже.ls /boot/kernel
Вообще-то libalias был портирован в ядро еще весной, до Google SoC. Тогда же и ng_nat появился.
>Вообще-то libalias был портирован в ядро еще весной, до Google SoC. Тогда
>же и ng_nat появился.Если бы вы сходили по приведённым ссылкам, то прочитали бы там это.
libalias был перенесён в ядро только в 6-ке.
Этож какой надо бешенный траффик иметь, чтобы напрягал userland nat? Да его хватает всегда и загрузка процессора невелика. Вот что действительно хотелось бы увидеть в libalias - это возможность прозрачного проброса портов, потому как redirect_port этого не делает и смысл его вообще для меня теряется.
>увидеть в libalias - это возможность прозрачного проброса портов, потому как redirect_port этого не делает и смысл его вообще для меня теряется.А что он, по-твоему, делает? Блин, читайте man'ы, развелось Guest'ов...
Кстати, да. Только вчера отметил, что в одной ветке две вопиюще вызывающие чушы и никто ни слова не сказал. opennet становится lor-ом... :(
>>увидеть в libalias - это возможность прозрачного проброса портов, потому как redirect_port этого не делает и смысл его вообще для меня теряется.
>
>А что он, по-твоему, делает? Блин, читайте man'ы, развелось Guest'ов...
А вникнуть в суть проблемы? Яж не с потолка это взял. redirect_port пробрасывает соединения, инициируя новые на алиасеном интерфейсе. То бишь не видно на машине на которую проброс - откуда пришло соединение, все идет от машины с natd. Вот это мне и не нравится, хотелось бы знать откель пакеты пришли на ту же почту. А так "безликие" коннекты. Можете убедиться сами путем чтения man 3 libalias и непосредственно исходных текстов.
>А вникнуть в суть проблемы? Яж не с потолка это взял. redirect_port
>пробрасывает соединения, инициируя новые на алиасеном интерфейсе. То бишь не видно
>на машине на которую проброс - откуда пришло соединение, все идет
>от машины с natd. Вот это мне и не нравится, хотелосьИнтересно.. Т.е. Вы хотите чтобы хост с реальным IP адресом мог свободно общаться с вашим сервером, находящимся в левой сети, причём со своим же реальным адресом? Перелистайте на досуге книжку по протоколу IP, по маршрутизации и т.д.. Вам, батенька, не НАТ надо юзать в таком случае..
Да нет же. Просто то же самое что делает ipnat ( map в ipnat.conf). То есть алиасинг без инициации соединений. Вообщем смотрите внимательнее о чем речь, может быть то же что делают маршрутизаторы цисковские некоторые(или многие?), вот у меня стоит неподконтрольная мне циска, так с неё до почтовика пробрасывают порт 25, причем все соединения снаружи видны как интернетные, хотя машина имеет серый адрес, понимаете, нет? Вот чего хотелось бы видеть в libalias.
>как интернетные, хотя машина имеет серый адрес, понимаете, нет? Вот чего
>хотелось бы видеть в libalias.Что-то всёравно не понимаю в чём проблема.
Сейчас попробовал открыть 21 порт через redirect_port, FTP сервер внутри локалки видит реальный адрес клиента.
А у меня на 5.4 да и на 4.11 почему-то проброс "безликий". Пропихиваю порт с одной машины на другую и на той для которой пропихнул - видно соединение от машины с natd, а не с реального адреса с которого коннект.
Кто-то может подсказать как ipnat и ICMP подружить? Как настроить так чтобы изнутри был возможен пинг на один и тот-же Внешний IP сразу для нескольких внутренних IP.
Народ, прочитав все приведённые выше посты, я невольно поймал себя на мысли - а кто нить вообще испльзует ipfw? или ipfilter / pf настолько круты / или ipfw настолько плох?
я попытался на днях сделать перенос libalias в kernel mode. FreeBSD 5.4 .Скачал архив , распаковал, сделал все по инструкции.
После добавления правила типа
ipfw add 100 nat 555 ip from any to any
выдается ошибка ipfw: getsockopt(IP_FW_ADD): Invalid argument. Стал проверять, что я сделал не так, короче ниасилил. Написал Paolo Pisati, после его вопросов типа did you compile a new kernel after fix-base.sh? пересобрал еще раз ядро, результат такой же. Тогда попробовал сделать тоже самое на другой машине с FreeBSD 5.4 , результат тот же. Тогда Paolo попросил доступ на одну из моих тачек, чтобы показать что типа руки у меня кривые. Не вопрос - организовал. Через несколько часов он собрал ядро на которой все заработало, а попутно изменив инструкции по установке:
the correct procedure to compilet/install/use it is:1) dowload libalias.tgz && run fix-base.sh
2) recompile kernel (without ipfw) && reboot
3) compile and install libalias
4) kldload ipfw (if you have ipfw already loaded it's the
plain FreeBSD kld now, so reboot again)Все бы хорошо, только когда ipfw собирается через libalias и идет как ipfw.ko , там отсутствуют поддержка pipe log divert. divert может уже и не нужен становится, а вот остальное не плохо бы иметь.
Короче послал все и юзаю natd.