基本上，假设您的域名 acme.com 的外部 IP 地址为 1.2.3.4，并且您将所有 WWW 流量端口转发到内部机器，例如 192.168.0.20/24。然后，192.169.0.x 网络上的 /内部/ 用户尝试访问 http://www.acme.com，并期望一切正常。嗯，基本配置不会发生这种情况。让我解释一下。基本上，http://www.acme.com 正在被您选择的 DNS 服务器解析为 http://1.2.3.4 的 IP。真正应该发生的是 Web 请求应该将该请求解析为 http://192.168.0.20。
看到区别了吗？
解决此问题的正确方法是设置一个分离 DNS 服务器。内部用户将被配置为使用 /内部/ DNS 服务器，当被询问 www.acme.com 时，该服务器会将此类请求解析为 192.168.0.20 地址。所有外部用户应由 /外部/ DNS 服务器提供服务，该服务器会将请求解析为 1.2.3.4 IP 地址。从那里，IPTABLES/IPCHAINS/IPFWADM 将像往常一样将流量端口转发到 192.168.0.20 服务器。
但是您可能在想，您不想设置分离 DNS 服务器，并且必须有另一种方法。还有一些替代方案！第一个替代方案是如果您只有少数内部机器。在这里，您可以在 *所有* 内部机器上设置“hosts”文件条目。该静态 hosts 条目基本上看起来像
www.acme.com 192.168.0.20 |
明白了吗？有了这个设置，机器将在访问 DNS 服务器解析主机之前查询 hosts 表。这效果很好，但是如果您更改了内部 Web 服务器上的 IP 地址，您将需要手动更新所有这些内部机器上的 hosts 文件。如果您对进行更具可扩展性的分离 DNS 方法感兴趣，TrinityOS 完全涵盖了分离和 chrooted DNS 服务器。TrinityOS - 第 24 节 http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos
现在，如果分离 DNS 和 hosts 文件方法都不让您感兴趣，您仍然有一个简单但有效的替代方案来使事情正常工作。您可以做的是向您的 rc.firewall-* 规则集添加一些特定规则。请参阅 第 6.7 节 章节下的“内部请求的端口转发重定向”部分。
为什么我没有首先提到这个替代解决方案？主要原因是这不是理想的解决方案。这种方法的主要问题是每个数据包都将从内部 MASQed 客户端发送到 MASQ 服务器。在那里，MASQ 服务器会将每个数据包的源网络地址转换为内部 MASQed WWW 服务器的 IP，然后将其转发到内部 Web 服务器。一旦 Web 服务器接收到数据包并做出响应，该响应必须通过所有这些处理返回到原始客户端机器。此过程在网络带宽和 MASQ 服务器 CPU 周期方面都过度浪费！