Поиск по сайту:

Как настроить обратный прокси с Apache


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

Хотя Apache может быть не лучшим выбором в качестве обратного прокси-сервера, поскольку более современные альтернативы, такие как NGINX, имеют тенденцию привлекать внимание, mod_proxy полезен для серверов, на которых уже работает Apache и теперь необходимо направить трафик на другой сервис. . Вы можете настроить виртуальный хост Apache для передачи запросов для данного домена на отдельный веб-сервер.

Для целей этого руководства мы используем Apache 2.4 с системой на основе Debian. Мы также предполагаем, что серверы, на которые вы хотите проксировать трафик, уже доступны по сети с вашего хоста Apache. В этой статье основное внимание уделяется включению прокси на основе уникального виртуального хоста, но mod_proxy также можно настроить глобально, как часть конфигурации вашего сервера Apache или на уровне каталога через .htaccess. файлы.

Включение прокси-модуля

mod_proxy включен в установку Apache по умолчанию. Используйте a2enmod, чтобы активировать модуль и его независимый HTTP-компонент:

sudo a2enmod proxy
sudo a2enmod proxy_http

Это настраивает Apache для поддержки проксирования HTTP-соединений с другими хостами. Модуль настраивается с помощью инструкций с префиксом Proxy в ваших конфигурационных файлах Apache. Мы настроим их дальше.

Настройка проксируемого виртуального хоста

Давайте настроим виртуальный хост, который перенаправляет example.com на внутренний IP-адрес 192.168.0.1. Вы должны добавить запись DNS для example.com, которая указывает на ваш хост Apache.

Прокси в этом сценарии позволяет посетителям прозрачно получать доступ к вашему внутреннему веб-серверу через внешний адрес. Apache действует как привратник, который направляет трафик к конечному пункту назначения. Пользователь увидит example.com, хотя фактически Apache разрешает запросы через отдельный сервер.

Добавьте новый файл виртуального хоста в /etc/apache2/sites-available со следующим содержимым:

<VirtualHost *:80>
    ServerName example.com

    ProxyPass / http://192.168.0.1/ nocanon
    ProxyPassReverse / http://192.168.0.1/
</VirtualHost>

Директивы ProxyPass и ProxyPassReverse указывают, что трафик на example.com должен быть проксирован на 192.168.0.1. Необязательное ключевое слово nocanon указывает Apache передать необработанный URL-адрес на удаленный сервер. Без этого ключевого слова Apache автоматически канонизирует URL-адрес, что может быть несовместимо с некоторыми серверами и платформами. Использование nocanon гарантирует совместимость, но может повлиять на вашу безопасность, поскольку отключает встроенную защиту Apache от прокси-атак на основе URL-адресов.

Необходимо указать ProxyPassReverse, чтобы отличить вашу конфигурацию от настройки обратного прокси-сервера. Apache будет использовать предоставленный URL-адрес для перезаписи заголовков ответов Location, Content-Location и URI, выдаваемых вашим сервером. Это гарантирует, что последующие запросы будут поступать на обратный прокси-сервер вместо того, чтобы напрямую обращаться к внутреннему серверу.

Эта конфигурация будет проксировать все запросы. Вы можете ограничить проксирование определенным путем, например /media, изменив инструкции ProxyPass и ProxyPassReverse:

ProxyPass /media http://192.168.0.1/
ProxyPassReverse /media http://192.168.0.1/

Добавление нескольких правил ProxyPass позволяет направлять запросы между несколькими целями, используя один виртуальный хост. Правила сопоставляются в порядке их написания. Если вам нужно более сложное поведение маршрутизации, используйте директиву ProxyPassMatch. Это эквивалентно ProxyPass, но сопоставляет входящие URL-адреса с регулярным выражением:

ProxyPassMatch ^/client/(.*)/images$ http://192.168.0.1/

Сохраните файл виртуального хоста и включите его с помощью команды a2ensite. Это берет базовое имя вашего файла относительно каталога sites-available:

sudo a2ensite example-proxy-vhost

Перезапустите Apache, чтобы применить изменения:

sudo service apache2 restart

Теперь ваш простой прокси должен работать. Попробуйте посетить example.com — вы должны увидеть контент, обслуживаемый 192.168.0.1. Запрос завершается на вашем хосте Apache, который затем проксирует его на ваш внутренний сервер.

