The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Проксирование порта средствами IPFW/natd"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Маршрутизация, NAT / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"Проксирование порта средствами IPFW/natd"  +/–
Сообщение от DeadLoco (ok) on 30-Сен-14, 22:46 
Возникла необходимость отпроксировать порт с машинки А на порт машинки Б. Поскольку обе машинки с белыми адресами сидят в провайдерских сетях, дефолтные гейтвеи у них смотрят в разные стороны, и фокус, которым обычно пользуются при раздаче нета натом офисным сетям, не срабатывает.

Нужно полноценное проксирование с подменой адреса источника пакета и обратной трансформацией ответа. Я уже вижу, что в кернел-нате эта плюшка пока не реализована, но вот как ее попользовать в юзерленд-нате я в упор не понимаю. В манах написано лишь, что есть две опции - -proxy_only -proxy_rule, а дальше тишина и молчок. Гуглеж тоже не прояснил.

Мне, по сути, нужно то, что иптаблесами делается вот так: 

iptables -t nat -A PREROUTING -p tcp -d 11.11.11.11 --dport 12345 -j DNAT --to-destination 22.22.22.22:12345
iptables -t nat -A POSTROUTING -p tcp -d 22.22.22.22 --dport 12345 -j SNAT --to-source 11.11.11.11
Но только средствами IPFW/natd.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от Денис (??) on 01-Окт-14, 09:19 
организовывал както прокидывание порта с одной машины  на другой средствами ipfw nat
при входе пакета на маршрутизатор менял адрес назначения, при выходе этого же пакета  адрес источника

>[оверквотинг удален]
> Нужно полноценное проксирование с подменой адреса источника пакета и обратной трансформацией
> ответа. Я уже вижу, что в кернел-нате эта плюшка пока не
> реализована, но вот как ее попользовать в юзерленд-нате я в упор
> не понимаю. В манах написано лишь, что есть две опции -
> -proxy_only -proxy_rule, а дальше тишина и молчок. Гуглеж тоже не прояснил.
> Мне, по сути, нужно то, что иптаблесами делается вот так: 

iptables -t 
> nat -A PREROUTING -p tcp -d 11.11.11.11 --dport 12345 -j DNAT 
> --to-destination 22.22.22.22:12345 
> iptables -t nat -A POSTROUTING -p tcp -d 22.22.22.22 --dport 12345 -j 
> SNAT --to-source 11.11.11.11
Но только средствами IPFW/natd.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от pavel_simple (ok) on 01-Окт-14, 09:54 
>[оверквотинг удален]
>> Нужно полноценное проксирование с подменой адреса источника пакета и обратной трансформацией
>> ответа. Я уже вижу, что в кернел-нате эта плюшка пока не
>> реализована, но вот как ее попользовать в юзерленд-нате я в упор
>> не понимаю. В манах написано лишь, что есть две опции -
>> -proxy_only -proxy_rule, а дальше тишина и молчок. Гуглеж тоже не прояснил.
>> Мне, по сути, нужно то, что иптаблесами делается вот так: 
iptables -t 
>> nat -A PREROUTING -p tcp -d 11.11.11.11 --dport 12345 -j DNAT 
>> --to-destination 22.22.22.22:12345 
>> iptables -t nat -A POSTROUTING -p tcp -d 22.22.22.22 --dport 12345 -j 
>> SNAT --to-source 11.11.11.11
Но только средствами IPFW/natd.

xinetd redirect

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Проксирование порта средствами IPFW/natd"  +1 +/–
Сообщение от DeadLoco (ok) on 01-Окт-14, 10:59 
> организовывал както прокидывание порта с одной машины  на другой средствами ipfw nat
> при входе пакета на маршрутизатор менял адрес назначения, при выходе этого же
> пакета  адрес источника

