Моя компания использует систему 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>
. До сих пор мне не удавалось заставить это работать, стоит упомянуть, что
Можно ли это сделать с помощью Apache?
Ответ HBruijn объяснил мне некоторые сложные моменты, но я все еще не смог их решить. Но мне удалось обойти проблему с SSL, просто добавив
SSLProxyEngine on
SSLProxyVerify none
Что не работает, также исх. ответ, отправленный HBruijn, и строка
RedirectMatch ^/$ /mycorp
не работают. / Возвращает http 404, и это то, что я получаю, но если бы был добавлен / mycorp, я ожидал бы http 401.
Но я создам новый вопрос для этой проблемы.
Моя компания использует систему 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 может по-прежнему обнаруживать использование неизвестного доменного имени и впоследствии отказывать в доступе.