Proxypass apache не работает

Настройка 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). Подробнее под катом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

Источник

Как использовать Apache в качестве обратного прокси при помощи mod_proxy на Ubuntu 16.04

Введение

Обратный прокси-сервер – это тип прокси-сервера, который ретранслирует HTTP/HTPPS-запросы на один или несколько бэкенд-серверов. Обратные прокси-серверы полезны, так как многие современные веб-приложения для обработки HTTP-запросов используют бэкенд-серверы приложений (к которым пользователи не должны иметь доступ напрямую), а также часто поддерживают только базовые функции HTTP.

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

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

Требования

Для того, чтобы выполнить необходимые действия, вам понадобится:

• сервер с установленной ОС Ubuntu 16.04 и пользователем, который может выполнять команды sudo;
• установленный на вашем сервере Apache.

Шаг 1: включение необходимых модулей Apache

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

Нужный нам модуль – это mod_proxy, а также несколько дополнений, которые расширяют его функционал и позволяют поддерживать различные сетевые протоколы. Если перечислять более конкретно, то понадобятся:

• mod_proxy – главный модуль Apache для перенаправления соединений; благодаря ему Apache может выступать в качестве шлюза для основных серверов приложений;
• mod_proxy_http – позволит использовать прокси для HTTP;
• mod_proxy_balancer и mod_lbmethod_byrequests – добавляют функции балансировки нагрузки для бэкенд-серверов.

Для того, чтобы активировать модули, выполните команды ниже в соответствующем порядке:

Затем перезапустите Apache для того, чтобы изменения вступили в силу.

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

Шаг 2: создание тестовых бэкенд-серверов

Запуск нескольких базовых бэкенд-серверов – отличная возможность протестировать, корректно ли работает Apache. Поэтому необходимо создать два сервера, которые будут отвечать на HTTP-запросы, печатая строку текста. Один будет отвечать “Hello world!”, другой “ Hello Timeweb!”.

Примечание. Если говорить не о тестовом запуске, то обычно бэкенд-серверы отдают одинаковый тип контента. Однако для тестирования будет удобнее, если это будет два сервера с разными сообщениями, потому что так будет проще отследить, что балансировка нагрузки работает корректно.

Flask – это микрофреймворк Python, который используется для создания веб-приложений. В этом руководстве мы будем использовать Flask, так как для написания базового приложения требуется всего несколько строк. Вам необязательно знать Python для того, чтобы выполнить дальнейшие действия.

Для начала обновите список доступных пакетов:

Теперь установите Pip, рекомендованная система управления пакетами Python.

И уже при помощи Pip установите Flask:

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

Файл можно создать в домашней директории пользователя, под которым вы авторизованы.

Скопируйте в файл текст, который приведен ниже, а затем сохраните и закройте файл.

Первые две строчки инициализируют фреймворк Flask. Единственная функция home() будет отдавать строку текста (“Hello world!”). А за то, чтобы этот текст появлялся в ответ на HTTP-запросы, отвечает @app.route(‘/’).

Второй бэкенд-сервер будет точно таким же, как и первый, кроме единственного отличия в тексте.

Поэтому для начала необходимо скопировать первый файл:

Теперь откройте новый скопированный файл:

И в последней строчке вместо “Hello world!” напишите, к примеру, “Hello Timeweb!”:

Команда ниже запустит первый бэкенд-сервер, его порт 8080.

Второй сервер тоже необходимо запустить, его порт 8081:

Теперь протестируем работу обоих серверов.

В ответ вы должны получить “Hello world!”.

В этом случае вы увидите в терминале надпись “Hello Timeweb!”.

Примечание. Для того, чтобы закрыть оба тестовых сервера (например, после выполнения всех действий в этом руководстве), вы можете просто выполнить следующую команду: killall flask.

Далее мы изменим конфигурационный файл Apache для того, чтобы появилась возможность использовать его в качестве обратного прокси-сервера.

Шаг 3: изменение изначальных установок для включения прокси

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

Сначала нужно открыть конфигурационный файл Apache в редакторе nano (или в другом редакторе на ваш выбор):

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

1 пример: обратное прокси для одного бэкенд-сервера

Скопируйте текст ниже вместо всего текста, расположенного в блоке VirtualHost, то есть чтобы в итоге блок выглядел вот так:

Если вы продолжаете следовать этому руководству и используете тестовые серверы, которые создали ранее, то скопируйте 127.0.0.1:8080, как и написано в примере. Если у вас есть свои собственные серверы приложений, то используйте их адреса.

В блоке используется три директивы:

• ProxyPreserveHost – заставляет Apache передать оригинальный заголовок Host бэкенд-серверу. Это полезно, так как в этом случае бэкенд-сервер получает адрес, который используется для доступа к приложению;
• ProxyPass – основная директива для настройки прокси. В данном случае она указывает, что все, что идет после корневого адреса URL (/), должно быть отправлено на бэкенд-сервер по указанному адресу. Например, если Apache получит запрос /primer, то он подключится к http://ваш_бэкенд-сервер/primer и отправит соответствующий ответ;
• ProxyPassReverse – должна иметь такие же настройки, как и ProxyPass. Она сообщает Apache, как изменить заголовки в ответе от бэкенд-сервера. Таким образом гарантируется, что браузер клиента будет перенаправлен на прокси-адрес, а не на адрес бэкенд-сервера.