Это работает только потому, что первая машина является шлюзом по умолчанию для второй. И есть гарантия, что пакет-ответ будет возвращаться через первую машину. В моем случае обе машины смотрят в нет, имеют каждая свой шлюз по умолчанию, и чтобы ответный пакет пришел на машину, откуда был отфорвардлен запрос - нужно выполнять полное проксирование, т.е. подмену И получателя, И отправителя при форварде, и то же самое - на обратном пути.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от Денис (??) on 01-Окт-14, 12:56 
>> организовывал както прокидывание порта с одной машины  на другой средствами ipfw nat
>> при входе пакета на маршрутизатор менял адрес назначения, при выходе этого же
>> пакета  адрес источника
> Это работает только потому, что первая машина является шлюзом по умолчанию для
> второй. И есть гарантия, что пакет-ответ будет возвращаться через первую машину.
> В моем случае обе машины смотрят в нет, имеют каждая свой
> шлюз по умолчанию, и чтобы ответный пакет пришел на машину, откуда
> был отфорвардлен запрос - нужно выполнять полное проксирование, т.е. подмену И
> получателя, И отправителя при форварде, и то же самое - на
> обратном пути.

нет,не поэтому и машина не была шлюзом по умолчанию для другой,но машины в одной локалке были, да
в чем проблема менять адрес источника и получателя?
если я правильно понял нужно следующее:
клиент коннектится на машину  А,машина А меняет адрес назначения на B и отправляет пакет на  B при этом меняя адрес источника на А. Сервер B отвечает А, после чего А отвечает клиенту, предварительно поменяв адреса как было

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

зы А может туннель организовать?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от reader (ok) on 01-Окт-14, 22:28 
на 192.168.56.10 FreeBSD 10.0-RELEASE

ipfw nat 1 config if em0 redirect_port tcp 77.234.201.242:80 80

40000 36 2496 nat 1 ip from any to any via em0
60000  0    0 allow ip from any to any
65535  0    0 deny ip from any to any

telnet 192.168.56.10 80  c 192.168.56.1

21:58:33.355535 IP 192.168.56.1.52289 > 192.168.56.10.80: Flags [S], seq 671562569, win 29200, options [mss 1460,sackOK,TS val 10019596 ecr 0,nop,wscale 7], length 0
21:58:33.355807 IP 192.168.56.10.52289 > 77.234.201.242.80: Flags [S], seq 671562569, win 29200, options [mss 1460,sackOK,TS val 10019596 ecr 0,nop,wscale 7], length 0
21:58:33.385629 IP 77.234.201.242.80 > 192.168.56.10.52289: Flags [S.], seq 186268352, ack 671562570, win 65535, options [mss 1460,sackOK,eol], length 0
21:58:33.385968 IP 192.168.56.10.80 > 192.168.56.1.52289: Flags [S.], seq 186268352, ack 671562570, win 65535, options [mss 1460,sackOK,eol], length 0
21:58:33.385988 IP 192.168.56.1.52289 > 192.168.56.10.80: Flags [.], ack 1, win 29200, length 0
21:58:33.386205 IP 192.168.56.10.52289 > 77.234.201.242.80: Flags [.], ack 1, win 29200, length 0
21:58:49.211597 IP 192.168.56.1.52289 > 192.168.56.10.80: Flags [P.], seq 1:6, ack 1, win 29200, length 5
21:58:49.211877 IP 192.168.56.10.52289 > 77.234.201.242.80: Flags [P.], seq 1:6, ack 1, win 29200, length 5
21:58:49.245288 IP 77.234.201.242.80 > 192.168.56.10.52289: Flags [.], ack 6, win 65535, length 0
21:58:49.245525 IP 192.168.56.10.80 > 192.168.56.1.52289: Flags [.], ack 6, win 65535, length 0
21:58:49.246869 IP 77.234.201.242.80 > 192.168.56.10.52289: Flags [P.], seq 1:174, ack 6, win 65535, length 173
21:58:49.246885 IP 77.234.201.242.80 > 192.168.56.10.52289: Flags [F.], seq 174, ack 6, win 65535, length 0
21:58:49.246997 IP 192.168.56.10.80 > 192.168.56.1.52289: Flags [P.], seq 1:174, ack 6, win 65535, length 173
21:58:49.247008 IP 192.168.56.1.52289 > 192.168.56.10.80: Flags [.], ack 174, win 30016, length 0
21:58:49.247051 IP 192.168.56.10.80 > 192.168.56.1.52289: Flags [F.], seq 174, ack 6, win 65535, length 0
21:58:49.247092 IP 192.168.56.10.52289 > 77.234.201.242.80: Flags [.], ack 174, win 30016, length 0
21:58:49.247229 IP 192.168.56.1.52289 > 192.168.56.10.80: Flags [F.], seq 6, ack 175, win 30016, length 0
21:58:49.247807 IP 192.168.56.10.52289 > 77.234.201.242.80: Flags [F.], seq 6, ack 175, win 30016, length 0
21:58:49.283254 IP 77.234.201.242.80 > 192.168.56.10.52289: Flags [.], ack 7, win 65534, length 0
21:58:49.283518 IP 192.168.56.10.80 > 192.168.56.1.52289: Flags [.], ack 7, win 65534, length 0

