Здравствуйте, jksgfv, Вы писали:
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)
не рассматривается и трафик к прокси всегда в тот же интерфейс что и к серверу?
J>Если предположить, что клиентов за роутером (R) много, то пустить весь трафик через прокси (P) можно только лишь немного скорректировав маршруты на роутере (R) и сервере (S).
по моему достаточно корректировки маршртов (+ NAT) на шлюзе. В какой ситуации вы считает, что нужно трогать еще и сервер?
J>Важно, что конфигурация клиентов останется прежней.
Для пущей простоты
роутер (R) можно спрятать:
J>J>клиент (C) прокси (P) сервер (S)
J> 10.0.0.4 ------ 10.0.0.2 ----- 10.0.0.1
J>
J>В итоге:
прозрачный прокси: клиент (C) соединяется с сервером (S), сервер (S) видит соединение с прокси (P) (плохо подходит - сервер может использовать адрес клиента)
нужный прокси: клиент (C) соединяется с сервером (S), сервер (S) видит соединение с клиентом (C)
J>Т.е. прокси (P) становится вообще невидимым.
J>Вернее, он ведёт себя как роутер, что позволяет оказать минимальное влияние на функционирование сети.
фраза которая все запутывает )
нужный прокси: клиент (C) соединяется с сервером (S), сервер (S) видит соединение с клиентом (C)
Без iptables или реализации части его функционала в своем коде вам не обойтись.