Apache mod proxy: Apache HTTP Server Version 2.4

Содержание

Настройка Reverse Proxy Apache (Debian 8) с автоматической выдачей Let’s Encrypt / Хабр

Так как зачастую, сайтов в организации много, а IP адресов мало, нужно иметь решение с Reverse Proxy. Для моих целей раньше всегда выступал Microsoft TMG, но у него есть свои недостатки, как и плюсы. Один из основных минусов, это то что на TMG нужно подгружать сертификаты публикуемого ресурса, что с Let’s Encrypt довольно неудобно, ввиду обновления сертификатов каждые 90 дней.

Решение было найдено: поднять Reverse Proxy на Apache и сделать так, чтобы работала автовыдача сертификатов Let’s Encrypt. А после чего спокойно публиковать его на Firewall, при этом порты буду перенаправляться с http на https.

За основу берем что у нас стоит чистый Debian GNU/Linux 8 (jessie). Подробнее под катом.

Ну что-ж, поехали.

aptitude install -y build-essential
aptitude install -y libapache2-mod-proxy-html libxml2-dev
aptitude install -y apache2

После чего активируем следующие модули:

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_ajp
a2enmod rewrite
a2enmod deflate
a2enmod headers
a2enmod proxy_balancer
a2enmod proxy_html
a2enmod proxy_ftp
a2enmod proxy_connect
a2enmod ssl

и рестартуем Apache:

service apache2 restart

Тут нас поджидает первая неудача, Apach’у для правильной работы не хватает модуля mod_xml2enc, НО! в Jessie этот модуль не работает, нам последовательно нужно внести следующие команды:

aptitude install apache2-prefork-dev libxml2 libxml2-dev apache2-dev
mkdir ~/modbuild/ && cd ~/modbuild/
wget http://apache. webthing.com/svn/apache/filters/mod_xml2enc.c
wget http://apache.webthing.com/svn/apache/filters/mod_xml2enc.h
apxs2 -aic -I/usr/include/libxml2 ./mod_xml2enc.c
cd ~
rm -rfd ~/modbuild/
service apache2 restart

После чего, все у нас хорошо, модуль стоит. Едем дальше )

Так как мы хотим опубликовать HTTPS сайт, до того момента пока мы не установим Let’s Encrypt, нам нужно сделать самоподписанный сертификат для нашего сайта, вводим комманду:

mkdir /etc/apache2/ssl
cd /etc/apache2/ssl
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crt

Нам нужно создать файл конфигурации и назвать его понятным именем:

touch /etc/apache2/sites-available/sambi4.conf

И задаем файлу примерно такое содержание:

<VirtualHost *:80>
ServerName sambi4.ru
Redirect permanent / https://sambi4.ru/ #отвечает за перенаправление на https
</VirtualHost>
<VirtualHost *:443>
SSLEngine On
SSLProxyEngine On
ProxyRequests Off
ProxyPreserveHost On
ProxyVia full
SSLCertificateFile /etc/apache2/ssl/server.  crt #указываем путь к нашему самоподписанному сертификату
SSLCertificateKeyFile /etc/apache2/ssl/server.key #указываем путь к нашему самоподписанному ключу сертификата
ProxyHTMLInterp On
ProxyHTMLExtended On
<proxy *>
Order deny,allow
Allow from all
</proxy>
ProxyPass / https://192.168.199.78/ #IP адрес публикуемого ресурса.
ProxyPassReverse / https://192.168.199.78/ #IP адрес публикуемого ресурса.
ServerName sambi4.ru
ServerAdmin [email protected] #считается хорошим тоном указывать email админа
DocumentRoot "/var/www/html" #эта строка нужна для того чтобы апач запустился, без нее он не сможет опубликовать ваш ресурс.
</VirtualHost>

После завершения создания, не забываем включить наш сайт:

a2ensite /etc/apache2/sites-available/sambi4.conf

перезапускаем Apache:

service apache2 restart

После всех проделанных процедур, мы имеем настроеный Reverse Proxy на Apache2, теперь можно приступить к настройке Let’s Encrypt:

