Назад | Перейти на главную страницу

Как я могу использовать 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?

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

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

Я также думаю, что вы, вероятно, думаете слишком технически и сделай сам; Я бы начал с обращения к поставщику 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 может по-прежнему обнаруживать использование неизвестного доменного имени и впоследствии запрещать доступ.

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

SSLProxyEngine on
SSLProxyVerify none

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

 RedirectMatch ^/$ /mycorp

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

Но я создам новый вопрос для этого выпуска.