ipfw kernel nat (замена src address)

FreeBSD, NetBSD, OpenBSD, DragonFly и т. д.

Модератор: arachnid

Ответить
DoggoD
Сообщения: 71
ОС: debian, centos, freebsd

ipfw kernel nat

Сообщение DoggoD »

приветствую..
появилась необходимость сделать редирект tcp\25 порта на корпоративном шлюзе

Код: Выделить всё

root@server:~ # uname -a
FreeBSD server 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

конфиг ipfw такой:

root@server:~ # cat /etc/firewall.conf

#re0 -- интерфейс в LAN, имеет адрес 192.168.0.254 #rl0 -- интерфейс в WAN, имеет адрес 111.111.111.111 nat 1 config if rl0 deny_in same_ports unreg_only redirect_port tcp 192.168.0.10:25 25 add allow ip from any to any via re0 add skipto 11000 ip from any to any via rl0 add 11000 nat 1 ip from any to any via rl0 add 11999 skipto 65000 ip from any to any


nat работает, telnet с наружи конектится к 25 порту и нормально разговаривает с почтовым сервером 192.168.0.10, а проблема, собственно в том, что вся входящая почта, которая приходит имеет в заголовке неверный ip адрес источника

Код: Выделить всё

Received: from some.real.domain.com (unknown [192.168.0.254])

что вызывает определенные проблемы..
есть ли способ сделать так, чтобы адрес источника не маскировался при прохождении через пакетный фильтр?
ipfw add fwd пробовал -- не работает..
заранее спасибо..
Debian 5.0 Lenny, 2.6.26-1-686, KDE 3.5.10.
Asus P5E-VM SE, e8400.
Спасибо сказали:
Аватара пользователя
nerve
Сообщения: 280
ОС: OpenBSD

Re: ipfw kernel nat

Сообщение nerve »

Код: Выделить всё

natd -redirect_port tcp 192.168.0.10:25 25
Спасибо сказали:
Аватара пользователя
arachnid
Модератор
Сообщения: 1099
ОС: freeBSD

Re: ipfw kernel nat

Сообщение arachnid »

nerve писал(а):
29.03.2016 16:55

Код: Выделить всё

natd -redirect_port tcp 192.168.0.10:25 25

ну там у человека ядерный нат, а вы предлагаете то же самое через демон. хотя на самом деле надо указать на невозможность желаемого :)

внимательно вспоминаем расшифровку термина NAT, как он работает, как устроена сеть и понимаем, что в сети ipv4 желаемого не достигнуть.
-= freeBSD stable, fluxbox =-
"если ты будешь со мной спорить, я тебя запишу в книжечку!" (с) Ежик
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: ipfw kernel nat

Сообщение Bizdelnick »

arachnid писал(а):
31.03.2016 16:43
в сети ipv4 желаемого не достигнуть.

Это почему это? ТСу нужен самый банальный проброс порта, который умеет любой бытовой роутер.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
lazhu
Сообщения: 70
ОС: FreeBSD 9-STABLE / clang 3.3
Контактная информация:

Re: ipfw kernel nat

Сообщение lazhu »

Bizdelnick писал(а):
31.03.2016 17:12
arachnid писал(а):
31.03.2016 16:43
в сети ipv4 желаемого не достигнуть.

Это почему это? ТСу нужен самый банальный проброс порта, который умеет любой бытовой роутер.

У ТС и так работает проброс порта. Ему надо при этом, чтобы адрес файрвола не подставлялся вместо исходного. Как верно заметили выше, это невозможно.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: ipfw kernel nat

Сообщение Bizdelnick »

Да почему невозможно-то? Нужели в FreeBSD не осилили?
Ну смотрите: пусть шлюз имеет внешний адрес IP0, внутренний — IP1, почтовый сервер во внутренней сети — IP2. Приходит пакет извне с адреса IP3, порт p, на IP0:25. Шлюз пересылает его в неизменном виде на IP2:25. Тут вроде ничего невозможного нет? В обратную сторону: почтовый сервер с IP2:25 шлёт пакет на IP3:p через шлюз IP1. Шлюз в этом пакете заменяет адрес источника с IP2 на IP0, номер порта не трогает, потому что он застолблён за IP2. Тут есть что-то невозможное?
В linux это реализуется двумя правилами iptables (DNAT для пакетов с назначением IP0:25, SNAT для пакетов с источником IP2:25).
А то, что работает у ТСа, — это не проброс (port forwarding или port mapping), а перенаправление (redirection).
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
arachnid
Модератор
Сообщения: 1099
ОС: freeBSD

Re: ipfw kernel nat

Сообщение arachnid »

да, согласен. что-то туплю.

ну за это рецепт решения (проверенно)

правило самого ната

Код: Выделить всё

ipfw nat 20 config if <внешний_ip> redirect_port tcp <куда>:<какой_порт> <на каком порту ждем снаружи>


правила перенаправления в нат

Код: Выделить всё

ipfw nat 20 tcp from any to <внешний_ip> dst-port <на каком порту ждем снаружи> via <имя_внешнего_интерфейса>
ipfw nat 20 tcp from <ip_сервера, куда_перенаправляли> to any via <имя_внешнего интерфейса>


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



