В моей конфигурации я использую Haproxy в основном для обратного прокси.
Я установил Прокси-сервер Squid в моей частной локальной сети, и я могу получить к нему доступ с внешнего порта через порт 3128. Но я использую базовую аутентификацию ncsa, и заголовки не зашифрованы, поэтому мой логин уязвим. Я хочу перенаправить свой прокси через haproxy.
[Клиент] -> proxy.example.net -> [haproxy: 443 ssl] -> [squid: 3128]
Я добавил в свою конфигурацию haproxy новый бэкэнд:
frontend www-https
bind *:443 ssl crt /etc/haproxy/ssl/fullchain.pem no-sslv3
log global
mode http
use_backend proxy-squid if { ssl_fc_sni proxy.example.com }
use_backend default if { ssl_fc_sni example.com }
default_backend default
backend default
option forwardfor
server d8-apps 127.0.0.1:8000 #nginx
backend proxy-squid
mode http
option forwardfor
option http-server-close
server d8-apps 127.0.0.1:3128
Бэкэнд по умолчанию и другие работы нормально но не прокси-сквид. Я реализовал "tcpdump -nX -vv -i lo port 3128" во время моего запроса и ничего ... а с портом 443 я вижу много пакетов с неправильной контрольной суммой.
В Wireshark я не вижу подтверждения ssl, как когда я захожу на example.com (бэкэнд по умолчанию). Я просто вижу трехэтапное рукопожатие tcp, за которым следует FIN, ACK.
Я думаю, что Haproxy не понимает мой настоящий запрос, когда я устанавливаю прокси в конфигурации своего браузера. Итак, возможно ли это реализовать с помощью конкретной конфигурации?
Спасибо!
HTTP содержит несколько разных синтаксисов сообщений, которые используются в разных ситуациях. Сообщения, отправляемые на сервер (или обратный прокси), сильно отличаются от сообщений, отправляемых на прокси.
Поскольку у вас есть настройка haproxy для работы в качестве обратного прокси, она не разрешает сообщения, необходимые браузеру для настройки HTTPS. туннель.
Поскольку все, что вы на самом деле пытаетесь сделать, это защитить свои подключения к Squid, я предлагаю вам просто заставить его прослушивать https_port для подключений из браузера. Конечно, для этого потребуется установка сертификата TLS с публичным именем прокси-сервера. Обратите внимание, что это не та же деталь сертификата, которая используется для обратного прокси (который использует доменное имя исходного сервера).
Firefox и Chrome явно поддерживают TLS для явного прокси, когда настроены на его использование через файл PAC или переменную среды https_proxy =. В обоих случаях URI прокси-сервера должен использовать схему https: //, тогда как традиционно используется схема http: //.
(Я говорю, очевидно, потому что сам еще не пробовал. У других были смешанные результаты, но браузер люди твердят, что это возможно)