В настоящее время мой IPtable без разбора отправляет все входящие запросы на мой прозрачный прокси-сервер Squid. Однако, поскольку мне нужен SSL для работы, мне нужен способ избежать перехвата SSL-трафика.
Идея
Можно ли это сделать в iptable? Спасибо!
Изменить: я добавляю дополнительную информацию о своей настройке.
Из-за особых требований я должен отправлять трафик на прозрачный прокси-сервер Squid, используя перенаправление DNS, а не обычное перенаправление маршрутизатора / шлюза.
Метод перехвата
Текущие правила таблицы IP
По-видимому, вы используете типичный маршрутизатор / шлюз для перенаправления трафика в Squid, вы можете просто перенаправить порт 80 и игнорировать 443, потому что трафик 443 будет идти напрямую, минуя Squid.
К сожалению, при моей текущей настройке, если я не пересылаю 443, любое https-соединение просто истечет.
Единственное решение сейчас - перехватить все запросы 443, сопоставить каждый домен с каждым уникальным IP-адресом и отправить запрос обратно на исходный IP-адрес источника.
Я попытался использовать Rinetd для пересылки 443 на исходный IP-адрес веб-сайта. К сожалению, этот метод перенаправит весь мой трафик 443 только на 1 IP-адрес, поскольку он не будет различать IP-адрес запроса.
Например, я сопоставляю 443 IP-адресу Gmail.com. Когда я приезжаю https://gmail.com, он будет работать нормально. Однако, если я приду https://hotmail.com, он все равно будет отправлять меня на IP-адрес gmail.com
Мне нужно найти способ сопоставить каждый IP-адрес с каждым доменом, чтобы при посещении gmail.com он перенаправлялся на IP-адрес gmail; когда я захожу на hotmail.com, он перенаправляет меня на IP hotmail.com
Вы описываете "прозрачный SSL-прокси", которого фактически не существует (для вперед кейс; он может работать для ускорителей SSL). Посмотрим почему:
На этом этапе необходимо обменять сертификаты и т. Д.
Однако… как Squid-бокс узнает, к какому сайту на самом деле осуществляется доступ (т.е. к какому удаленному хосту подключиться)? Клиент не сообщает серверу SSL, какой сайт он ожидает - он полагается, что сервер уже знает это! Это часть функций безопасности SSL.
Та же проблема с iptables - как узнать, на каком хосте находится клиент? действительно разыскивается? Эта информация просто недоступна (потому что «фиктивный DNS-сервер» выбросил ее).
Единственный известный мне способ прокси SSL - через CONNECT метод; и для этого вам нужно указать поле Squid как явный прокси.
Честно говоря, проблема в перенаправлении DNS. Я сбит с толку, почему вы не можете использовать iptables для перенаправления порта 80 и оставить 443 в покое.
Вы не можете перенаправить трафик https (443) на любой порт, используя iptables. Squid не обрабатывает https-запросы в прозрачном режиме (только http):
PD: eth1 localnet и eth0 интернет
Ты можешь сделать это: Перенаправить http-трафик LAN (eth1) на прозрачный порт прокси-сервера squid 8080 (http). В squid.conf должно быть правило: http_port 8080 intercept
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080
И откройте порт 443 для локальной сети
iptables -A INPUT -i eth1 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth1 -p tcp --dport 443 -o eth0 -j ACCEPT
Ты не сможешь это сделать: Перенаправить трафик https LAN (eth1) на непрозрачный порт прокси-сервера squid 3128 (https) (Fake Rule). Не имеет значения, существует ли в squid.conf правило: http_port 3128
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 3128
Альтернативы: