timru
Administrator
Сообщения: 48
Зарегистрирован: 12.10.2008
Пользователя нет на форуме
|
![[*]](./images/xmbforum/default_icon.gif) когда размещено 27.1.2018 в 15:46 |
|
|
ISPmanager 4: После установки SSL-сертификата сайт стал работать медленнее. Что делать?
Забегая вперед, скажу что установка сертификата никоим образом не должна увеличивать нагрузку на сайте, дело тут совершенно в другом.
Для начала немного теории. В самом простом случае, есть веб-сервер apache, который висит на 80-м порту и отдает посетителю весь контент, как
статический (изображения, js, css и т.д.), так и динамический (обрабатывает php-скрипты с помощью php-модуля). В целях снижения нагрузки, на 80-й порт
можно повесить более легкий веб-сервер nginx, который будет отдавать статику, а php-скрипты передавать на обработку более тяжелому веб-серверу apache,
который будет висеть скажем на порту 8080. Что же делать в случае c SSL, для работы которого используется порт 443 (https-протокол)? По-логике, нужно
заставить nginx слушать оба порта - и 80, и 443, и пусть он в случае необходимости работает и SSL-сертификатами, а apache пусть так и остается на
порту 8080.
Но в ISPmanager-4 изначально это было реализовано неправильно. В случае с одним только apache, он слушал порты 80 и 443. А в случае связи nginx +
apache получалась такая картина:
- для http-протокола nginx висел на 80-м порту, а apache на 8080-м;
- для https-протокола порт 443 обслуживал только один apache, а nginx из связки вообще выпадал.
Проблема долгое время не была актуальной среди наших клиентов, поэтому никто не придал ей особого значения. Но в сентябре 2016-го Google опубликовал
предупреждение о том, что начиная с января 2017-го Chrome будет помечать HTTP-страницы, на которых посетители вводят пароли или иные секретные данные,
как небезопасные:
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
А начиная с 2017-го года все больше и больше клиентов начало переходить на SSL.
И вот тут обнаружилась проблема, которую в первую очередь заметили владельцы выделенных серверов с сильно нагруженными сайтами: до использования SSL
сайт работал нормально, а после установки SSL-сертификата и настройки перенаправления посетителей на HTTPS-протокол, нагрузка неожиданно возросла. Но
виноват в этом вовсе не сертификат, а тот факт что по HTTPS-протоколу сайт стал обслуживать только один apache, а nginx выпал из связки.
Поэтому возник вопрос, как в этом случае задействовать nginx. Но все не так просто.
Оказывается, в каком-то 201X году разработчики ISPmanager выпустили исправление данной проблемы. Для того чтобы привести файлы конфигурации в
"актуальное состояние", необходимо в разделе "Настройки сервера" -> "Возможности" выделить строчки "Веб-сервер Apache" и "nginx [engine x] — HTTP и
прокси-сервер." и переактивировать их, нажав кнопку "Вкл." Ни в коем случае не пытайтесь сделать это!
По факту, данная функция не работает так как надо. Очень часто все это заканчивается тем, что ISPmanager выключает SSL на всех сайтах и удаляет все
сертификаты. И, к сожалению, техподдержка ISPsystem не желает решать эту проблему, ссылаясь на что поддержка ISPmanager-4 завершена 01.12.2016.
К сожалению, решения на данный момент нет. Иногда после некорректной переактивации удавалось вручню "допилить" файлы конфигурации так, чтобы панель
управления ISPmanager продолжала успешно работать и создавать новые домены уже в новом формате. Иногда нет. Если у вас на сервере много сайтов, а
также внесены ручные правки в httpd.conf и nginx.conf, с большой долей вероятности ничего не получится даже с нашей помощью. Необходимо задумываться о
переезде на сервер с Linux, т.к. ISPmanager-5 уже не поддерживает FreeBSD.
[Отредактировано 27.1.2018 кто timru]
|
|
|
timru
Administrator
Сообщения: 48
Зарегистрирован: 12.10.2008
Пользователя нет на форуме
|
| когда размещено 20.2.2018 в 09:33 |
|
|
Как повесить nginx на 443-й порт на сервере с ISPmanager-4 и включить поддержку протокола HTTP/2 самостоятельно.
Внимание!!! Используйте эту инструкцию только на свой страх и риск. На практике положительный результат достигался
меньше чем в половине случаев.
Вместо IP 185.12.92.111 подставляйте основной IP вашего сервера.
Эта тема посвящена сразу 2-м проблемам, и решает сразу обе.
1) Все больше людей перееводят свои сайты на HTTPS. Но у нас на серверах с ISPmanager-4 в большинстве случаев все настроено таким образом, что при
включении SSL для какого-то сайта, его начинает обслуживать только apache, без участия nginx. Из-за этого растет нагрузка.
2) Все больше людей хотят новый протокол HTTP/2. Но apache 2.2 его не поддерживает, требуется обновление до 2.4. Но ISPmanager-4 не поддерживает
apache 2.2, так что apache обновлять нельзя. А вот nginx можно. Начиная с версии 1.10 nginx поддерживает HTTP/2. Опять же, для этого требуется чтобы
на 443-м порту висел именно nginx, а не apache.
ISPmanager-4 не умеет сам корректно переключить nginx на 443-й порт. Поэтому придется поработать ручками.
Для начала, нам нужно изучить конфиги. Есть 2 варианта,
"новый формат конфигов":
- apache висит на порту 81, а не на 8080 (смотрите httpd.conf)
- в ispmgr.conf присутствуют строчки:
Option WebNginxNoSSL
WebModules nginx apache
"старый формат конфигов":
- apache висит на порту 8080, а не на 81 (смотрите httpd.conf)
- в ispmgr.conf отсутствует строчка "WebModules nginx apache"
Если у нас новый формат конфигов, то задача намного упрощается. Для начала, рассматриваем его.
1. Нужно слегка модифицировать сертификаты
В apache для сертификатов используются такие строчки
Для неподписанных:
SSLCertificateFile /home/httpd-cert/polzovatel/nashdomen.ru.crt
SSLCertificateKeyFile /home/httpd-cert/polzovatel/nashdomen.ru.key
Для подписанных:
SSLCertificateFile /home/httpd-cert/polzovatel/nashdomen.ru.crt
SSLCertificateKeyFile /home/httpd-cert/polzovatel/nashdomen.ru.key
SSLCertificateChainFile /home/httpd-cert/polzovatel/nashdomen.ru.bundle
(тут есть цепочка сертификатов)
В nginx нет отдельного файла для цепочки, поэтому если она у нас была в apache, то нам нужно объединить nashdomen.ru.crt и nashdomen.ru.bundle в один
файл nashdomen.ru.chained.crt
# cat nashdomen.ru.crt nashdomen.ru.bundle > nashdomen.ru.chained.crt
Аналогичную операцию проделываем для всех сертификатов.
2. Редактируем nginx.conf
В глобальных параметрах (до первого блока server{}) прописываем строчку:
--------------
include /usr/local/ispmgr/etc/nginx.domain;
--------------
Далее, ищем блоки, для которых нужно включить SSL. Например:
--------------
server {
server_name nashdomen.ru http://www.nashdomen.ru;
listen 185.12.92.111;
--------------
после этой строчки дописываем такую строчку:
--------------
listen 185.12.92.111:443 ssl http2;
--------------
а также в конце блока дописываем
--------------
ssl_certificate /home/httpd-cert/polzovatel/nashdomen.ru.chained.crt;
ssl_certificate_key /home/httpd-cert/polzovatel/nashdomen.ru.key;
--------------
Аналогичную операцию проделываем для всех блоков.
3. Редактируем httpd.conf
Комментируем эти строчки:
#LoadModule ssl_module libexec/apache22/mod_ssl.so
#Include etc/apache22/extra/httpd-ssl.conf
Удаляем такие строчки:
NameVirtualHost 185.12.92.111:443
Удаляем все блоки с виртуалхостами :443
<VirtualHost 185.12.92.111:443 >
бла-бла-бла
</VirtualHost>
4. Редактируем /usr/local/ispmgr/etc/ispmgr.conf
Удаляем строчку:
Option WebNginxNoSSL
5. Редактируем /usr/local/ispmgr/etc/nginx.domain
Как правило, в этом файле прописан левый IP, нужно заменить его на основной IP сервера везде, где он встречается.
6. Редактируем /etc/rc.local
Тут должна быть строчка:
/usr/local/ispmgr/sbin/ihttpd 185.12.92.111 1500
Если ее нет - добавляем.
IP должен быть основным IP сервера. Если IP левый - исправляем.
7. Выполняем команды:
# killall ispmgr
# /usr/local/ispmgr/sbin/ihttpd 185.12.92.111 1500
# /usr/local/etc/rc.d/apache22 restart
# /usr/local/etc/rc.d/nginx restart
Для усиления безопасности и повышения рейтингов в ssllabs нужно также сделать следующее:
# cd /usr/local/etc/nginx/ && openssl dhparam -out dhparam.pem 4096
Внимание! Эта команда выполняется реально долго, вплоть до 1 часа.
Также добавляем в глобальный блок nginx:
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
ssl_dhparam /usr/local/etc/nginx/dhparam.pem;
И перезапускаем nginx.
Полезные ссылки:
Проверка наличия поддержки HTTP/2:
https://tools.keycdn.com/http2-test
Проверка безопасности SSL:
https://www.ssllabs.com/ssltest/analyze.html?d=nashdomen.ru
---------------------------------------------------------------------------------
Если у нас старый формат конфигов, нужно сначала перейти на новый формат, а затем все делать по инструкции выше.
Что именно нужно править вручную в httpd.conf, nginx.conf и ispmgr.conf - я детально не изучал, но правок очень много. (Недостаточно исправить порт с
8080 на 81, изменений там в разы больше.)
Поэтому, как вручную переделать конфиги - я пока не знаю, и предлагаю вариант с использованием ISPmanager.
Переход на новый формат может осуществить сам ISPmanager, при условии что у нас до сих пор лежит старая база пэкеджей (папки с названиями пакетов в
/var/db/pkg) и до сих пор есть в системе программы типа pkg_*.
И САМОЕ ВАЖНОЕ: ПРИ ТАКОМ ПЕРЕХОДЕ ISPMANAGER УДАЛИТ ИЗ APACHE ВСЕ ЧТО КАСАЕТСЯ SSL, ВКЛЮЧАЯ ФАЙЛЫ СЕРТИФИКАТОВ, И НИЧЕГО НЕ ДОБАВИТ В
NGINX!!!!!
Поэтому обязательно делаем бэкапы:
# cd /home && cp -pr httpd-cert httpd-cert.bak
# cd /usr/local/etc && cp -pr apache22 apache22.bak
# cd /usr/local/etc && cp -pr nginx nginx.bak
# cd /usr/local/ispmgr/etc && cp -pr ispmgr.conf ispmgr.conf.bak
Затем идем в ISPmanager в раздел "Возможности", выделяем там apache и nginx, и нажимаем кнопку "Включить", невзирая на то что они и так уже включены.
После этого ждем минуты 3. Возвращаемся на сервер. Ужасаемся от того, что натворил ISPmanager. Возвращаем все обратно:
# cd /home && mv httpd-cert httpd-cert.new && httpd-cert.bak httpd-cert
# cd /usr/local/etc && mv nginx nginx.new && mv nginx.bak nginx && /usr/local/etc/rc.d/nginx restart
# cd /usr/local/etc && mv apache22 apache22.new && mv apache22.bak apache22 && /usr/local/etc/rc.d/apache22 restart
# cd /usr/local/ispmgr/etc && mv ispmgr.conf ispmgr.conf.new && mv ispmgr.conf.bak ispmgr.conf && killall ispmgr
После этого у нас полностью восстанавливается старая рабочая конфигурация, но зато есть новые конфиги.
Эти новые конфиги мы уже дорабатываем по инструкции выше.
[Отредактировано 20.2.2018 кто timru]
|
|
|
|
