使用 Apache 2.2 mod_rewrite 来合并子域

发布于 2024-11-03 22:42:32 字数 1802 浏览 2 评论 0原文

我在使用 mod_rewrite 时遇到麻烦,需要帮助。

我在 DMZ 中有一个反向代理,它接受外部客户端请求子域 sub1.example.comsub2.example.com 的请求,并将它们(透明地)转发到内部公司网络 internal.example.com 中的单台计算机。具体来说:

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

虽然我无法控制 DMZ 中执行重定向的代理,但我可以完全控制托管 Apache 2.2 并侦听 80internal.example.com443 已加载 mod_rewrite

我需要配置此 Apache 实例,以将上述四个子域地址(HTTP 或 HTTPS 上的 sub1sub2)中的任何一个重定向到第四个地址 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),我已将以下内容添加到配置 SSL 环境的 VirtualHost 元素中:

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 位于同一网络上)进行测试时,重定向可以正常工作,它们无法在其外部的任何网络上工作,其中:

  • 任一子域(1 和 3)的 HTTP 地址无法完全加载
  • 任一子域(2 和 4)的 HTTPS 地址在客户端浏览器中产生错误,报告太多已执行重定向。

谁能建议我哪里出了问题,或者可能是适合我的情况的更合适的配置?提前致谢!

I am running into trouble using mod_rewrite and need help.

I have a reverse proxy in a DMZ which accepts requests from external clients asking for subdomains sub1.example.com and sub2.example.com and forwards them (transparently) to a single machine within an internal corporate network, internal.example.com. Specifically:

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

While I do not have control over the proxy in the DMZ performing the redirections, I do have complete control of internal.example.com which hosts Apache 2.2 and listens on 80 and 443 with mod_rewrite loaded.

I need to configure this Apache instance to perform a redirect of any of the four above subdomain addresses (sub1 or sub2 on either HTTP or HTTPS) to the fourth address https://sub2.example.com (4). To achieve this, I currently use the following in httpd.conf:

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

This works in redirecting clients that request addresses (1) and (3) (i.e., the HTTP address of either subdomain) to the right target (4), but has no effect in rewriting access to address (2). To redirect (2) to (4), I've added the following into the VirtualHost element configuring the SSL environment:

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

This is now triggered if the client requested sub1.example.com via HTTPS (confirmed via mod_rewrite logging). However, while redirections now work correctly when testing from machines behind the DMZ (internal and on the same network as internal.example.com), they fail to work on any network external to it, where:

  • The HTTP address for either subdomain (1 and 3) fail to load entirely
  • The HTTPS address for either subdomain (2 and 4) produce an error in client browsers which report that too many redirects have been performed.

Can anyone suggest where I've gone wrong, or perhaps a more appropriate configuration for my circumstances? Thanks in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

旧人九事 2024-11-10 22:42:33

虽然我没有使用我的解决方案来解决与您完全一样的问题,但我怀疑有一个更简单的解决方案比使用重写更干净的方法。
(注意:下面假设内部 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
总结,有时执行上述操作,[即做所有相同的事情,但使用端口 443 而不是 80],会起作用,但根据某些因素,您可能也只想做一个
命名虚拟主机 192.168.1.1:443
以及本文中描述的可能的其他配置更改)。

希望这有帮助!

While I have not used my solution for problems exactly like yours I suspect there is a simpler & cleaner way than using re-writes.
(NOTE: The below assumes that internal DNS recognizes your one server as the IP to resolve all of the subdomains to. If this is not the case then this change should likely be made... I don't know what would happen if it did not, but I've also never set up reverse proxy...)

Try the following:
-In httpd.conf @ the end verify that the following line appears:

NameVirtualHost *:80

-Finally add a VirtualHost for each* of the subdomains such as the following:

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

*IMPORTANT NOTE: you may be able to use only ONE virtual host entry.
To do this try the following:

<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>

VERY IMPORTANT NOTE:
This may not work in quite the same way with SSL (port 443).
I wouldn't know as I have not yet done much with virtual hosts & SSL.
In order to properly setup SSL using this method read the following: http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2
(summary, sometimes doing the above, [that is doing everything the same but with port 443 instead of 80], will work but, depending on some factors, you may also just want to do a
NamedVirtualHost 192.168.1.1:443
and possibly other configuration changes as described in the article).

Hope this helps!

泪眸﹌ 2024-11-10 22:42:33

问题在于重定向会触发来自客户端浏览器的新请求。因此,他请求 sub2.example.com,而 DMZ 反向代理无法理解这一点。

也许它可以在没有 [R=...] 的情况下工作,但我什至不确定,因为它仍然可能触发请求。当然,这不再是重定向。

由于反向代理是你的前端接口,你需要他理解sub2.xxx,否则它将无法工作。

The problem is that the redirection triggers a new request from the client browser. So he asks for sub2.example.com and the DMZ reverse proxy does not understand that.

Maybe it could work with no [R=...] but I'm not even sure of that, since it may still trigger a request. And of course, it's no more a redirection.

Since the reverse proxy is your front interface, you need him to understand sub2.xxx or it won't work.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文