Из всех бесплатных сертификатов, жив остался только Let’s Encrypt, но его особенность в том, что сертификат выдается сроком на 3 месяца.

Нам нужно поставить сертификат, и сделать автоматическую выдачу при завершении срока сертификации.

echo 'deb http://ftp.debian.org/debian jessie-backports main' | tee /etc/apt/sources.list.d/backports.list

после:

aptitude update

ну а теперь ставим сам Let’s Encrypt:

aptitude install -y python-certbot-apache -t jessie-backports

Дожидаемся процесса установки, и пробуем выпустить сертификат:

certbot --apache

И вот тут нас поджидает неудача:

ERROR:letsencrypt_apache.configurator:No vhost exists with servername or alias of: sambi4.ru. No vhost was selected. Please specify servernames in the Apache config

Связано это с тем, что в репозитариях до сих пор старая версия (на момент написания 0.10.2), в которой наблюдаются ошибки. А именно ошибки в python-скриптах. Решение как обычно просто:
Качаем свежую версию certbot:

git clone https://github.com/certbot/certbot.git

После чего, идем по пути:

 cd /usr/lib/python2.7/dist-packages

Удаляем папки (а лучше делаем бэкап):

acme
certbot
certbot_apache
И копируем файлы из нового релиза:

cp /root/certbot/certbot /usr/lib/python2.7/dist-packages/
cp /root/certbot/acme/acme/ /usr/lib/python2.7/dist-packages/
cp /root/certbot/certbot-apache/certbot_apache/ /usr/lib/python2.7/dist-packages/

Теперь можно со спокойной душой запускать процесс выпуска сертификата:

certbot --apache

Отвечаем на вопросы и все!

Поздравляю, сертификат мы выпустили, теперь нужно добавить скрипт автопродления сертификата, т. к. Let’s Encrypt выдает сертификаты сроком только на 90 дней (мы об этом помним).

Все просто. Нам в cron нужно добавить строчку:

30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log

Т.е. набираем:

crontab -e

И добавляем нашу строку (обязательно перейти на следующую срочку, иначе не сохранится)

И все, повторить бесконечное множество раз с Вашими другими ресурсами.

Удачи, админы!

Шпаргалка ;): Настройка mod_proxy в Apache

В общем, был такой таск: есть у нас локальная сетка и маршрутизатор Peplink. В локальной сетке на многих тазиках крутятся сайты, которые должны быть доступны извне. Как это сделать? Разносить по портам — не вариант, т. к. пользователю неудобно всё-таки набирать URL типа блаблабла:8081. Решение — использовать HTTP-прокси, а на тазик с ним открыть в маршрутизаторе порты 80, 443. Для проксирования обычно используют nginx, но апач тоже отлично справляется с этой задачей.

Так сложилось, что тазик с прокси был Убунтой (клиент категорически н ехотел работать с другими дистрибутивами Linux), а «в Убунте всё не как у людей» (с) 🙂 потому конфигурация её несколько отличается от других дистрибутивов. Но, приняв философию Убунты, я понял, что многие решения в ней очень даже удобны, хотя некоторые мне не нравятся — например, отсутствие пользователя root. Но это уже философия, грозящая холиваром, потому перейдем к делу 🙂

В убунте манипулирование апачем происходит с помощью глобальных команд: включение/выключение виртуал хостов — a2ensite / a2dissite с одним аргументом — пути к конфигу, в котором прописан виртуал хост. Включение/выключение модов или расширений происводится командами a2enmod / a2dismod.

В общем, алгоритм работы такой:

1) Нужно включить необходимые модули апача. Устанавливаем:

sudo apt-get install libapache2-mod-proxy-html libapache2-mod-gnutls

Разрешаем:

sudo a2enmod proxy

sudo a2enmod ssl

sudo a2enmod cache

sudo /etc/init. d/apache2 restart

