内部到内部 NAT 又称 NAT 环回，解决了从内部接口上的计算机访问 ASA 或类似设备的外部接口上的 Web 服务器时的发夹式 NAT 问题。这可以防止 DNS 管理员必须维护重复的内部 DNS 区域，该区域具有其服务器的相应 RFC1918 地址，这些地址已 NAT 到公共地址。我不是网络工程师，所以我可能遗漏了一些东西，但这似乎很容易配置和实施。非对称路由可能是一个问题，但很容易缓解。
根据我的经验，网络管理员/工程师更喜欢系统人员只运行 split-dns，而不是配置防火墙以正确处理 NAT 发夹。这是为什么呢？
答案1
我不会这么做有几个原因：
- 如果没有必要，为什么要给 DMZ 路由器和防火墙增加额外的负担？我们的大多数内部服务都不在 DMZ 中，而是在一般的公司区域，DMZ 中的代理服务偶尔用于远程访问。进行内部到内部的 nat 会给 DMZ 增加更多负载，这在我们的情况下会很严重。
- 如果您不执行 DNAT + SNAT，您将获得非对称路由，这是出了名的难以正确实现的。因此，您使用 SNAT 并丢失源 IP 信息。但是，将源 IP 与人员联系起来进行故障排除非常有用。或者在出现愚蠢情况时偶尔进行故障排除。“嘿，这个 IP 在未经身份验证的服务 X 上做了一些奇怪的事情”“哦，让我们在 imap 服务器日志中查看它是谁”。
答案2
显然，不可能肯定的答案但我可以想到以下几个原因：
- 优雅：NAT 一开始就不是很优雅，但 IPv4 的地址空间有限，因此它是必不可少的。如果我可以避免使用 NAT，我会这样做。无论如何，有了 IPv6，这个问题就会消失。
- 复杂性：尤其是在您没有一个单一的“核心”路由器来创建所有安全边界的情况下，过滤器配置可能会变得非常棘手。要么您必须在几乎所有路由器设备上传播和维护 NAT 规则。
- 参考：如果防火墙管理员与服务器管理团队的其他成员不是同一组，那么可能很难联系到他们。为了确保变更不会因防火墙管理员的积压（或休假）而延迟，我们选择了将责任保留在同一团队中
- 可移植性和常见做法：使用 DNS 视图是“众所周知的”解决此问题的方法。并非每个边界路由器都以直接的方式支持环回 NAT，更少的人知道如何在特定环境中正确设置它。在排除网络故障时，工作人员需要了解发夹 NAT 配置及其所有影响 - 即使他们正在追踪一个看似不相关的问题
答案3
免责声明-这是一个引人深思的答案。
我认为避免此类解决方案的一个常见原因是网络工程师对 NAT 的非理性恐惧/仇恨。如果您想查看一些关于此问题的讨论示例，请查看以下内容：
- http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
- http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/（汤姆的博客似乎一直吸引着相当热烈的 NAT/IPv6 讨论）
- http://libertysys.com.au/blog/nat-is-evil-but-not-bad（我的博客）
据我所知，这种担忧很大程度上源于思科对 NAT 的糟糕实现（因此从这个意义上来说，这可能并非不合理），但在我看来，“传统”网络工程师对“NAT 不好”的世界观非常熟悉，以至于他或她看不到像这样的明显例子，而 NAT 却非常合理，实际上还可以简化解决方案。
就这样吧——随心所欲地投反对票吧！:-)
答案4
从我的角度来看，这在 Cisco Pix 到 ASA 的转换之间发生了一些变化。丢失了命令alias。一般来说，从 Cisco 防火墙的内部接口访问外部地址需要某种技巧。请参阅：如何通过外部 IP 访问我的内部服务器？
不过，我们并不总是需要维护重复的内部 DNS 区域。如果在 NAT 语句中进行了配置，Cisco ASA 可以将外部地址的 DNS 查询重定向到内部地址。但我更喜欢为公共 DNS 区域保留一个内部区域，以便具有这种粒度，并能够在一个地方进行管理，而不是进入防火墙。
通常，在环境中只有少数服务器可能需要这样做（邮件、网络、一些公共服务），因此这不是一个大问题。