недостающий кусок к "ipfw: порядок прохождения пакетов, сложные случаи"

[nuclight]

К посту http://nuclight.livejournal.com/124348.html в свое время не всё влезло, из-за ограничений на объем поста в ЖЖ (судя по всему 65535 в байтах, причем UTF-8, так как для разной пропорции русского текста длина переменная и непредсказуемая). Ниже идет недостающий кусок, с того места, где

Comments

[dadv]

Текст действительно устарел, да и изначально содержал неточность. Я говорю о судьбе пакета после успешной расшифровки его реализацией KAME IPSEC в FreeBSD 6.x и ранее - пакет, действительно, попадает на L4 для локальной доставки и это может быть плохо - если на машине работает NAT, то правильней будет пропустить пакет через NAT и после этого может оказаться, что он предназначен вовсе не для локальной доставки, а для дальнейшего форвардинга по таблице роутинга, обычным путем

[_slw]

а можно еще добавить про ipfw nat?

и из man ipfw не понятен переход от длинного правила ipfw nat 123 config к пачке строчек ipfw nat 1 config .. ipfw nat 5 config.

там что, по инстансам будет бежать в порядке возрастания номеров? или надо будет кучу add nat добавлять?

[nuclight]

Его следует рассматривать как еще одну сущность за пределами, полностью аналогичную divert/dummynet/netgraph и т.д. Если упрощенно, то здесь полная аналогия с natd: ipfw nat - это конфиг инстанса ната в ядре, навроде процесса natd, только в ядре. Т.е. само по себе создание инстанса еще ничего не делает, хоть сотню их сделайте, на номера всем наплевать. Соответственно, реально трафик в него отправляется через ipfw add nat - и эти правила будут полностью аналогичны ipfw add divert, и пишутся по ровно тем же законам.

Вот только обвязка ipfw nat сделана довольно криво - когда у вас много редиректов или инстансов, оно начинает глючить. Причем это проблема именно конфигурялки. Некоторые для этого патчат ядро... ну в общем поищите в базе PR.

[_slw]

ну про недостаточность NAT_BUF_LEN я уже в курсе.

а непонятно следующее -- если по add nat отправлю трафик, который не попадает под редирект, например, он стухнет или вернется и на следующее правило пойдет? т.е. надо ли заморачиваться на check_state и всем остальным?

и опять же, к ману. вроде как из их примера следует эквивалентность предложенного разбиения на правила. из твоих слов следует противоположное.

[nuclight]

Я же сказал - абсолютно те же принципы, что и с divert в natd (если natd не модифицировал пакет, то и ipfw nat это не сделает). Абсолютно. Пишется точно так же. Ну, за исключением возврата на точно следующее, а не следующий номер (как в divert), и добавленной возможности one_pass. А что там конкретно в Вашем полном наборе правил происходит - это уж Вам на месте виднее.

>вроде как из их примера следует эквивалентность предложенного разбиения на правила. из твоих слов следует противоположное.

О чем конкретно речь? Вопрос мне был задан другой, на него я и ответил.