2) Делаем конфиг виртуал хоста (по 1му файлу на 1 хост!) и помещаем его в /etc/apache2/sites-available. Пример HTTPS конфига проксирования на тазик с Confluence — это такая джавовская веб-морда для программистов и не только, работающая на Apache Tomcat (с портом 8444):

<VirtualHost *:443>

#мыло админа и документ рут не существующий — т. к. апач требует хоть какой-то обязательно
ServerAdmin [email protected]
DocumentRoot «/etc/httpd/docs/dummy-host.example.com»

#вот здесь внимательно заполняем теми данными, которые у нас есть в ДНС-ах
ServerName conf.mydomain.com
ServerAlias www.conf.mydomain.com

#настройки SSL — включение SSL и пути к файлам ключей
SSLEngine On
SSLCertificateFile /etc/ssl/server.crt
SSLCertificateKeyFile /etc/ssl/server.

key

#включение прокси для данного виртуал хоста и некоторые настройки. Я в них особо не вчитывался — работает так отлично 🙂
SSLProxyEngine On
ProxyRequests Off
ProxyPreserveHost On
ProxyVia full

<proxy *>
Order deny,allow
Allow from all
</proxy>

#чего и куда проксируем / означает что проксируются все запросы к сайту, начиная с корня
ProxyPass / https://192.168.1.132:8444/
ProxyPassReverse / https://192.168.1.132:8444/

</VirtualHost>

Замечание: Не забываем создать ssl-сертификаты либо положить с другой машины в папку /etc/ssl/ и выставить права (chmod 700 /etc/ssl/

и на файлы: chmod 600 /etc/ssl/server.crt и chmod 600 /etc/ssl/server.key)

Для HTTP virtual host убираются строчки, связанные с SSL и меняется порт 443 на 80, SSLProxyEngine On меняется на ProxyEngine On. Ну и в директиве ProxyPass https на http — понятное дело.

Затем командой

sudo a2ensite /etc/apache2/sites-available/конфиг_виртуал_хоста

Активируем наш виртуал хост. После этого нужно перезагрузить апач:

sudo /etc/init.d/apache2 reload

Усё, будет проксировать.

После долгого секса с Debian выяснил, что надо еще дополнительно сделать:

sudo a2enmod proxy_connect

sudo a2enmod proxy_html

sudo a2enmod proxy_ftp

Руководство по обратному прокси-серверу — HTTP-сервер Apache, версия 2.4

HTTP-сервер Apache, версия 2.4

Доступные языки: en | fr

В дополнение к тому, что он является «базовым» веб-сервером и предоставляет статические и динамическое содержимое для конечных пользователей, Apache httpd (а также большинство других серверы) также может выступать в качестве обратного прокси-сервера, также известного как «шлюзовый» сервер.

В таких случаях httpd сам не генерирует и не размещает данные. а контент получает один или несколько внутренних серверов, которые обычно не имеют прямого подключения к внешней сети. В качестве httpd получает запрос от клиента, сам запрос прокси на один из этих внутренних серверов, который затем обрабатывает запрос, генерирует содержимое, а затем отправляет это содержимое обратно на httpd, который затем генерирует фактический HTTP-ответ обратно клиенту.

Существует множество причин для такой реализации, но в целом типичные обоснования связаны с безопасностью, высокой доступностью, балансировкой нагрузки и централизованная аутентификация/авторизация. В них критично реализации, которые макет, дизайн и архитектура серверной части инфраструктура (те серверы, которые фактически обрабатывают запросы) изолированы и защищены снаружи; что касается клиента, обратный прокси-сервер — это единственный источник всего контента.

Типичная реализация ниже:

Обратный прокси
Простое обратное проксирование
Кластеры и балансировщики
Конфигурация Balancer и BalancerMember
Аварийное переключение
Диспетчер балансировки
Динамические проверки работоспособности
Флаги состояния BalancerMember

См.

также

Комментарии

ProxyPass директива определяет отображение входящих запросов на серверную часть сервер (или кластер серверов, известный как Balancer группа). Самый простой пример проксирует все запросы ("/") к одному бэкенду:

 ProxyPass "/" "http://www.example.com/"

