Как работает rinetd?

Question

[TIEugene]

Или другой редиректор TCP.
Пусть есть машина A, которая работает с машиной B — которая перенаправляет всё (или то, что надо) на машину C с помощью rinetd.
На участке B-C как-то виден адрес A? Имеется ввиду средствами провайдера сети C.

Answer 1

[ivnik]

Судя по ману это просто tcp-прокси. Соответственно машина A работает только с B и знать не знает ни про какую машину C. А машина C получает подключения от машины B и не знает ни про какую A.

Comments

[TIEugene]

Хорошо бы, чтобы так. Но в мане пишется Forward, а не proxy.
Скажем — www.partow.net/programming/tcpproxy/index.html — здесь явно указано, что это именно прокси.
А с rinetd приходится догадываться — так ли это.

Answer 2

[ivnik]

Добавил в конфиг:

127.0.0.1 127 192.168.0.1 192

Запустил tcpdump и telnet:

$ telnet 127.0.0.1 127
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.

# tcpdump -i any -n port 127 or port 192
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
12:42:40.869870 IP 127.0.0.1.42205 > 127.0.0.1.127: Flags [S], seq 3890575008, win 32792, options [mss 16396,sackOK,TS val 86107963 ecr 0,nop,wscale 7], length 0
12:42:40.869882 IP 127.0.0.1.127 > 127.0.0.1.42205: Flags [S.], seq 293205897, ack 3890575009, win 32768, options [mss 16396,sackOK,TS val 86107963 ecr 86107963,nop,wscale 7], length 0
12:42:40.869891 IP 127.0.0.1.42205 > 127.0.0.1.127: Flags [.], ack 1, win 257, options [nop,nop,TS val 86107963 ecr 86107963], length 0
12:42:40.869959 IP 192.168.0.1.36533 > 192.168.0.1.192: Flags [S], seq 3984613777, win 32792, options [mss 16396,sackOK,TS val 86107963 ecr 0,nop,wscale 7], length 0
12:42:40.869967 IP 192.168.0.1.192 > 192.168.0.1.36533: Flags [R.], seq 0, ack 3984613778, win 0, length 0
12:42:40.870023 IP 127.0.0.1.127 > 127.0.0.1.42205: Flags [F.], seq 1, ack 1, win 256, options [nop,nop,TS val 86107963 ecr 86107963], length 0
12:42:40.870071 IP 127.0.0.1.42205 > 127.0.0.1.127: Flags [F.], seq 1, ack 2, win 257, options [nop,nop,TS val 86107963 ecr 86107963], length 0
12:42:40.870085 IP 127.0.0.1.127 > 127.0.0.1.42205: Flags [.], ack 2, win 256, options [nop,nop,TS val 86107963 ecr 86107963], length 0

Видно, что на порт 192 идут пакеты от 192.168.0.1, т.е. адрес 127.0.0.1 не светится.

Comments

[TIEugene]

Я понимаю, что вредничаю — но…
Понятно, что не светится. Но если rinetd туннелирует TCP так, как и NAT — то информация о натированном адресе содержится внутри пакета. И рано или поздно эту инфу можно будет достать оттуда.
А если как сквид — риалнэ проксирует — то он должен держать входящее соединение и открывать параллельно ему соответствующее исходящее. Вот это — риалнэ секюрно.
Просто я сейчас пустил важный ssh через HTTP-proxy (squid) — и параллельно через rinetd. И не пойму — в чем подколка… Не может быть, чтобы всё так просто было… Нигде не гуглится такое предложение по «проксированию» ssh через rinetd.
Я ж не думаю, что самый умный :-)

[ivnik]

NAT заменяет адреса в пакете, (NAT=network address translation), можно менять source, можно dest, а можно оба адреса. В случае замены source addr получатель не узнает старый, настоящий, source адрес.
Прокси через squid производводится через запрос CONNECT, т.е. клиент должен уметь использовать http-proxy. В случае tcp-прокси проброс осуществляется прозрачно для клиента.
Вообще, rinetd заменяется 2-мя правилами DNAT/SNAT в iptables. Я всегда обходился настройкой файрвола.

[TIEugene]

> NAT заменяет адреса в пакете, (NAT=network address translation), можно менять source, можно dest, а можно оба адреса. В случае замены source addr получатель не узнает старый, настоящий, source адрес.

При этом он или сохраняет источник в служебных полях исходящего пакета (здесь могу врать) — или же держит таблицу трансляции для каждого пакета (подменяя при этом порт источника).
В манах rinetd об этом ни слова :-(
Хотя — судя по трейсу — он делает так, как во втором случае.

[ivnik]

Ядро держит таблицу трансляции в памяти. Ничего не сохраняет ни в каких служебных полях пакета. Убедиться в этом легко сняв дамп (анализировать трафик удобно в wireshark).

Answer 3

[shadowalone]

rinetd использует DNAT, и соответственно понять не сложно что если сделаны настройки на проброс порта на машину во внутренней сети, и на этой машине не указан шлюзом адрес машины с rinetd, то ничего работать не будет.
Можете поэксперементировать.

Answer 4

[TIEugene]

Вообще у меня несколько другая задача — пробрасывать трафик между двумя сетями через интернет, пользуясь внешними машинами.
Грубо говоря — разорвать визуальную связь между двумя сетями. Нутыпонел © :-)
Поэтому и ищу такой хостинг (не российский, ессно), чтобы можно было поставить прокси или iptables или rinetd.
Дискуссия показывает, что rinetd будет достаточно.

Answer 5

[ragus]

вообще-то rinetd работает глупо: слушает сокет, при поступлении коннекта делает accept() и в соответствии с правилами делает connect() на хост: порт, что указаны в конфиге. потом в цикле: читаем из одного сокета в буфер. пишем в другой сокет.
буфер в юзерспейсе, так что данные постоянно бегают по пути kernel <=> userspace< => kernel. Такой вариант кушает cpu и не отличается производительностью. да, и никакого туннелирования ессно нет ))))