☰

无法通过 PfSense 防火墙后面的同一服务器上的 HTTPS 访问域

tag-icon • tag-icon networking ubuntu firewall nginx https
无法通过 PfSense 防火墙后面的同一服务器上的 HTTPS 访问域

我在一台有多个域名的服务器上托管一个平台，比如 example.com 和 anotherexample.com。我在该服务器上运行 Spring Boot 后端，它使用域 example.com 并尝试与 anotherexample.com 通信。我的问题是我似乎无法通过 HTTPS 连接到其他域，它根本无法连接。我尝试了以下测试，结果不同：

  1. curl在防火墙之外的机器上使用https://anotherexample.com，完美运作
  2. curl在服务器上使用，而是使用http://anotherexample.com，完美运作
  3. curl在服务器上使用https://anotherexample.com，没有回应，最终超时
  4. curl在防火墙上使用https://anotherexample.com，没有回应，最终超时
  5. 在服务器上使用openssl s_client -connect anotherexample.com:443 -servername anotherexample.com，无响应，最终超时
  6. /etc/hosts在服务器上更改为127.0.0.1 anotherexample.com，运行时 openssl s_client -connect anotherexample.com:443 -servername anotherexample.com，我收到了响应。

什么问题导致我无法连接到防火墙后面的机器上托管的任何域，是不是服务器（Ubuntu 22.04）或 PfSense 防火墙（2.7.2）上配置有错误。


我的结构如下：

  • PfSense 防火墙使用 NAT 确保公共 IP 到达服务器的内部 IP
  • 运行 NGINX 的服务器，端口 80 和 443 开放。证书通过 LetsEncrypt 完成，可在浏览器中完美运行

答案1

这是正常的；当源和实际目标都在同一个子网（或实际上是同一个系统）上时，DNAT（“端口转发”）不起作用。许多早期的帖子都发布了有关家庭网关的相同问题（搜索“NAT hairpin”），但它同样适用于包括 pfSense 在内的任何 NAT 实现，因此请搜索早期的帖子以获取完整解释；基本问题是防火墙只能在一个方向上重写数据包，而不能在另一个方向上重写数据包。

一种常见的解决方法是让 pfSense 重写源 IP 地址，让 Web 服务器认为连接实际上来自防火墙而不是它自己。为此，请启用NAT 反射在您的防火墙中。在其他地方，它可能被称为“NAT 环回”、“NAT 发夹”，或者只是没有特定名称的自定义 SNAT 规则。

请注意，这会对性能产生轻微影响，因为每个数据包都必须通过以太网到达 pfSense和返回，而不是完全留在机器内。如果您使用基于 IP 的访问，您的 Web 应用还需要预期防火墙 IP。

所以我个人认为推荐所有域的 /etc/hosts条目127.0.0.1，而不是依赖 NAT 反射。

相关内容