Чтобы гарантировать, что и Location: заголовки, сгенерированные из серверная часть изменена, чтобы указывать на обратный прокси-сервер вместо вернуться к себе, Проксипасреверс чаще всего требуется директива:

 ProxyPass "/" "http://www.example.com/"
ProxyPassReverse "/" "http://www.example.com/"

Проксировать можно только определенные URI, как показано в этом примере:

 ProxyPass "/images" "http://www.example.com/"
ProxyPassReverse "/images" "http://www.example.com/"

В приведенном выше примере любые запросы, начинающиеся с /images путь с прокси к указанному бэкенду, иначе он будет обработан локально.

Каким бы полезным ни было вышеизложенное, оно все же имеет недостатки, которые следует (один) внутренний узел выходит из строя или становится сильно загруженным, что проксирование эти запросы не дают реального преимущества. Что нужно, так это способность определить набор или группу внутренних серверов, которые могут обрабатывать такие запросы и для обратного прокси-сервера для балансировки нагрузки и аварийного переключения между их. Эту группу иногда называют кластером , но Apache httpd’s термин балансир . Один определяет балансировщик, используя <Прокси> и Директивы BalancerMember как показано:

 <Балансировщик прокси://myset>
    BalancerMember http://www2.example.com:8080
    BalancerMember http://www3.example.com:8080
    ProxySet lbmethod=bytraffic

ProxyPass "/images/" "балансировщик://myset/"
ProxyPassReverse "/images/" "balancer://myset/"

Схема balancer:// сообщает httpd, что мы создаем комплект балансиров, с именем мой набор . Он включает в себя 2 внутренних сервера, который httpd вызывает BalancerMembers . В этом случае любые запросы на /images будет проксироваться на один из двух бэкендов. Директива ProxySet указывает, что балансировщик myset использует алгоритм балансировки нагрузки который балансирует на основе байтов ввода-вывода.

Подсказка

BalancerMembers также иногда упоминается как рабочие .

Вы можете настроить многочисленные детали конфигурации балансиров и рабочих через различные параметры, определенные в ProxyPass . Например, если мы хотим, чтобы http://www3.example.com:8080 обрабатывать в 3 раза больше трафика с тайм-аутом в 1 секунду, мы бы скорректировали конфигурации следующим образом:

 <Балансировщик прокси://myset>
    BalancerMember http://www2. example.com:8080
    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
    ProxySet lbmethod=bytraffic

ProxyPass "/images" "балансировщик://myset/"
ProxyPassReverse "/images" "balancer://myset/"

Вы также можете точно настроить различные сценарии отработки отказа, указав, какие рабочие процессы и даже к каким балансировщикам следует обращаться в таких случаях. Например, ниже установка реализует три случая отработки отказа:

http://spare1.example.com:8080 и http://spare2.example.com:8080 отправляются трафик только если один или оба из http://www2.example.com:8080 или http://www3.example.com:8080 недоступен. (один запасной будет использоваться для замены одного неиспользуемого элемента того же набора балансировщиков.)
http://hstandby.example.com:8080 отправляется трафик, только если все остальные воркеры в наборе балансировщика 0 недоступны.
Если для всех балансировщиков нагрузки установлено значение 0 рабочих, запасных частей и недоступны, только тогда http://bkup1.example.com:8080 и http://bkup2.example.com:8080 рабочих из набора балансировщика 1 ввести в оборот.

Таким образом, можно иметь один или несколько «горячих» резервов и «горячих резервов» для каждый набор балансировщика нагрузки.

 <Балансировщик прокси://myset>
    BalancerMember http://www2.example.com:8080
    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
    BalancerMember http://spare1.example.com:8080 status=+R
    BalancerMember http://spare2.example.com:8080 status=+R
    BalancerMember http://hstandby.example.com:8080 status=+H
    BalancerMember http://bkup1.example.com:8080 lbset=1
    BalancerMember http://bkup2.example.com:8080 lbset=1
    ProxySet lbmethod=byrequests