вроде работает или я вопрос не понял?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от DeadLoco (ok) on 02-Окт-14, 00:15 
> вроде работает или я вопрос не понял?

Есть старый сервант, который надо мигрировать на другую машину без простоя. Там еще шестая фря, и кернел-нат, увы, не катет. Потому и ограничение по ipfw/natd возникло - что есть, тем и работаем.

Короче, в старом natd редирект порта не сопровождается алиасингом источника адресом хоста ната.

Если с адреса 1.1.1.1 приходит пакет на хост 2.2.2.2:22222 где natd редиректит порт 22222 на машину 3.3.3.3, то на 3.3.3.3 приходит пакет с адресом источника 1.1.1.1:ххххх. 3.3.3.3 отвечает на этот адрес, и если пакет минует на обратном пути хост с натом, то сессия не подымется, потому что ответ не с того хоста, который ожидает инициатор. Если же пакет попадает в нат на обратном пути, то тогда ему подменяется адрес на 2.2.2.2 и все ок.

Трабла усугубляется тем, что natd асимметричен, и редиректит/алиасит в разные стороны.

Задача решается двумя инстансами ната - спасибо за наводку Денису. 

instance                default
alias_address           172.22.22.101
in_port                 8881
out_port                8880
redirect_port   tcp     172.22.22.103:20000     172.22.22.101:20000
redirect_port   tcp     172.22.22.103:20001     172.22.22.101:20001
redirect_port   tcp     172.22.22.103:20002     172.22.22.101:20002
. . . . . . .
instance                reverse
alias_address           172.22.22.101
in_port                 8871
out_port                8870
Дальше дивертим четыре потока:
NEW="172.22.22.103"
$cmd add 1000 divert 8881 tcp from not $NEW to me ${ports} in  via em0
$cmd add 1001 divert 8870 tcp from any to $NEW             out via em0
$cmd add 2000 divert 8871 tcp from $NEW to me              in  via em0
$cmd add 2001 divert 8880 tcp from $NEW to any             out via em0
Первый инстанс редиректит порт, заменяя пакету dst, а второй алиасит источник, заменяя ему src.


УПД.
К серверу коннектится несколько тыщ устройств, которым программатором в еепром забит IP-адрес:порт, и обычными манипуляциями с ДНС, увы, ничего не решить. Теперь же перешитые будут лезть сразу на новый сервант, а неперешитые будут редиректиться.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от Skif (ok) on 02-Окт-14, 12:17 
Я всё же не понимаю чем forward, не redirect вам не подходит?
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Проксирование порта средствами IPFW/natd"  +1 +/–
Сообщение от reader (ok) on 02-Окт-14, 13:35 
> Я всё же не понимаю чем forward, не redirect вам не подходит?

forward это по моему пересылка не на другой ip, а на другой mac адрес соответственно с ограничениями только в подсети.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от Skif (ok) on 02-Окт-14, 13:38 
>> Я всё же не понимаю чем forward, не redirect вам не подходит?
> forward это по моему пересылка не на другой ip, а на другой
> mac адрес соответственно с ограничениями только в подсети.

Change the next-hop on matching packets to ipaddr, which can be
             an IP address or a host name.  The next hop can also be supplied
             by the last table looked up for the packet by using the tablearg
             keyword instead of an explicit address.  The search terminates if
             this rule matches.

             If ipaddr is a local address, then matching packets will be for-
             warded to port

             If ipaddr is not a local address, then the port number (if speci-
             fied) is ignored, and the packet will be forwarded to the remote
             address, using the route as found in the local routing table for
             that IP.
             A fwd rule will not match layer-2 packets (those received on
             ether_input, ether_output, or bridged).
             The fwd action does not change the contents of the packet at all.
             In particular, the destination address remains unmodified, so
             packets forwarded to another system will usually be rejected by
             that system unless there is a matching rule on that system to
             capture them.  For packets forwarded locally, the local address
             of the socket will be set to the original destination address of
             the packet.  This makes the netstat(1) entry look rather weird
             but is intended for use with transparent proxy servers.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от reader (ok) on 02-Окт-14, 13:57 
