我相当确定这是一个 NAT 或路由问题，但它一直困扰着我。
硬件是 Checkpoint Safe@Office 防火墙。默认操作模式是有线客户端位于 192.168.10.x 网络上，而 wifi 客户端位于 192.168.252.x 网络上，并且它们之间有防火墙隔开。
有线侧的一台计算机充当 Web 服务器；为我的企业网站的“dev”子域提供服务。它可从外部和内部访问，并且一切正常。
但是，出于其他原因，我需要有线和 wifi 网络能够相互通信。为此，您可以将设备设置为“桥接模式”，这样有线和 wifi 客户端最终都会获得 192.168.10.x IP 地址并可以自由通信。
不幸的是，以这种方式桥接会严重损害 Web 服务器的性能，以致于它在网络内部无法使用 - 但从外部来看它仍然可以使用。
如果我从网络内部 ping dev.mydomain.com，它会解析为我的公共IP - 并且我之前的所有尝试（以及谷歌搜索）使此配置正常工作都表明，由于请求是出站的，然后又返回到网络，它是“双重natting”或类似的东西，导致路由器不确定如何处理它。
有办法解决这个问题吗？我发现其他人也遇到了同样的问题（跨不同的设备），但我还没有找到有效的解决方案。
2013年3月31日更新：
我确信第一个回答者使用 NAT 规则重定向流量的做法是正确的。
起初，我以为是硬件出了问题 - 但我已经能够通过成功地将所有出站网络流量从一个设备重定向到虚无来确认这一点，它按预期工作。
所以现在的问题是——需要发挥什么 NAT 规则的作用来确保流量正确地路由到内部网络？
我尝试了最明显的做法：
什么时候：资料来源内部网络，目的地是我的公共 IP服务是网络服务器
然后：不要改变来源，改变目的地我的内部服务器 IP并且不要改变服务。
这不起作用，但我觉得应该起作用。
更新 #2
我正在使用 Microsoft 网络监视器尝试观察数据包，看看是否能提供任何见解。
首先，这引发了一个关于 NAT 转换如何工作的问题——因为即使制定了规则，我看到请求发送到 dev.mydomain.com 并且在数据包内部，目的地仍然显示为我的公共 IP。 翻译是否应该真正改变目的地，还是只是应该默默地重定向它？
其次，这也证实了这个问题。如果我在捕获数据包的同时查看一个真实的网站，其模式看起来与你预期的差不多 - 首先，DNS 查找出去并返回，然后是一些请求（可能涉及所有标准文件、JS、CSS 等以及 HTML 本身），每个请求几乎立即得到数据包的答复。
如果我查看我的 dev. 子域，结果非常片面。无论有没有 NAT 规则，我看到的是请求发出后初始响应返回，然后 HTTP GET 请求发出并返回（实际上包含页面的 HTML） - 但之后什么都没有。一堆请求（我猜）是包含内容，但没有得到答复。最终，它们再次发出，但仍然没有返回任何内容。
我们是否正在查看的是 Apache 问题而不是路由器问题？
更新 #3
因此，我创建了一个基本的 HTML 页面，其中只有一行文本，没有包含文件，无论有没有 NAT 规则，它都可以工作，有时立即生效，有时需要几秒钟 - 但总是可以工作。然后，我以与实际页面中包含图像相同的方式包含图像，然后加载 - 但总是需要几到几十秒的时间。考虑到实际页面会有许多图像请求以及其他文件，如果它们都那么慢，那么这似乎并不奇怪，这解释了页面超时的原因。我还没有弄清楚原因。
答案1
您应该能够在此设备中设置透明代理规则，将内部网络到端口 80 的所有出站流量重定向到您的外部 IP 地址，然后重定向到您的 Web 服务器的本地（内部）IP 地址。
在 NAT 下：
Source: Internal Network IPs (Range) 192.168.10.1-192.168.10.254
Destination: External IP
Service: Web Port 80
Change the destination to:
Destination: Internal WebServer IP
目前，您正在执行外部 DNS 查找，而 DynamicDNS 正在为开发服务器提供您网络的外部 IP。内部流量尝试流出路由器，然后路由器应该执行 NAT 以将来自网络的端口 80 流量传输回网络服务器的本地（内部）IP。
为了安全起见，您可能只应该允许来自特定（白名单）IP 地址（内部和外部）的 Web 服务器流量，因为您允许来自外部的连接。