После внесения изменений Apache необходимо перезапустить:

Теперь, если вы наберете в браузере адрес своего сервера, вы увидите ответ от вашего бэкенд-сервера вместо приветственной страницы Apache.

2 пример: балансировка нагрузки между несколькими бэкенд-серверами

Если у вас есть несколько бэкенд-серверов, будет хорошей идеей при использовании прокси распределить трафик между ними; сделать это можно при помощи функции балансировки нагрузки утилиты mod_proxy.

Как и в первом примере, тут вам тоже необходимо заменить текст в блоке VirtualHost на следующий:

В целом текст похож на предыдущий, однако вместо указания одного бэкенд-сервера появляется новый блок Proxy, в котором указано несколько серверов. Блок называется balancer://mycluster (название можно изменить) и состоит из одного или нескольких BalancerMembers, которые определяют адреса лежащих в основе бэкенд-серверов.

Директивы ProxyPass и ProxyPassReverse используют пул балансировки нагрузки под названием mycluster вместо конкретного сервера.

Вы можете использовать адреса тестовых серверов (как указано выше), либо заменить их на адреса своих серверов.

Для того, чтобы изменения вступили в силу, перезапустите Apache:

Теперь проведите такой же тест, как и в первом примере: введите IP-адрес вашего сервера в браузер и вместо стандартного приветствия Apache вы увидите один из ответов бэкенд-серверов. Если вы используете тестовые серверы, то это будет либо “Hello world!”, либо “Hello Timeweb!”. Обновите страницу несколько раз и, если вы увидели оба текста, значит все работает корректно.

Заключение

Теперь вы знаете, как настроить Apache в качестве обратного прокси-сервера для одного или нескольких внутренних серверов. mod_proxy можно эффективно использоваться для того, чтобы настраивать обратный прокси для серверов с приложениями, написанных на различных языках программирования и технологиях, таких как Python, Django или Ruby и Ruby on Rails. Также mod_proxy можно использовать для балансировки нагрузки между несколькими бэкенд-серверами для сайтов с большой нагрузкой, чтобы обеспечить высокую доступность таких ресурсов.

mod_proxy и mod_proxy_http самая популярная комбинация модулей, однако есть несколько других, которые поддерживают другие сетевые протоколы. Хотя в этом руководстве они не использовались, их тоже можно выделить отдельным списком:

• mod_proxy_ftp для FTP;
• mod_proxy_connect для SSL-туннеля;
• mod_proxy_ajp для протокола AJP (Apache JServ Protocol);
• mod_proxy_wstunnel для веб-сокетов.

Источник

Apache в качестве proxy http

Потребовалось в одном проекте прокинуть HTTP-трафик на внутренний сайт фирмы. Наружу смотрел Apache, а какой был внутри не суть важно, какое-то приложение с web-интерфейсом. Конечно у данной задачи есть масса решений. Люди работающие в данной сфере чаще всего предлагают решение с Nginx на периметре и он в свою очередь отдаёт трафик от нескольких web-серверов наружу. Так же на роутере можно прокинуть трафик с изменённым портом. Например, вместо 80 порта использовать 81 или 8080.

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

Я сначала думал, что достаточно будет только одного прокси-модуля, но как показала практика необходимо запускать целую династию этих проксей. Без этого при редиректах или подключениях с разных версий браузеров возникали ошибки номер 404 или 500. А в логах сыпалось, что необходимо воспользоваться LoadModule.

Идём дальше. Теперь необходимо создать виртуальный хост который будет перенаправлять запрос на другой физический сервер. В моём случае, на другой сервер расположеный в локальной сети. Мой хост выглядел вот так.

Поля ServerAdmin и DocumentRoot обязательны для заполнения и их игнорировать нельзя. По этому туда надо хоть что-то записать. Не забывайте, что в DNS должен существовать хост ServerName и он должен указывать на сервер на котором запущен Apache.

И так параметры, которые я использовал:

• ServerAdmin — электронная почта администратора. Можно писать, что угодно.
• DocumentRoot — каталог, так как это обязательный параметр его нельзя игнорировать. Можно указать любой.
• ServerName — имя хоста, который мы перенаправляем на внутренний сервер.
• ErrorLog и CustomLog — адрес файлов для логов и степень детализации.
• ProxyRequests — передача параметров на проксируемый сервер. Рекомендуется всегда отключать этот параметр. Его включение делает возможность получения несанкционированного доступа внутрь вашей сети.
• ProxyPreserveHost — сохранять имя хоста при передаче запроса. Необходимо если принимающий сервер оценивает эти заголовки.
• ProxyVia — отвечает за передачу HTTP-заголовка Via в цепочке HTTP-прокси по цепочке.
• ProxyPass и ProxyPassReverse — первый параметр говорит откуда идет отсчет. Можно проксировать только один каталог на другой сервер. Второй параметр указывает протокол, адрес и порт на который перенаправляется трафик.

Если вы хотите организовать обратный прокси-сервер к сайтам внутри вашей сети с нуля, то я бы рекомендовал использовать для этих целей сервер Nginx. Используя его вы сможете организовать кэширование, балансировку и много иных приятных плюшек касающихся ваших web-серверов.

Успехов в администрировании.

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

Источник