Использование SSL

В приведенном выше примере SSL не используется. В производственной рабочей нагрузке вы захотите настроить это, добавив параметры SSLCertificateFile и SSLCertificateKeyFile на свой виртуальный хост. Они определяют сертификат SSL и ключ, используемые при проверке SSL-соединений. Вы также можете использовать certbot Let’s Encrypt для автоматизации настройки.

Такая настройка SSL означает, что безопасное соединение будет разорвано на вашем хосте Apache. Соединение между Apache и вашим прокси-сервером будет осуществляться через обычный HTTP.

Если вам также необходимо защитить прокси-соединение, вы должны использовать параметры SSLProxy, предоставляемые mod_ssl. SSLProxyEngine=On будет работать как самая базовая конфигурация, при условии, что и Apache, и ваш целевой прокси-сервер имеют доступ к одним и тем же сертификатам. Этот параметр указывает, что информация SSL должна передаваться через прокси-соединение.

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

Обратные прокси-серверы Apache имеют несколько необязательных директив, которые можно использовать для настройки поведения пересылки. Вот некоторые часто используемые варианты:

  • ProxyAddHeaders — Apache передает X-Forwarded-Host, XForwarded-For и X -Forwarded-Server на ваш внутренний сервер по умолчанию. Они позволяют вашему бэкенду определить, что запрос был проксирован через Apache. Установка для этого заголовка значения Off запрещает Apache добавлять эти заголовки.
  • ProxyErrorOverride — Apache не будет вмешиваться в ответы, отправляемые вашим внутренним сервером, если это не указано. Если ваш сервер выдает код ошибки 400, 404, 500 или любой другой, пользователь получит этот контент как есть. Параметр ProxyErrorOverride изменяет это, позволяя Apache вместо этого заменять содержимое страниц ошибок сконфигурированным ErrorDocument. Это может быть полезно в ситуациях, когда вы хотите, чтобы ошибки от всех ваших серверных частей обрабатывались единообразно, а конфигурация была централизована на прокси-сервере.
  • ProxyPassReverseCookieDomain. Эта функция аналогична обязательной (для обратного проксирования) директиве ProxyPassReverse. Он перепишет домен в заголовках Set-Cookie, чтобы он ссылался на имя виртуального хоста, а не на имя хоста внутреннего сервера, с которого они происходят.
  • ProxyPreserveHost — Apache обычно отправляет собственное имя хоста на ваши внутренние серверы в качестве значения заголовка Host. Установка этой директивы означает, что вместо этого будет отправлен заголовок original Host. Это может быть необходимо, когда ваше серверное программное обеспечение выполняет собственную маршрутизацию на основе имени хоста.
  • ProxyTimeout — используйте эту директиву, чтобы настроить время ожидания Apache, пока ваш внутренний сервер обрабатывает проксируемый запрос. Apache прервет запрос и вернет клиенту код ошибки, если время ожидания превышено. По умолчанию используется значение Timeout на уровне сервера.

Вы можете установить эти директивы как дополнительные строки в вашем файле виртуального хоста. Не забывайте перезапускать службу Apache каждый раз, когда вы применяете изменение.

Балансировка нагрузки

Реализация обратного прокси-сервера Apache также поддерживает балансировку нагрузки между несколькими различными серверными частями. Это позволяет запросу example.com попасть на любой из серверов в балансировочном пуле.

<Proxy balancer://example-balancer>
    BalancerMember http://192.168.0.1
    BalancerMember http://192.168.0.2
    ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass / balancer://example-balancer
ProxyPassReverse / balancer://example-balancer

В этом примере запросы направляются на один из двух серверов в пуле example-balancer. Алгоритм балансировки нагрузки определяется настройкой lbmethod; используемое здесь значение bytraffic пытается гарантировать, что каждый из серверов обрабатывает равный объем трафика.

Альтернативный  метод балансировки byrequests – это более простая версия bytraffic, которая дает каждому бэкенду равную долю входящих запросов.  балансировщик по занятости отслеживает, сколько запросов обслуживает каждый сервер, а затем назначает новые запросы наименее загруженному серверу.

Краткое содержание

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

Доступны и другие варианты прокси. Вы можете проксировать соединения FTP, WebSocket и HTTP2, среди прочего, установив дополнительные надстройки вместе с mod_proxy. Полный список модулей доступен в документации Apache.