Я обновляю свою сеть с использования обратного прокси-сервера apache (недостаточно мощного) до прокси-сервера Squid, настроенного только для обратного использования.
Мой прокси-сервер squid находится на виртуальной машине CentOS 6 и в настоящее время работает вместе с моим ранее существовавшим прокси-сервером apache, поэтому у меня все еще работает squid на порту 3128.
У меня есть эта настройка в моем /etc/squid/squid.conf,
http_port 3128 accel vhost
visible_hostname squid
cache_peer 192.168.0.13 parent 80 0 no-query originserver name=server1
cache_peer_domain server1 www.server1.com server1.com
cache_peer 192.168.0.14 parent 80 0 no-query originserver name=server2
cache_peer_domain server2 www.server2.com server2.com
cache_peer 192.168.0.15 parent 80 0 no-query originserver name=server3
cache_peer_domain server3 www.server3.com server3.com
http_access allow all
Это отлично работает для всех HTTP-соединений.
Он направляет
www.server1.com:3128
к
192.168.0.13:80
Я пытался внедрить сертификаты SSL для двух из трех доменов. Вчера вечером мне удалось получить некоторую успешную конфигурацию для полностью рабочего HTTPS-соединения с одним из моих доменов.
Я добавил этот конфиг перед настройками HTTP:
https_port 443 accel ssl-bump transparent vhost cert=/usr/ssl/CA/server1.crt key=/usr/ssl/CA/server1.key
cache_peer 192.168.0.12 parent 443 0 no-query originserver login=PASS ssl sslflags=DONT_VERIFY_PEER name=server1_ssl
cache_peer_domain server1_ssl ssl www.server1.com server1.com
Прошлой ночью все было нормально. Это будет подключаться к
https:// www.domain1.com
полностью зашифрован. Из-за одного из вариантов (методом проб и ошибок - не могу вспомнить, какой) он расшифровывает пакеты и направляет HTTPS-запрос на правильную виртуальную машину. На виртуальной машине уже был установлен сертификат SSL, поэтому она могла распознавать запросы HTTPS, и вся загрузка страницы от начала до конца была зашифрована.
Я мог бы посетить https: // www.domain2.com, и он сказал бы, что соединение было частично зашифровано, и показало бы ошибку сертификата, что сертификат был для www.domain1.com
Однако сегодня это действительно мешало HTTP-соединению с доменом 1, и мой браузер сообщал, что страница перенаправляется так, что никогда не завершится.
С тех пор я удалил всю конфигурацию SSL-соединения из файла конфигурации и использую только стандартный HTTP.
Есть ли способы заставить https: // www.domain1.com прочитать сертификат domain1.crt и направить его на виртуальную машину domain1, а https: // www.domain2.com - прочитать сертификат domain2.crt и направить на виртуальную машину domain2?
Извините за такой длинный вопрос, но это очень специфическая проблема, с которой я столкнулся, и я попытался предоставить как можно больше информации.
Спасибо
Squid не поддерживает SNI что написано Вот. Итак, чтобы иметь в Squid:
https://server1.com (cert for server1.com) => http://mylanip1
https://server2.com (cert for server2.com) => http://mylanip2
ты должен:
https_port server1.com:443 cert=/etc/ssl/server1.pem vhost
https_port server2.com:443 cert=/etc/ssl/server2.pem vhost
cache_peer mylanip1 parent 80 0 name=lanip1 no-query originserver
cache_peer_domain lanip1 server1.com
cache_peer mylanip2 parent 80 0 name=lanip2 no-query originserver
cache_peer_domain lanip2 server2.com
Было бы лучше, если бы у вас были серверы на поддоменах домена, для которого у вас есть групповой сертификат (например, s1.myserver.com, s2.myserver.com, сертификат для * .myserver.com). Тогда вы можете использовать только одну запись https_port
https_port 443 cert=/etc/ssl/wildcard.myserver.com.pem vhost
Так что в кальмаре это возможно.
Но такой простой случай гораздо проще сделать с помощью httpd и Виртуальные хосты на основе имен. Вы сохраните один публичный IP. В Centos 6 версии openssl и httpd поддерживают SNI. Это видно из версии openssl. (Видеть Вот и Вот)