ProxyPass "/images/" "балансировщик://myset/"
ProxyPassReverse "/images/" "balancer://myset/"

Для аварийного переключения горячие резервы используются в качестве замены непригодным рабочим процессам в тот же набор балансировщика нагрузки. Рабочий считается непригодным, если он слив, остановлен или иным образом находится в состоянии ошибки/сбоя. Горячие резервы используется, если все рабочие и запасные части в наборе балансировщика нагрузки недоступен. Наборы балансировщиков нагрузки (с соответствующими горячими резервами и резервные) всегда проверяются в порядке от самого низкого до самого высокого.

Одной из самых уникальных и полезных функций обратного прокси-сервера Apache httpd является встроенный приложение балансировщик-менеджер . Похожий на mod_status , балансировщик-менеджер отображает текущая рабочая конфигурация и статус включенного балансиры и рабочие в настоящее время используются. Однако не только это отображать эти параметры, он также позволяет динамически, во время выполнения, на лету реконфигурация почти всех из них, включая добавление новых BalancerMembers (воркеры) к существующему балансировщику. Чтобы включить эти возможности, выполните следующие действия. необходимо добавить в вашу конфигурацию:

 <Местоположение "/balancer-manager">
    Балансировщик-менеджер SetHandler
    Требовать локального хоста

Предупреждение

Не включайте диспетчер балансировки , пока не защитите свой сервер. В в частности, убедитесь, что доступ к URL жестко ограниченный.

