отправка HTTPS-трафика после Squid + SSL_BUMP на второй прокси.
После настройки Squid для выполнения SSL Bump на HTTPS SSL-запросах от клиентов ... я хочу отправить это на другой прокси-сервер, который будет выполнять свой собственный MITM и подключаться к 'целевому серверу' и вернуть информацию клиенту ........ Что нужно squid для передачи запросов (после выполнения ssl bump) второму прокси?
client (box1) -> iptables (box1) -> squiq + ssl_bump (box2) -> anotherproxy (box3) -> targetServer
box1 был обновлен с помощью правил iptable
iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to 10.1.1.1.1:8444
box2 имеет SSL_BUMP, настроенный для прослушивания и дешифрования на 8444 .. однако я не уверен, как настроить squid, как чтобы передать дешифрованное перенаправление ssl из ssl_bump ... Я пробовал cache_peer (parent), и squid не удается успешно подключиться к 'cache_peer (parent) ..
Я почти уверен, что вы не можете указать нисходящий прокси-сервер в squid.conf, если используете SslBump (или я не мог, когда использовал его с Squid 3.4. ??) . Я предполагаю, что вы могли бы сделать это, настроив другой прозрачный https / SslBump iptables / squid, как в вашем примере:
client (box1) -> iptables (box2) -> squid + ssl_bump (box3) - > ANOTHER_IPTABLES (box4) -> anotherproxy + ssl_bump (box5) -> targetServer
с box4, перенаправляющим весь трафик 443TCP на порт 8884 box5 (ваш порт перехвата https squid)
Но действительно ли вам нужно это делать? Для меня это выглядит сложным.
Кстати, если вы используете iptables (например, box2) в качестве маршрутизатора, вы также можете запустить на нем squid + ssl_bump, чтобы сэкономить на ящиках.