Certbot и webroot
Мы будем получать сертификаты по методу webroot без перенастройки или остановки веб-сервера, под которым подразумевается nginx. Нам нужен какой-то каталог, в который будет писать свои файлы, и какой должен быть доступен из сети удостоверяющему серверу согласно протокола ACME.
Чтобы не писать каждый раз длинную строку из опций, а еще лучше — не вспоминать о них, запишем основные настройки в файл конфигурации, который ожидает найти в :
Последняя директива нужна чтобы избавить нас от прелестей и красивостей ncurses, что нужно чтобы вы могли сравнить вывод команд здесь, в этой статье, и у себя.
Также нам нужно мягко перезагрузить nginx (без перерыва в обслуживании) при успешном обновлении сертификатов. Ничего не мешает в этот же момент перезапускать и другие сервисы вроде Postfix, использующие полученные сертификаты. Команды указываются через точку с запятой.
Что будет делать Certbot
Ожидается что будет создавать необходимые для проверки прав на домен файлы в подкаталогах ниже по иерархии к указанному. Вроде таких:
Эти файлы должны будут быть доступны из сети на целевом домене по крайней мере по HTTP:
Для следующих проверок создадим какой-то такой файл:
Установка и использование сертификатов
Certbot не перезаписывает сертификаты, а заменяет их ссылками на самые актуальные варианты сертификатов в определенном каталоге, одноименном с первым доменом сертификата (т.е. ).
Давайте посмотрим что за файлы у нас есть:
С этим знанием мы можем задать настройки SSL для nginx:
Как видите, нигде в конфиге не используется, и это не ошибка. Для nginx он не нужен.
Полный рабочий пример конфига:
Конфиг для переадресации с голого домена без www:
Подразумевается что вы используете какой-то локальный сервер для кеширования DNS запросов. Если это не так, то в директиве нужно заменить на IP используемого DNS сервера.
Настройки шифров и прочее подобное (, ) лучше держать вне конфигов отдельных серверов.
Шаг 9. Настройте SSL и Cipher Suites
Конфигурация nginx по умолчанию позволяет использовать небезопасные старые версии протокола TLS (согласно официальной документации: ssl_protocols TLSv1 TLSv1.1 TLSv1.2). Это может привести к таким атакам, как атака BEAST. Поэтому мы рекомендуем вам не использовать старые протоколы TLS и изменять конфигурацию для поддержки только новых, безопасных версий TLS.
Для этого добавьте следующую директиву в раздел server файла конфигурации nginx:
Кроме того, вы должны указать наборы шифров, чтобы убедиться, что уязвимые наборы не поддерживаются. Чтобы выбрать лучшие комплекты шифров, прочитайте нашу статью об усилении шифрования TLS и добавьте директиву ssl_ciphers в раздел сервера для выбора шифров (как предлагается в статье об усилении шифрования). Мы также рекомендуем добавить следующую директиву в раздел сервера:
Эта директива позволит принять решение о том, какие шифры использовать, на стороне сервера, а не на стороне клиента.
Шаг 4. Настройка NGINX
Открываем/создаем файл конфигурации для виртуального домена:
vi /etc/nginx/conf.d/test.dmosk.local.conf
* где test.dmosk.local.conf может называться как угодно, главное — чтобы на конце было .conf.
Приводим его к следующему виду:
server {
listen 80;
server_name test-http2.dmosk.local;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
ssl on;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
location / {
root /usr/share/nginx/html;
}
}
* в первых 4 строкам мы указываем перенаправлять все http-запросы на https; /etc/nginx/ssl/ — путь, где лежат наши файлы сертификатов; /usr/share/nginx/html — корневая директория, где лежат файлы сайта.
Проверяем корректность настройки nginx:
nginx -t
И перезапускаем его:
systemctl restart nginx
* на более ранних системах service nginx restart.
Подготовка среды
Необходимо убедиться, что мы находимся в нужном каталоге для сборки — это может быть произвольная папка, которую мы создадим. В моем примере я буду использовать домашнюю директорию пользователя. Проверить текущее положение можно командой:
$ pwd
Мы должны увидеть что-то на подобие:
/home/builder
Перейти в домашний каталог пользователя можно командой:
$ cd ~
Создадим структуру каталогов для сборки:
$ rpmdev-setuptree
В нашей текущем каталоге должна появиться папка rpmbuild — а в ней:
- BUILD — содержит все файлы, которые появляются при создании пакета.
- RPMS — сюда будут складываться готовые пакеты.
- SOURCES — для исходников, из которых и будут собираться RPM-пакеты.
- SPECS — для файлов с описанием процесса сборки.
- SRPMS — для исходников RPM-файлов.
Мы готовы к загрузке исходника и его подготовке.
Типы статического контента
| «Легкий» контент: html, css, js, xml, rss, txt. Он хорошо поддается сжатию, требует мало места для хранения. Приминение nginx в любом случае даст заметный прирост производительности. | |
| «Тяжелый» контент: фото, видео, аудио-файлы. Узким местом выступает, в первую очередь дисковая система, размер оперативной памяти, пропускная способность канала. Задача раздачи такого типа контента делится на 2 — хранение контента и, собственно, раздача контента. С помощью nginx можно добиться минимального расхода памяти и процессорного времени, но при увеличении нагрузки все же прийдется собирать RAID-масив. |
Как работает Nginx
В отличие от обычного веб-сервера, Nginx не создаёт один поток под каждый запрос, а разделяет его на меньшие однотипные структуры, называемые рабочими соединениями. Каждое такое соединение обрабатывается отдельным рабочим процессом, а после выполнения они сливаются в единый блок, возвращающий результат в основной процесс обработки данных. Одно рабочее соединение может обрабатывать до 1024 запросов одного вида одновременно.
Практическое применение
- Отдельный порт/IP. При наличии большого количества статичного контента или файлов для загрузки, можно настроить на отдельном порту или IP, чтобы осуществлять раздачу. При большом количестве запросов рекомендуется ставить отдельный сервер и подключать к нему Nginx.
- Акселерированное проксирование. В таком случае все пользовательские запросы на статичный контент (картинки, простой HTML, JavaScript, CSS-файлы) поступают сначала на Nginx, а он их обрабатывает самостоятельно. При этом никаких изменений исходного кода не требуется.
- Nginx и FastCGI. Если поддерживается технология FastCGI, Apache вообще можно не использовать. Но в таком случае может потребоваться модификация кодов скриптов.
Для начала
Вы должны неплохо знать C. Не просто его синтаксис, а то, как работать со структурами и не бояться указателей и ссылок на функции, а также иметь представление о препроцессоре. Если вам надо немного освежить знания, то ничто не сможет сравниться с K&R(англ.).
Полезно понимать основы HTTP. Мы же, вообще-то, собираемся работать с web-сервером.
Пригодятся знания структуры конфигурационного файла Nginx’а. Вот основные моменты: существуют четыре контекста (называеются они main — главный, server — сервер, upstream — апстрим, и location — локейшн)в которых могут быть директивы с одним и более параметрами. Директивы в главном контексте применяются ко всему-всему; директивы из котекста сервера применяются к конкретному хосту/порту; директивы в апстриме описывают набор бэкендов; а директивы в контексте локешна применяются к разным путям запроса (например, «/», «/images» и т.д.) Локешн наследует конфигурацию содержащему его серверному контексту, а сервер наследует главному контексту. Контекст апстрима не наследует никому, у него собственные директивы, которых больше нигде не используются. Я буду иногда упоминать эти четыре контекста, так что… не забывайте про них.
Ну что же, начнем!
Получаем сертификаты
Ввиду лимитов на обращения сначала попробуем получить сертификат для основного домена в режиме «сухого прогона»:
Этот вызов должен завершиться без сообщений об ошибках.
Если так, то получим сертификат уже в самом деле.
Символические ссылки на сертификаты Certbot помещает в каталоги с разбивкой по доменам.
Проверим полученные сертификаты.
Команда должна вывести список доменов для каждого из имеющихся сертификатов.
Чтобы не занимать в голове место порядком ключей для , добавим обёртку для него.
Использовать её очень просто.
Добавить поддомен в сертификат
Можно добавить до сотни доменов и поддоменов в существующий сертификат.
Это полезно, если вы забыли добавить поддомен www.
Поддержка старых клиентов
Если вам критически важна поддержка старых клиентов без SNI (напр. IE в WinXP, устаревшие версии Java и Python), то стоит зафиксировать список доменов для сертификата .
В этом случае получение сертификатов происходит без явного указания доменов.
С этим подходом любой сможет получить список находящихся у вас на сервере сайтов из данных сертификата, не говоря уж о необходимости править конфиги каждый раз.
Потому лучше без него.
Подготовим nginx к получению сертификатов
В общем случае для получения сертификата необходимо во всех блоках добавить следующий блок до других блоков :
Понятно, что вписывать для каждого сайта такой блок явно — это моветон, потому создадим файл с содержанием блока выше.
Затем для каждого домена и поддомена, для которых нужно получить сертификаты, в блоке перед всеми блоками укажем:
Хосты-редиректоры (например, с голого домена на www) можно пропустить. ACME сервер обязан учитывать стандартную переадресацию.
Перезагрузим nginx и проверим что наш тестовый файл виден:
После проверки лучше удалить тестовый файл — любит удалять за собой всё лишнее, а такой файл будет мешать и вызывать сообщение об ошибке (Unable to clean up challenge directory).
Теперь у нас всё готово чтобы .
О переадресации с кодами 301 и 302
Как было уже сказано, ACME сервер Boulder учитывает переадресацию . В этом смысле не имеет значения где, в конечном счете, находятся файлы, требуемые для прохождения проверок. Переадресация возможна даже , без ограничений по конечному протоколу HTTP или HTTPS. Сами .
Если вы можете получить эти файлы с помощью с ограничением в десять переадресаций, то и Boulder эти файлы увидит. Не должно быть .
Это удобно если у вас сложная структура переадресаций между разными версиями сайтов. Должно быть достаточно подключить тот блок с только на основном сайте для получения сертификатов для всех остальных.
Проверка всегда начинается с запроса по протоколу HTTP на 80 порту.
Если у вас уже всё зашифровано…
Если у вас уже все сайты работают по HTTPS, то вся схема будет работать если у вас настроен переадресующий сервер на 80 порту, сохраняющий в ответе.
Другое дело что можно сократить путь и подключить наш блок с в умолчальном сервере для 80 порта, который делает переадресацию на HTTPS. Тогда не нужно будет ничего дописывать в конфиги отдельных сайтов.
Пример конфигурации такого переадресующего всё-подряд-на-HTTPS сервера:
Такой конфиг стоит определить в , в стороне от конфигов конкретных сайтов.
Сервер запускаем явно на внешнем IP чтобы не перенастраивать Apache на другой порт. Если для вас это не проблема, то указание имени сервера в директиве можно пропустить.
Если нужно получить сертификат для домена без сайта…
Типичный пример — сертификат для выделенных под SMTP или IMAP серверов, на которых вообще нет каких-то сайтов. Либо используйте универсальный переадресатор что выше, либо…
К сожалению, протокол ACME требует чтобы такой сервер был доступен во время каждой проверки. Это практически эквивалентно постоянной доступности, ввиду требования получения и обновления сертификатов без перезагрузки сервера. Не удаляйте такой конфиг после получения сертификата.
Если у вас только Apache2…
Если у вас Apache2, а перейти на всеми любимый nginx возможности нет, то… Добавьте следующие строчки в :
Затем
И обязательно проверьте, так:
Существует много причин почему такая схема может у вас в Apache2 не заработать. Пары экранов текста не хватит чтобы описать их все. Не серчайте — статья про nginx.
Делиться (не) значит заботиться
До недавнего времени у нас был только один экземпляр NGINX Ingress, ответственный за проксирование запросов ко всем приложениям во всех окружениях (dev, staging, production). Я убедился на собственном опыте, что это плохая идея. Не складывайте все яйца в одну корзину.
Думаю, то же самое может быть сказано и по поводу использования одного кластера для всех окружений, однако мы выяснили, что такой подход приводит к более эффективному расходованию ресурсов. Мы запускали dev/staging-поды на уровне QoS с негарантированной доставкой (best-effort QoS tier), используя таким образом ресурсы, оставшиеся от production-приложений.
Обратной стороной медали здесь является то, что мы оказываемся ограничены в действиях, которые можно выполнять по отношению к кластеру. Например, если нам потребуется провести нагрузочное тестирование staging-сервиса, придется быть очень осторожными, чтобы не повлиять на боевые сервисы, запущенные в этом же кластере.
Несмотря на то что контейнеры дают в общем случае хороший уровень изоляции, они по-прежнему зависят от разделяемых ресурсов ядра, которые являются объектом злоупотреблений.
Одна установка Ingress на каждое окружение
Мы уже говорили о том, что нет причин, по которым не стоит использовать по одному Ingress-контроллеру на каждое окружение. Это дает дополнительный уровень защиты на тот случай, если с сервисами в dev и/или staging начнутся проблемы.
Некоторые преимущества этого подхода:
- Появляется возможность использовать различные настройки для разных окружений.
- Позволяет тестировать обновления Ingress перед применением их в production.
- Можно избежать раздувания конфигурации NGINX записями множества вышестоящих серверов и сервисов, связанных с эфемерными и/или нестабильными окружениями.
- Ускоряются перезагрузки конфигурации и сокращается количество этих событий в течение дня (позже мы обсудим, почему нужно стремиться к минимизации количества перезагрузок).
Ingress-классы в помощь
Одним из способов заставить разные -контроллеры управлять разными Ingress-ресурсами является использование разных имен классов ingress для каждой отдельной установки ingress, а затем аннотирование -ресурсов с целью указать, кто кем должен управлять.
Знай свой конфиг
Красота Ingress-контроллера том, что вы можете положиться на эту замечательную программу в вопросе генерации и перезагрузки конфигурации прокси-сервера и больше по этому поводу не беспокоиться. Вам даже не обязательно быть знакомым с нижележащей технологией (NGINX в данном случае). Правда? Нет!
Если вы этого еще не сделали, обязательно посмотрите на сгенерированную для вас конфигурацию. Для NGINX Ingress-контроллера можно получить содержимое с помощью .
Теперь попробуйте найти что-нибудь несовместимое с вашей установкой. Хотите пример? Давайте начнем с ;
Первая проблема: в настоящий момент (будет ли это когда-либо исправлено?) NGINX ничего не знает о cgroups, а значит, в случае будет использовано значение количества хоста, а не количества «виртуальных» процессоров, как определено в Kubernetes resource requests/limits.
Проведем эксперимент. Что будет, если мы попробуем загрузить следующий файл конфигурации NGINX на двухъядерном сервере в контейнере, ограниченном только одним CPU? Сколько рабочих процессов будет запущено?
Таким образом, если вы планируете ограничить ресурсы процессора, которые доступны NGINX Ingress, не стоит позволять nginx создавать большое количество рабочих процессов в одном контейнере. Лучше всего явно указать их необходимое количество с помощью директивы .
Теперь рассмотрим директиву . Значение параметра явно не указано и по умолчанию для Linux равно . Если параметр ядра равен, скажем, , то нужно присвоить соответствующее значение. Другими словами, убедитесь в том, что конфигурация nginx настроена с учетом параметров ядра.
Но на этом не останавливайтесь. Такое упражнение необходимо провести для каждой строчки сгенерированного файла конфигурации. Только посмотрите на все те параметры, которые позволяет поменять Ingress-контроллер. Исправляйте без колебаний все, что не подходит для вашего случая. Большинство параметров NGINX могут быть настроены с помощью записей и/или аннотаций .
Параметры ядра
С Ingress или без него, всегда проверяйте и настраивайте параметры нод в соответствии с ожидаемой нагрузкой.
Это достаточно сложная тема, поэтому я не планирую здесь подробно ее раскрывать. Дополнительные материалы по этом вопросу можно найти в разделе .
Kube-Proxy: Таблица Conntrack
Тем, кто использует Kubernetes, думаю, не нужно объяснять, что такое Сервисы и для чего они предназначены. Однако полезно будет рассмотреть некоторые особенности их работы.
Другими словами, отправленные на IP сервиса пакеты направляются (напрямую или через балансировщик) на соответствующий (пары подов, которые соответствуют label selector сервиса) с помощью правил iptables, управляемых kube-proxy. Соединения с IP-адресами сервиса отслеживаются ядром с помощью модуля , и эта информация хранится в RAM.
Поскольку различные параметры conntrack должны быть согласованы друг с другом (например, и ), kube-proxy, начиная работу, устанавливает разумные значения по умолчанию.
Это неплохой вариант, но вам может потребоваться увеличить значения этих параметров, если мониторинг показывает, что у вас заканчивается место, выделенное для conntrack. Однако необходимо помнить, что увеличение значений этих параметров ведет к повышенному потреблению памяти, так что поаккуратнее там.
Мониторинг использования conntrack
Подготовка системы
1. Устанавливаем необходимые пакеты:
yum install wget rpm-build rpmdevtools gcc make
* где:
- wget — утилита для загрузки файлов по сети.
- rpm-build — включает в себя утилиту rpmbuild, с помощью которой будет выполняться сама сборка установочного пакета.
- rpmdevtools — позволит нам использовать утилиту rpmdev-setuptree, с помощью которой мы сможем создать рабочую среду в виде каталогов для сборки.
- gcc — компилятор СИ. Необходим для сборки.
- make — утилита для сборки исходников.
2. Устанавливаем зависимости:
yum install openssl-devel zlib-devel pcre-devel
* данные пакеты необходимы именно для нашего варианта сборки. Имейте ввиду, что в вашем случае может понадобиться больше зависимостей. Так или иначе, если в системе не будет хватать необходимых пакетов, мы получим ошибку при попытке выполнить сборку RPM.
3. Создаем пользователя.
Делать готовые установочные сборки пакетов очень опасно от пользователя root. Если мы допустим ошибку с путями, файлы могут перетереть или удалить важные для работы директории. Стоит создать отдельного пользователя и работать под ним.
Выполняем команду:
useradd builder -m
* в данном примере мы создадим пользователя builder. Опция -m сразу создаст домашний каталог для пользователя.
Теперь заходим под данным пользователем — последующие команды мы будем выполнять от него:
su — builder
Другие способы
Открой файл /etc/sysctl.conf и помести в него следующие строки:
Поместив корневой каталог Web-сервера в выделенный раздел и запретив на нем размещение любых исполняемых файлов и файлов-устройств, ты обезопасишь остальную часть системы от тех, кто сможет получить доступ к корню Web-сервера. При этом запись в файле /etc/fstab должна иметь примерно такой вид:
Помести nginx в chroot/jail-окружение
Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.
Установи правила SELinux для защиты nginx
Хорошей альтернативой изолированным средам исполнения являются локальные системы обнаружения и предотвращения вторжений, такие как SELinux или AppArmor. Будучи правильно настроенными, они смогут предотвратить попытки взлома Web-сервера. По дефолту ни одна из них не настроена для работы в связке с nginx, однако в рамках проекта SELinuxNginx (http://sf.net/projects/selinuxnginx/) были созданы правила для SELinux, которые может использовать любой желающий. Остается только скачать и установить:
Настрой брандмауэр
Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.
Ограничь количество соединений с помощью брандмауэра
Для не слишком нагруженного Web-сайта хорошей идеей будет ограничить количество попыток соединений с одного IP-адреса в минуту. Это сможет уберечь тебя от некоторых типов DoS-атак и брутфорса. В Linux это можно сделать с помощью стандартного iptables/netfilter-модуля state:
Правила урезают лимит на количество подключений с одного IP в минуту до 15. То же можно сделать и с помощью pf:
Кроме лимита на количество последовательных подключений (15 в минуту), данное правило устанавливает дополнительный лимит на количество одновременных подключений равный 100.
Настрой PHP
Если ты используешь nginx в связке с PHP, не забудь настроить и его. Вот как должен выглядеть конфигурационный файл /etc/php/php.ini защищенного сервера:
Установка Nginx на CentOS
Рассмотрим практически установку Nginx на Linux, взяв за основу один из самых популярных дистрибутивов данной операционной системы – CentOS.
- Добавляем yum-репозиторий Nginx на ОС с помощью команды:
sudo rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
- Для установки используем команду sudo yum install nginx. Подтверждаем появившееся извещение.
- Для запуска сервера используем команду:
sudo systemctl start nginx.service
- Проверить, успешна ли установка, можно, посетив общественный IP-адрес сервера. Узнать его можно через команду:
ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//' - Чтобы Nginx автоматически запускался при загрузке ОС, вводим:
sudo servicectl enable nginx.service
Изменение конфигурационного файла NGINX
Перед сборкой мы можем изменить конфигурационный файл веб-сервера, который уже попадет в наш установочный пакет. Так как мы рассматриваем пример работы с модулем spnego, внесем настройки для него.
Открываем файл:
$ vi rpmbuild/SOURCES/nginx.conf
Внесем следующие изменения:
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;include /etc/nginx/modules/*.conf;
events {
…
* в нашем примере внесено всего 2 изменения:
- worker_processes, который отвечает за распределение нагрузки по ядрам уже давно рекомендуется выставлять в значение auto.
- Также мы дописали строку include /etc/nginx/modules/*.conf, которая укажет нашему веб-серверу подгружать все конфигурационные файлы из каталога modules.
Также активируем для сайта по умолчанию опцию для модуля spnego. Открываем файл:
$ vi rpmbuild/SOURCES/nginx.vh.default.conf
Это файл, который будет находиться по пути /etc/nginx/conf.d/default.conf. Внесем в него изменения:
location / {
root /usr/share/nginx/html;
index index.html index.htm;
auth_gss on;
auth_gss_realm DMOSK.RU;
auth_gss_keytab /etc/http.keytab;
auth_gss_service_name HTTP/test.dmosk.ru;
}
Пересобираем RPM:
$ rpmbuild -bb rpmbuild/SPECS/nginx.spec
Выполняем установку новых пакетов на целевом сервере. В нашем примере мы можем переустановить пакеты командами:
rpm -Uvh —force nginx-1.19.3-1.el7.ngx.x86_64.rpm
rpm -Uvh —force nginx-module-spnego-1.19.3-1.el7.ngx.x86_64.rpm
* напоминаю, что у нас используется версия 1.19.3. Чтобы данные команды отработали, необходимо находиться в каталоге, где лежат наши установочные файлы.
Мы должны увидеть изменения в конфигах, которые сделали до сборки.
Apache
Для поддержки файла .htaccess, который используется многими сайтами, необходимо установить и настроить веб-сервер Apache.
Устанавливаем apache и модуль для php:
apt-get install apache2 libapache2-mod-php
Заходим в настройки портов:
vi /etc/apache2/ports.conf
И редактируем следующее:
Listen 8080
#<IfModule ssl_module>
# Listen 443
#</IfModule>
#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>
* мы настроили прослушивание на порту 8080, так как на 80 уже работает NGINX. Также мы закомментировали прослушивание по 443, так как и он будет слушаться NGINX.
Теперь открываем настройку следующего модуля:
vi /etc/apache2/mods-available/dir.conf
И добавляем впереди индексных файлов index.php:
<IfModule dir_module>
DirectoryIndex index.php index.html …
</IfModule>
* если не указан конкретный скрипт, сначала веб-сервер пытается найти и запустить index.php, затем index.html и так далее.
Открываем основной конфигурационный файл для apache:
vi /etc/apache2/apache2.conf
Рядом с опциями Directory дописываем:
<Directory /var/www/*/www>
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
</Directory>
* где Directory указывает на путь, для которого мы хотим задать настройки; AllowOverride — позволит переопределить все настройки с помощью файла .htaccess; Options задает некоторые настройки: Indexes разрешает списки каталогов, ExecCGI разрешает запуск cgi скриптов, Require all granted — предоставляет всем доступ к сайтам в данном каталоге.
Ниже допишем:
<IfModule setenvif_module>
SetEnvIf X-Forwarded-Proto https HTTPS=on
</IfModule>
* этой настройкой мы при получении заголовка X-Forwarded-Proto со значением https задаем переменную $_SERVER равную on. Данная настройки критична для функционирования некоторых CMS.
Запрещаем mpm_event:
a2dismod mpm_event
* по умолчанию, apache2 может быть установлен с модулем мультипроцессовой обработки mpm_event. Данный модуль не поддерживает php 7 и выше.
Разрешаем модуль мультипроцессовой обработки mpm_prefork:
a2enmod mpm_prefork
Разрешаем модуль php:
a2enmod php7.4
* в данном примере установлен php версии 7.4.
Разрешаем модуль setenvif:
a2enmod setenvif
Разрешаем модуль rewrite:
a2enmod rewrite
В процессе включения модулей, если мы видим «Module … already enabled», значит модуль уже включен.
Разрешаем автозапуск Apache и перезапускаем службу:
systemctl enable apache2
systemctl restart apache2
Открываем браузер и вводим в адресную строку http://<IP-адрес сервера>:8080. Мы должны увидеть привычную страницу:
* в разделе Server API мы должны увидеть Apache.
NGINX + Apache
Ранее мы настроили связку nginx + php-fpm. Теперь настроим nginx + apache. Открываем конфигурационный файл nginx для сайта по умолчанию:
vi /etc/nginx/sites-enabled/default
Находим наш настроенный location для php-fpm:
…
location ~ \.php$ {
set $root_path /var/www/html;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
…
и меняем на:
…
location ~ \.php$ {
proxy_pass http://127.0.0.1:8080;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
Проверяем и перезапускаем nginx:
nginx -t
systemctl restart nginx
Пробуем открыть в браузере http://<IP-адрес сервера> — должна открыться та же страница, что при проверке Apache (с добавлением 8080):
Apache Real IP
Запросы на apache приходят от NGINX, и они воспринимаются первым как от IP-адреса 127.0.0.1. На практике, это может привести к проблемам, так как некоторым сайтам необходимы реальные адреса посетителей. Для решения проблемы будем использовать модуль remoteip.
Создаем конфигурационный файл со следующим содержимым:
vi /etc/apache2/mods-available/remoteip.conf
<IfModule remoteip_module>
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1/8
</IfModule>
Активируем модуль:
a2enmod remoteip
Перезапускаем apache:
systemctl restart apache2
Для проверки настройки открываем браузер и вводим в адресную строку http://<IP-адрес сервера>, где откроется наша страница phpinfo. В разделе Apache Environment мы должны увидеть внешний адрес компьютера, с которого обращаемся к серверу в опции REMOTE_ADDR.
