Discussion:
отличия ядерного и "безъядерного" NAT
(слишком старое сообщение для ответа)
Vassily Kiryanov
2014-11-29 10:44:09 UTC
Permalink
Hi All!

Где-то ошибаюсь в настройке in-kernel NAT, хотя на этой-же системе два других
in-kernel NAT работают безупречно. Подтолкните в нужную сторону, пожалуйста.

Hужно мне для части клиентов локалки разрешить прямой выход на некоторые IP в
интернете, для чего использую NAT и таблицы.

назначаю номера:
Table_Clients_TEST=19
Table_Servers_TEST=29

заполняю таблицы:
TESTserv='8.8.8.8'
TESTclnt='10.1.1.159'

немного нестандартно конфигурю natd:
alias_address white1_my
in_port 8667
out_port 8669
same_ports yes

заполняю правила файрвола:
# из интернета до обработки в natd
ipfw add 5008 divert 8667 ip from table($Table_Servers_TEST) to ${white1_my} in

# из интернета после обработки в natd но ещё "на входе"
ipfw add 5511 allow ip from table($Table_Servers_TEST) to
table($Table_Clients_TEST) in

# из интернета после обработки в natd но уже "на выходе"
ipfw add 5512 allow ip from table($Table_Servers_TEST) to
table($Table_Clients_TEST) out via ${if_gray0}

# из локалки наружу, до обработки natd
ipfw add 5513 divert 8669 ip from table($Table_Clients_TEST) to
table($Table_Servers_TEST) in via ${if_gray0}

# из локалки наружу, после обработки natd
ipfw add 5514 allow ip from ${white1_my} to table($Table_Servers_TEST)
in via ${if_gray0}

ну и дальше правило с fwd отправит пакет в один из трёх туннелей (ну или
потребуется ещё одно разрешающее правило, если отправлять по роутингу)

Работает прекрасно, и было-бы грех жаловаться, но решил переходить на in-kernel
NAT, заменяю правила 5008 и 5513 на
ipfw add 5008 nat 1 ip from table($Table_Servers_TEST) to ${white1_my} in
ipfw add 5513 nat 1 ip from table($Table_Clients_TEST) to
table($Table_Servers_TEST) in via ${if_gray0}

конфигурацию nat задаю как:
ipfw nat 1 config ip ${white1_my} same_ports redirect_port tcp jail_proxy:3128
3128

и работать оно перестаёт, source-IP в пакетах не заменяется с TESTclnt на
white1_my ну и все остальные правила соответсвенно оказываются "не при делах".
А сами пакеты после этого с тем-же серым исходным IP пытаются уйти по роутингу.


Всего хорошего. "За верную и прибыльную дружбу!" (c) Яго.
Vassily
Eugene Grosbein
2014-12-01 13:45:02 UTC
Permalink
29 ноя 2014, суббота, в 14:44 NOVT, Vassily Kiryanov написал(а):

VK> и работать оно перестаёт, source-IP в пакетах не заменяется с TESTclnt на
VK> white1_my ну и все остальные правила соответсвенно оказываются "не при
VK> делах".
VK> А сами пакеты после этого с тем-же серым исходным IP пытаются уйти по
VK> роутингу.

sysctl net.inet.ip.fw.one_pass=0 не забыл?

Eugene
Vassily Kiryanov
2014-12-01 13:24:45 UTC
Permalink
Hi ***@grosbein.net!

01 Dec 14 16:45, Eugene Grosbein wrote to Vassily Kiryanov:

VK>> и работать оно перестаёт, source-IP в пакетах не заменяется с
VK>> TESTclnt на white1_my ну и все остальные правила соответсвенно
VK>> оказываются "не при делах". А сами пакеты после этого с тем-же
VK>> серым исходным IP пытаются уйти по роутингу.

EG> sysctl net.inet.ip.fw.one_pass=0 не забыл?

Hет, не забыл, стоит именно равным нулю. Между работой и не работой отличие
только в двух правилах ipfw, касающихся divert и NAT. Идеи исчерпаны, есть
только мысль на freebsd-net подписаться и там Великих Гуру побеспокоить.

Всего хорошего. "За верную и прибыльную дружбу!" (c) Яго.
Vassily

Loading...