>[оверквотинг удален]
>            
>  capture them.  For packets forwarded locally, the local address
>            
>  of the socket will be set to the original destination
> address of
>            
>  the packet.  This makes the netstat(1) entry look rather
> weird
>            
>  but is intended for use with transparent proxy servers.

в чем противоречие?
в fwd указывается ip, но пересылка идет на mac этого ip, а ip назначения в пакете остается оригинальным

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от DeadLoco (ok) on 02-Окт-14, 16:36 
>>> Я всё же не понимаю чем forward, не redirect вам не подходит?

packets forwarded to another system will usually be rejected by
that system unless there is a matching rule on that system to
capture them.

Но даже если переводить интерфейс в promisc-mode и ловить левые пакеты, остается проблема с ответом, который должен уходить с src, на который обращался инициатор сессии.

Короче, геморрой еще тот.

В реализации кернел-ната средствами libalias поведение редиректа изменено, в сравнении с редиректом natd. Если natd при редиректе меняет только dst пакета, а затем алиасит src проходящего мимо ответа, то libalias выполняет настоящее проксирование, пересылая пакет на другой адрес от своего имени, а затем пересылает от своего имени полученный ответ.

пакет = (src/dst)
Для natd:
--> (1/2) --> {host2} --> (1/3) --> {host3}
<-- (2/1) <-- {host2} <-- (3/1) <-- {host3}

Для libalias:
--> (1/2) --> {host2} --> (2/3) --> {host3}
<-- (2/1) <-- {host2} <-- (3/2) <-- {host3}

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

13. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от Аноним (??) on 03-Окт-14, 11:34 
>[оверквотинг удален]
> а затем алиасит src проходящего мимо ответа, то libalias выполняет настоящее
> проксирование, пересылая пакет на другой адрес от своего имени, а затем
> пересылает от своего имени полученный ответ.
> пакет = (src/dst)
> Для natd:
> --> (1/2) --> {host2} --> (1/3) --> {host3}
> <-- (2/1) <-- {host2} <-- (3/1) <-- {host3}
> Для libalias:
> --> (1/2) --> {host2} --> (2/3) --> {host3}
> <-- (2/1) <-- {host2} <-- (3/2) <-- {host3}

А какие сервисы вообще нужно "запроксировать"?

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от DeadLoco (ok) on 03-Окт-14, 13:54 
> А какие сервисы вообще нужно "запроксировать"?

Нестандартные. Запущен целый букет однотипных сервисов, каждый на своем порту, для работы с разными типами клиентских железок.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от Skif (ok) on 03-Окт-14, 11:43 
>[оверквотинг удален]
> а затем алиасит src проходящего мимо ответа, то libalias выполняет настоящее
> проксирование, пересылая пакет на другой адрес от своего имени, а затем
> пересылает от своего имени полученный ответ.
> пакет = (src/dst)
> Для natd:
> --> (1/2) --> {host2} --> (1/3) --> {host3}
> <-- (2/1) <-- {host2} <-- (3/1) <-- {host3}
> Для libalias:
> --> (1/2) --> {host2} --> (2/3) --> {host3}
> <-- (2/1) <-- {host2} <-- (3/2) <-- {host3}

Я давно не работаю с FreeBSD и ipfw в частности, но можно ещё приплюсовать ipfw tag и маркировать нужные пакеты, направляя в нужную сторону. Для простоты можно поднят gif туннель между хостами, если они в разных подсетях и весь трафик "проксирования" гонять по туннелю. идущий на "сервис" маркировать, идущий с туннеля "маркировать", маркированный на возврате тоже гнать по туннелю.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

15. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от Skif (ok) on 03-Окт-14, 11:53 
>[оверквотинг удален]
>> <-- (2/1) <-- {host2} <-- (3/1) <-- {host3}
>> Для libalias:
>> --> (1/2) --> {host2} --> (2/3) --> {host3}
>> <-- (2/1) <-- {host2} <-- (3/2) <-- {host3}
> Я давно не работаю с FreeBSD и ipfw в частности, но можно
> ещё приплюсовать ipfw tag и маркировать нужные пакеты, направляя в нужную
> сторону. Для простоты можно поднят gif туннель между хостами, если они
> в разных подсетях и весь трафик "проксирования" гонять по туннелю. идущий
> на "сервис" маркировать, идущий с туннеля "маркировать", маркированный на возврате тоже
> гнать по туннелю.