При доступе к обратному прокси-серверу по этому URL-адресу (например: http://rproxy.example.com/balancer-manager/ , вы увидите страница, аналогичная приведенной ниже:

Эта форма позволяет администратору DevOps настраивать различные параметры, принимать рабочих в автономном режиме, изменить методы балансировки нагрузки и добавить новые работы. За Например, нажав на сам балансировщик, вы попадете на следующую страницу:

При нажатии на рабочего отображается эта страница:

Чтобы эти изменения сохранялись при перезапуске обратного прокси-сервера, убедитесь, что BalancerPersist включен.

Прежде чем httpd проксирует запрос рабочему процессу, он может «проверить» , если этот рабочий процесс доступен через установку параметра ping для этого воркера с помощью ProxyPass . Часто это полезнее проверять работоспособность рабочих вне полосы , в динамичная мода. Это достигается в Apache httpd с помощью Модуль mod_proxy_hcheck .

В балансировщике-менеджере текущее состояние, или статус , рабочего отображается и может быть установлено/сброшено. Значения этих статусов следующие:

Flag	String	Description
	Ok	Worker is available
	Init	Worker has been initialized
`D`	Dis	Worker отключен и не принимает запросы; будет автоматически повторяется.
`S`	Стоп	Работник административно остановлен; не принимает запросы и не будет автоматически повторяться.
`R`	Spar	Работник является горячей заменой. Для каждого рабочего в заданном lbset, который непригоден для использования (слив, остановка, ошибка и т. д.), в его место. Горячие резервы могут помочь обеспечить постоянную доступность определенного количества рабочих. для использования балансировщиком.
`H`	Stby	Worker находится в режиме горячего резерва и будет использоваться только при отсутствии других жизнеспособные рабочие или запасные части доступны в наборе противовеса.
`E`	Err	Worker находится в состоянии ошибки, обычно из-за сбоя проверки перед запросом; запросы не будут передаваться этому рабочему процессу, но будут повторяться в зависимости от `повторная попытка` настройка воркера.
`N`	Drn	Worker находится в режиме слива и будет принимать только существующие закрепленные сеансы предназначена для себя и игнорировать все другие запросы.
`C`	HcFl	Работник не прошел динамическую проверку работоспособности и не будет использоваться, пока она не будет проходит последующие проверки работоспособности.

Примечание:
Это не раздел вопросов и ответов. Комментарии, размещенные здесь, должны указывать на предложения по улучшению документации или сервера и могут быть удалены нашими модераторами, если они либо реализованы, либо считаются недействительными/не по теме. Вопросы о том, как управлять HTTP-сервером Apache, следует направлять либо на наш IRC-канал #httpd, на Libera.chat, либо в наши списки рассылки.

404: Страница не найдена

Страница, которую вы пытались открыть по этому адресу, похоже, не существует. Обычно это результат плохой или устаревшей ссылки. Мы приносим свои извинения за доставленные неудобства.

Что я могу сделать сейчас?

Если вы впервые посещаете TechTarget, добро пожаловать! Извините за обстоятельства, при которых мы встречаемся. Вот куда вы можете пойти отсюда:

Поиск

Узнайте последние новости.
Наша домашняя страница содержит самую свежую информацию о Java-разработке.
Наша страница «О нас» содержит дополнительную информацию о сайте, на котором вы находитесь, TheServerSide.com.
Если вам нужно, свяжитесь с нами, мы будем рады услышать от вас.

Просмотр по категории

SearchAppArchitecture

Признаки антипаттерна «Золотой молот» и 5 способов его избежать
Антипаттерн «Золотой молот» может подкрасться к команде разработчиков, но есть способы его обнаружить. Изучайте знаки, а также некоторые…
Почему контрактное тестирование может быть необходимо для микросервисов
Разработчики сталкиваются с многочисленными трудностями, пытаясь выполнить традиционное сквозное интеграционное тестирование микросервисов. Контракт…
Растущая роль разработчиков, ориентированных на данные
Больше, чем когда-либо, растущая зависимость разработчиков от данных, источников данных и пользователей подталкивает разработчиков к пониманию ИТ-покупок …

ПоискПОКачество

Инструменты Atlassian Open DevOps объединяют больше рабочих процессов
Atlassian утверждает, что по мере роста числа поставщиков комплексных инструментов DevOps пользователям нужен выбор; клиенты говорят, что интеграция сторонних инструментов — это …
Инструмент управления API с низким кодом борется со сложностью с оговорками
Новый инструмент управления API с низким кодом может принести такие преимущества, как повышенная скорость, меньшее количество ошибок кодирования и более широкий доступ. Но…
Обновления безопасности GitHub и расширение Copilot наделали много шума
Новые функции, представленные на GitHub Universe, включают частные каналы для решения проблем безопасности и Copilot для бизнеса, которые могут упасть . ..

SearchCloudComputing

Эксперты по облачным технологиям и их прогнозы AWS re:Invent 2022
Поскольку AWS готовится к своему крупнейшему событию года, наши участники прогнозируют, что поставщик облачных услуг представит на re:Invent 2022.
Сравните Amazon Lightsail и EC2 для нужд вашего веб-приложения
Не всем разработчикам нужны или нужны все возможности Amazon EC2. Узнайте, подходит ли сокращенный и упрощенный Amazon Lightsail…
VMware добавляет инструменты управления несколькими облаками
VMware представила HCX+, управляемый сервис для многооблачных центров обработки данных, а также возможности Kubernetes для частных облаков и …

ПоискБезопасность

Проверка реальностью: компенсационные пакеты CISO охватывают всю гамму
Опытный руководитель службы безопасности бесценен — этот факт все чаще признают организации. Зарплаты директоров по информационной безопасности в целом находятся в тренде…
Риск и повторение: исследователи критикуют HackerOne
В этом эпизоде подкаста обсуждается недавняя статья TechTarget Security о платформе вознаграждения за обнаружение ошибок HackerOne, в которой исследователи …
Rapid7 раскрывает больше уязвимостей F5 BIG-IP
Несмотря на то, что серьезность проблем относительно невелика, устройства F5 обычно становятся мишенью для злоумышленников, чтобы обеспечить устойчивость внутри …

ПоискAWS

AWS Control Tower стремится упростить управление несколькими учетными записями
Многие организации изо всех сил пытаются управлять своей огромной коллекцией учетных записей AWS, но Control Tower может помочь. Услуга автоматизирует…
Разбираем модель ценообразования Amazon EKS
В модели ценообразования Amazon EKS есть несколько важных переменных.