Bizdelnick писал(а):
01.04.2016 12:04
Да почему невозможно-то? Нужели в FreeBSD не осилили?
Ну смотрите: пусть шлюз имеет внешний адрес IP0, внутренний — IP1, почтовый сервер во внутренней сети — IP2. Приходит пакет извне с адреса IP3, порт p, на IP0:25. Шлюз пересылает его в неизменном виде на IP2:25. Тут вроде ничего невозможного нет? В обратную сторону: почтовый сервер с IP2:25 шлёт пакет на IP3:p через шлюз IP1. Шлюз в этом пакете заменяет адрес источника с IP2 на IP0, номер порта не трогает, потому что он застолблён за IP2. Тут есть что-то невозможное?
В linux это реализуется двумя правилами iptables (DNAT для пакетов с назначением IP0:25, SNAT для проходящих с источником IP2:25).
А то, что работает у ТСа, — это не проброс (port forwarding или port mapping), а перенаправление (redirection).
-= freeBSD stable, fluxbox =-
"если ты будешь со мной спорить, я тебя запишу в книжечку!" (с) Ежик
Спасибо сказали:
DoggoD
Сообщения: 71
ОС: debian, centos, freebsd

Re: ipfw kernel nat

Сообщение DoggoD »

arachnid писал(а):
01.04.2016 13:50
да, согласен. что-то туплю.

ну за это рецепт решения (проверенно)

правило самого ната

Код: Выделить всё

ipfw nat 20 config if <внешний_ip> redirect_port tcp <куда>:<какой_порт> <на каком порту ждем снаружи>


правила перенаправления в нат

Код: Выделить всё

ipfw nat 20 tcp from any to <внешний_ip> dst-port <на каком порту ждем снаружи> via <имя_внешнего_интерфейса>
ipfw nat 20 tcp from <ip_сервера, куда_перенаправляли> to any via <имя_внешнего интерфейса>


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

arachnid, у меня с

Код: Выделить всё

nat 1 config if rl0 deny_in same_ports unreg_only redirect_port tcp 192.168.0.10:25 25
add 11000 nat 1 ip from any to any via rl0

src address маскируется или эти строки в моем конфиге отличается чем-то от предложенных вами?
Debian 5.0 Lenny, 2.6.26-1-686, KDE 3.5.10.
Asus P5E-VM SE, e8400.
Спасибо сказали:
Аватара пользователя
arachnid
Модератор
Сообщения: 1099
ОС: freeBSD

Re: ipfw kernel nat

Сообщение arachnid »

DoggoD писал(а):
04.04.2016 03:20
arachnid писал(а):
01.04.2016 13:50
да, согласен. что-то туплю.

ну за это рецепт решения (проверенно)

правило самого ната

Код: Выделить всё

ipfw nat 20 config if <внешний_ip> redirect_port tcp <куда>:<какой_порт> <на каком порту ждем снаружи>


правила перенаправления в нат

Код: Выделить всё

ipfw nat 20 tcp from any to <внешний_ip> dst-port <на каком порту ждем снаружи> via <имя_внешнего_интерфейса>
ipfw nat 20 tcp from <ip_сервера, куда_перенаправляли> to any via <имя_внешнего интерфейса>


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

arachnid, у меня с

Код: Выделить всё

nat 1 config if rl0 deny_in same_ports unreg_only redirect_port tcp 192.168.0.10:25 25
add 11000 nat 1 ip from any to any via rl0

src address маскируется или эти строки в моем конфиге отличается чем-то от предложенных вами?

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

и еще раз обращу внимание на своё последнее предложение - о порядке прохождения пакетов - потому как инициатором соединения является внешний источник - поэтому правильное расположение правил так же влияет на прохождение
-= freeBSD stable, fluxbox =-
"если ты будешь со мной спорить, я тебя запишу в книжечку!" (с) Ежик
Спасибо сказали:
DoggoD
Сообщения: 71
ОС: debian, centos, freebsd

Re: ipfw kernel nat

Сообщение DoggoD »

коллеги, не пинайте сильно,
но как выяснилось, проблема лежала вообще в иной плоскости и по большому счету ее (проблемы) не было..
если в кратце, то в ситуации, описанной в топе виноват (помимо моих кривых рук) rinetd (использовался для "просто посмотреть"), который был мною забыт на сетевом интерфейсе резервного канала.. странность в том, что при доступности основного канала, подавляющее большинство легитимных сообщений (это не говоря про спам, который обходил проверку spf, т.к. src address был из mynetwork) шли на менее приоритетный MX резервного канала, а для rinetd подмена src address -- нормальное поведение..
ИТОГ: выпилил к чертям rinetd, обновил правила сетевого интерфейса резервного канала с учетом redirect_port для конфига nat-а -- все заработало как нужно..
строка

Код: Выделить всё

nat 1 config if rl0 deny_in same_ports unreg_only redirect_port tcp 192.168.0.10:25 25

в конфиге ipfw не маскарадит src address входящих пакетов (собственно вариант от arachnid так же является полностью рабочим)..
в рамках проблемы озвученной в топе, считаю вопрос закрытым..
всем спасибо за содействие в решении вопроса..
Debian 5.0 Lenny, 2.6.26-1-686, KDE 3.5.10.
Asus P5E-VM SE, e8400.
Спасибо сказали:
Ответить