Использование Apache 2.2 mod_rewrite для консолидации поддоменов - PullRequest
Новая
       54

Использование Apache 2.2 mod_rewrite для консолидации поддоменов

1 голос
/ 27 апреля 2011

У меня проблемы с использованием mod_rewrite и мне нужна помощь.

У меня есть обратный прокси-сервер в демилитаризованной зоне, который принимает запросы от внешних клиентов, запрашивающие субдомены sub1.example.com и sub2.example.comи перенаправляет их (прозрачно) на один компьютер во внутренней корпоративной сети internal.example.com.В частности:

  1. http://sub1.example.com → http://internal.example.com
  2. https://sub1.example.com → https://internal.example.com
  3. http://sub2.example.com → http://internal.example.com
  4. https://sub2.example.com → https://internal.example.com

Хотя у меня нет контроля над прокси-сервером в демилитаризованной зоне, выполняющим перенаправления, у меня есть полный контроль над internal.example.com, на котором установлен Apache 2.2 и который прослушивает 80 и 443 с загруженным mod_rewrite.

Мне нужно настроить этот экземпляр Apache для выполнения перенаправления любого из четырех указанных выше адресов поддоменов (sub1 или sub2 на HTTP или HTTPS) на четвертый адрес https://sub2.example.com (4).Чтобы достичь этого, в настоящее время я использую следующее в httpd.conf: 

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://sub2.example.com/$1 [R=301,L]

. Это работает при перенаправлении клиентов, которые запрашивают адреса (1) и (3) (т. Е. HTTP-адрес любого субдомена), направильная цель (4), но не влияет на переписывание доступа к адресу (2).Чтобы перенаправить (2) в (4), я добавил следующее в элемент VirtualHost, конфигурирующий среду SSL: 

RewriteEngine On
RewriteCond %{SERVER_NAME} =sub1.example.com
RewriteRule ^/?(.*) https://sub2.example.com/$1 [R=301,L]

Теперь это срабатывает, если клиент запросил sub1.example.com через HTTPS (подтверждено через ведение журнала mod_rewrite).Однако, несмотря на то, что перенаправления теперь работают корректно при тестировании с машин позади DMZ (внутренней и в той же сети, что и internal.example.com), они не работают в любой внешней сети,где:

  • HTTP-адрес любого субдомена (1 и 3) не загружается полностью
  • HTTPS-адрес любого субдомена (2 и 4) приводит к ошибке в клиентских браузерах, котораясообщить, что было выполнено слишком много перенаправлений.

Кто-нибудь может подсказать, где я ошибся, или, возможно, более подходящую конфигурацию для моих обстоятельств?Заранее спасибо!

Ответы [ 2 ]

0 голосов
/ 17 февраля 2014

Хотя я не использовал свое решение для проблем, точно таких же, как ваша, я подозреваю, что есть более простой и чистый способ, чем использование перезаписей.(ПРИМЕЧАНИЕ. Ниже предполагается, что внутренний DNS распознает ваш один сервер как IP-адрес для разрешения всех поддоменов. Если это не так, то это изменение, вероятно, должно быть сделано ... Я не знаю, что произойдет, если онне сделал, но я также никогда не настраивал обратный прокси ...)

Попробуйте следующее: -В httpd.conf @ конец убедитесь, что появляется следующая строка: 

NameVirtualHost *:80

-Наконец добавьте VirtualHost для каждого * поддомена, например: 

<VirtualHost *:80>
ServerName sub1.example.com
ServerAlias sub1
DocumentRoot "X:/path/to/website/for/internal.example.com"
</VirtualHost>

* ВАЖНОЕ ПРИМЕЧАНИЕ: вы можете использовать только ОДНУЮ запись виртуального хоста.Для этого попробуйте следующее: 

<VirtualHost *:80>
ServerName internal.example.com
ServerAlias sub1.example.com
ServerAlias sub2.example.com
ServerAlias sub3.example.com
DocumentRoot "X:/path/to/website/for/internal.example.com"
</VirtualHost>

ОЧЕНЬ ВАЖНОЕ ПРИМЕЧАНИЕ: Это может работать не так, как с SSL (порт 443).Я бы не знал, так как я еще мало что сделал с виртуальными хостами и SSL.Чтобы правильно настроить SSL с использованием этого метода, прочитайте следующее: http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2 ( summary , иногда делая выше, [который делает все то же самое, но с портом 443 вместо 80], будетработать, но, в зависимости от некоторых факторов, вы также можете просто захотеть сделать NamedVirtualHost 192.168.1.1:443 и, возможно, другие изменения конфигурации, как описано в статье).

Надеюсь, это поможет!

0 голосов
/ 27 апреля 2011

Проблема в том, что перенаправление инициирует новый запрос от клиентского браузера. Поэтому он запрашивает sub2.example.com, а обратный прокси-сервер DMZ этого не понимает.

Возможно, это могло бы работать без [R=...], но я даже не уверен в этом, поскольку он все еще может вызвать запрос. И, конечно же, это больше не перенаправление.

Поскольку обратный прокси-сервер является вашим интерфейсом, вам нужно, чтобы он понял sub2.xxx, иначе он не будет работать.

...