Как я могу использовать Apache в качестве обратного прокси для https?

Моя компания использует систему CMS, размещенную в облаке. Мы хотим создать внутренние DNS-псевдонимы, чтобы разработчикам было легче их запоминать. Читая документацию для mod_proxy_connect, я думаю, что должно быть возможно сделать что-то вроде

<VirtualHost *:443>
 ServerAdmin mellomvaredrift@mycorp.no
 ServerName test-cms.mycorp.no

 AllowCONNECT
 ProxyPass /  https://mycorp-xpqa-lb-8qh7ip0n.cms.cloud/mycorp
 ProxyPassReverse /  https://mycorp-xpqa-lb-8qh7ip0n.cms.cloud/mycorp
</VirtualHost>

. До сих пор мне не удавалось заставить это работать, стоит упомянуть, что

  • У меня нет доступа к сертификату / ключу CMS-система, отличная от публичной верт.

Можно ли это сделать с помощью Apache?

0
задан 24 April 2019 в 22:24
2 ответа

Ответ HBruijn объяснил мне некоторые сложные моменты, но я все еще не смог их решить. Но мне удалось обойти проблему с SSL, просто добавив

SSLProxyEngine on
SSLProxyVerify none

Что не работает, также исх. ответ, отправленный HBruijn, и строка

 RedirectMatch ^/$ /mycorp

не работают. / Возвращает http 404, и это то, что я получаю, но если бы был добавлен / mycorp, я ожидал бы http 401.

Но я создам новый вопрос для этой проблемы.

0
ответ дан 4 December 2019 в 13:20

Моя компания использует систему CMS, размещенную в облаке. Мы хотим создать внутренние DNS-псевдонимы, чтобы разработчикам было легче их запоминать.

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

Я также думаю, что вы, вероятно, думаете слишком технически и DIY; Я бы начал с обращения к поставщику CMS и заявил, что вы хотите использовать свой собственный домен для доступа к CMS. Вероятно, они смогут (пере) настроить свою службу так, чтобы она работала с вашим предпочтительным доменом и связанным сертификатом TLS.

Тогда единственная конфигурация, которую вам нужно сохранить на своей стороне, - это запись DNS CNAME для точек test-cms.example.com. в mycorp-xpqa-lb-8qh7ip0n.cms.cloud.


Теперь вернемся к конфигурации Apache.

mod_proxy_connect требуется только для прямого HTTPS-прокси, вы настраиваете обратный прокси-сервер и не нуждаетесь в AllowCONNECT .

Обратному прокси-серверу также нужен собственный сертификат TLS, который отсутствует в вашем коде.

Часто отображение различных URL-путей в обратном прокси-сервере, / на / mycorp , приводит к несовместимости, как и несбалансированные завершающие косые черты.

Вместо этого рассмотрите следующее:

  RedirectMatch ^/$ /mycorp
  ProxyPass /  https://mycorp-xpqa-lb-8qh7ip0n.cms.cloud/
  ProxyPassReverse /  https://mycorp-xpqa-lb-8qh7ip0n.cms.cloud/

Это перенаправляет запросы к корневому каталогу, голому субдомену в правильный подкаталог, а также обеспечивает, например, контент из общих, а не специфичных для компании каталогов, таких как https: // mycorp -xpqa-lb-8qh7ip0n.cms.cloud/common останется доступным.

<VirtualHost *:443>
  ServerName test-cms.example.com

  SSLEngine on
  SSLCertificateFile /etc/apache2/ssl/test-cms.example.com.crt
  SSLCertificateKeyFile /etc/apache2/ssl/test-cms.example.com.key

  RedirectMatch ^/$ /mycorp
  SSLProxyEngine on
  ProxyPass /  https://mycorp-xpqa-lb-8qh7ip0n.cms.cloud/
  ProxyPassReverse /  https://mycorp-xpqa-lb-8qh7ip0n.cms.cloud/

</VirtualHost>

Любая достаточно продвинутая конфигурация безопасности на стороне CMS может по-прежнему обнаруживать использование неизвестного доменного имени и впоследствии отказывать в доступе.

2
ответ дан 4 December 2019 в 13:20

Теги

Похожие вопросы