Назад | Перейти на главную страницу

Прокси-сервер Squid за Haproxy

В своей конфигурации я использую Haproxy в основном для обратного прокси.

Я установил Squid Proxy в свою частную сеть, и я могу получить к нему доступ с внешнего порта через порт 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: //.

(Я говорю, очевидно, потому что сам еще не пробовал. У других были смешанные результаты, но браузеры продолжают говорить, что это возможно).