☰

IP 重定向 Lets 加密

tag-icon • tag-icon networking lets-encrypt
IP 重定向 Lets 加密

以下是有关 http 验证的 Lets encrypt 文档：

“我们对 HTTP-01 挑战的实施遵循重定向，深度最多为 10 次重定向。它只接受重定向到“http:”或“https:”，并且只接受重定向到端口 80 或 443。它不接受重定向到 IP 地址。当重定向到 HTTPS URL 时，它不会验证证书（因为此挑战旨在引导有效证书，因此它可能会在此过程中遇到自签名或过期的证书）。”

我为此做了几件事：

  1. 我在我的服务器上启用了端口 80，并且在服务器前使用 Azure 防火墙。在 Azure 防火墙上，我配置了 DNAT 规则，即所有传入防火墙端口 80 的流量都应转发到服务器的 80 端口。 结果：我可以看到此案中颁发的证书。

  2. 我在我的服务器上启用了端口 443。在 Azure 防火墙上，我配置了 DNAT 规则，即所有传入防火墙端口 80 的流量都应转发到服务器的 443 端口。 结果：我看到结果是否定的，在这种情况下没有颁发证书。

我对这些结果有几个疑问：

  1. 根据文档中的句子，“它不接受重定向到 IP 地址”。为什么我的第一个案例有效？DNAT 不是 IP 重定向吗？

  2. 如果不是重定向，为什么我的第二个案例失败了？

答案1

不，DNAT 不是重定向。

重定向是一种格式的 HTTP 响应

HTTP/1.1 302 Moved Temporarily
Location: http://other.location/of/the/resource

也就是说，它是由 HTTP 服务器发出的，并且发生在第 7 层，即应用层。NAT 发生在网络层，即第 3 层；进行通信的程序（HTTP 客户端和 HTTP 服务器）根本不知道它曾经发生过。

为什么端口 443 不起作用？首先回答一下，你想通过将 HTTP 端口 80 NAT 到静态 SSL/TLS 端口 443 来做什么？监听端口 443 的服务器通常配置为使用 SSL，因此它首先期望看到SSL 客户端Hello数据包，但访问80端口的客户端马上发出HTTP请求。

提示：对两个端口进行 NAT，80 到 80，443 到 443。确保在端口 80 上接受的请求重定向到 *https://*something；有很多手册介绍如何做到这一点，包括 Certbot 自己的配置大师，它会询问您是否要安装这样的重定向。

相关内容