Здравствуйте, jksgfv, Вы писали:

J>Здравствуйте, grey_olli, Вы писали:

J>>>>>Есть задача реализовать прозрачный прокси,
J>>>А картинка довольно простая:

клиент (C)      роутер (R)     прокси (P)     сервер (S)
 10.0.0.4 ------ 10.0.0.3 ----- 10.0.0.2 ----- 10.0.0.1

J>>>Разумеется, подсети могут быть (и вероятно и будут) разными.
_>>то есть картинка

клиент (C)              роутер (R)               сервер (S)
10.0.0.4 ------ 10.0.0.3,10.0.1.1,10.0.2.2 ----- 10.0.2.1
                            \
                             ----- 10.0.1.2
                                  прокси (P)

_>>не рассматривается и трафик к прокси всегда в тот же интерфейс что и к серверу?
_>>по моему достаточно корректировки маршртов (+ NAT) на шлюзе. В какой ситуации вы считает, что нужно трогать еще и сервер?
J>Роутер (R) не принадлежит нам, и мы можем рассчитывать только лишь на простейший его функционал (маршрутизацию на наш прокси),
По первой схеме: добавляете в R маршрут на S через P, в P реализуете не только свою прокси функцию, но и функционал router (для всего трафика) + NAT
конкретно вашего проксируемого трафика в postrouting. Видимо Вам достаточно будет написать модуль к iptables помимо собственно прокси-функций (может готовое что приспособите — это уже вам виднее по деталям протокола и функционала вашего прокси application). На S добавляете маршрут в сеть C через P .

> NAT'а там может и не быть (и не быть возможности его установить). Т.е. рассчитывать на какую бы то ни было топологию сети мы не можем, тем более навязывать свои изменения (добавление NAT и изменение IP-адреса и подсети сервера).
J>Наша же задача — внедрением своего прокси (P) как можно меньше повлиять на систему и сохранить максимум информации о существующей топологии в трафике (т.е. как раз избежать добавления NAT).
См. выше.

>>Без iptables или реализации части его функционала в своем коде вам не обойтись.

J>На своей машине (прокси (P)) я могу вытворять что угодно — хоть ядро со своими патчами, не говоря об использовании iptables. Но от других машин я могу ожидать лишь простейших изменений конфигурации (добавление маршрута, например), основывать архитектуру на добавлении правил iptables или функций NAT где-то на роутере (R) или тем более сервере (S) нет никакой возможности.
cм. выше.

J>Отсюда и требование, чтобы сети казалось, что прокси (P) просто форвардит весь трафик (что и наводит на мысль о роутере).
Не путайте мягкое и гибкое. Функции прокси на tcp вам нужны на application level OSI, роутинг осуществляется гораздо ниже — на сетевом уровне OSI.

J> Меня же интересует "худший случай", когда топология прямолинейная и сервер использует IP-адреса клиентов, скажем, для реализации како-либо политики безопасности.
см. выше.