Прошу прощения — не могли бы Вы подсказать — не будет ли эта конструкция проще, если выгонять через EXT_IP2 всю сеть?
Я тут подумал и решил выгнать сервер терминалов в отдельную физическую (и IP, ессно) сеть.
> NAT заменяет адреса в пакете, (NAT=network address translation), можно менять source, можно dest, а можно оба адреса. В случае замены source addr получатель не узнает старый, настоящий, source адрес.
При этом он или сохраняет источник в служебных полях исходящего пакета (здесь могу врать) — или же держит таблицу трансляции для каждого пакета (подменяя при этом порт источника).
В манах rinetd об этом ни слова :-(
Хотя — судя по трейсу — он делает так, как во втором случае.
Я понимаю, что вредничаю — но…
Понятно, что не светится. Но если rinetd туннелирует TCP так, как и NAT — то информация о натированном адресе содержится внутри пакета. И рано или поздно эту инфу можно будет достать оттуда.
А если как сквид — риалнэ проксирует — то он должен держать входящее соединение и открывать параллельно ему соответствующее исходящее. Вот это — риалнэ секюрно.
Просто я сейчас пустил важный ssh через HTTP-proxy (squid) — и параллельно через rinetd. И не пойму — в чем подколка… Не может быть, чтобы всё так просто было… Нигде не гуглится такое предложение по «проксированию» ssh через rinetd.
Я ж не думаю, что самый умный :-)
Хорошо бы, чтобы так. Но в мане пишется Forward, а не proxy.
Скажем — www.partow.net/programming/tcpproxy/index.html — здесь явно указано, что это именно прокси.
А с rinetd приходится догадываться — так ли это.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