Ваш случай, в моём понимании, частный случай данной ситуации
http://nuclight.livejournal.com/124348.html
Тот факт, что на самом деле "перепрыгивание" выполняется на параметры
действия, позволяет использовать это для интересных вещей. В частности, с
использованием появившегося во FreeBSD 6.2 параметра tag на каждый пакет можно
навешивать внутриядерный тег, что в применении со skipto позволяет сделать, к
примеру, запоминание, с какого шлюза пришел входящий пакет на машине с каналами
к двум разным провайдерам, и ответные пакеты отправлять в тот канал, откуда они
пришли (допустим, у вашей машины только один IP-адрес, и сделать fwd на базе
внешнего адреса не получится), т.е. реализовать аналог reply-to из pf:

ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
ipfw add 300 allow { recv $ext_if1 or recv $ext_if2 }  # входящие снаружи
ipfw add 400 allow in recv $int_if   # разрешить ответы на внутреннем проходе
ipfw add 500 fwd $gw1 tagged 1      # остались ответы на внешнем интерфейсе,
ipfw add 600 fwd $gw2 tagged 2      # зарулим их куда надо

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от DeadLoco (ok) on 03-Окт-14, 14:36 
> Ваш случай, в моём понимании, частный случай данной ситуации

У меня проблема усугубляется тем, что обе машины - в разных сетях и имеют по одному внешнему интерфейсу. Они вообще никак не связаны между собой, находятся на площадках у разных хостеров. Конечно, можно было бы прокинуть впн, и привести все к стандартной схеме "офисная сеть с шлюзом-прокси", но это некрасиво. Это потребовало бы дополнительных настроек на обоих хостах. А так новый хост конфигурится без знания о старом, но старый редиректит на него запросы от клиентов, которые тоже ничего не знают о новом хосте.

Просто надо учитывать, что натд асимметричен, как диод, и в одном направлении умеет подменять пакету дст, а в другом - срц, но не оба одновременно. Именно поэтому приходится делать конвейер из двух встречно включенных инстансов.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от Skif (ok) on 03-Окт-14, 15:03 
>[оверквотинг удален]
> между собой, находятся на площадках у разных хостеров. Конечно, можно было
> бы прокинуть впн, и привести все к стандартной схеме "офисная сеть
> с шлюзом-прокси", но это некрасиво. Это потребовало бы дополнительных настроек на
> обоих хостах. А так новый хост конфигурится без знания о старом,
> но старый редиректит на него запросы от клиентов, которые тоже ничего
> не знают о новом хосте.
> Просто надо учитывать, что натд асимметричен, как диод, и в одном направлении
> умеет подменять пакету дст, а в другом - срц, но не
> оба одновременно. Именно поэтому приходится делать конвейер из двух встречно включенных
> инстансов.

Ну, я предлагаю просто gif поднять без всяких шифрований - оно ведь вам не нужно. Предлагаю просто для упрощения той самой "маркировки"
В такой схеме у вас никто и не будет ничего знать друг о друге кроме пары правил ipfw и gif тунеля, которые отключить дело пары сек.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Проксирование порта средствами IPFW/natd"  +/–
Сообщение от Skif (ok) on 03-Окт-14, 15:06 
>[оверквотинг удален]
>> не знают о новом хосте.
>> Просто надо учитывать, что натд асимметричен, как диод, и в одном направлении
>> умеет подменять пакету дст, а в другом - срц, но не
>> оба одновременно. Именно поэтому приходится делать конвейер из двух встречно включенных
>> инстансов.
> Ну, я предлагаю просто gif поднять без всяких шифрований - оно ведь
> вам не нужно. Предлагаю просто для упрощения той самой "маркировки"
> В такой схеме у вас никто и не будет ничего знать друг
> о друге кроме пары правил ipfw и gif тунеля, которые отключить
> дело пары сек.

В противном случае - socks прокси, при условии, что он сможет работать с вашими сервисами

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру