组织的计算机networking具有192.168 / 16 IP地址范围的NAT。 有一个服务器的部门有一个IP地址192.168.xy，这个服务器处理这个部门的主机与另一个NAT的IP地址范围172.16 / 16。
因此有2层的NAT。 他们为什么不划分子网呢？ 这将允许简单的路由。
我觉得多层NAT可能会造成性能损失。 你能帮我比较两种devise策略吗？
更新：
@Jon一些更多的信息
在与朋友讨论时，我们意识到子网划分会导致以下问题。 计算机的ARP请求会泛滥整个组织的networking。 如果路由器不转发这些请求，那么一个部门中的PC将不能连接到其他部门中的PC，如果它们位于不同的NAT后面，则无法完成。 使用数据包嗅探器，我们发现有大量的ARP请求，因为部门中的大多数计算机都启用了Windows上的文件共享。
如何解决这个问题？
另外，如果两台电脑位于不同的NAT之后，那么他们就没有办法互相连接了。
做多层NAT的唯一真正的问题是它使你的networking拓扑混乱。 如果您使用多个NAT层，则会丢弃组织中所有主机之间的对称路由，并且还可能会在networking中发生重叠的专用地址空间。 想象一下，如果你在第n层的n + 1 NAT层中使用了一个地址范围， 这些networking永远不能互相路由，但n + 1层中的主机可能具有与n层相同的地址，从而使服务器的身份混乱。
如果我正在布局大型networking的拓扑结构，那么我将只使用10. *或172.16-24。*地址来连接任何子网上的主机。 然后，如果有些部门或个人想要加倍NAT，他们可以（使用192.168。*networking）了解到他们负责NAT主机后面的networking。 我也更倾向于创build更多的子网，而不是让这些双NATnetworking中的任何一个变得太大。
多级NAT的问题与单层NAT基本相同，但复合化。 如：
在数据包生命周期内由于额外的工作而导致延迟（尽pipe在大多数情况下这不太可能是显着的）
知道什么来自哪里。 如果您试图追踪某些请求来自哪里（也许您的传出防火墙已经logging了看起来像是试图发送垃圾邮件或search其他感染目标的受感染机器），NAT使得这样的诊断更加困难。
传入连接端口转发，如果您需要传入连接，则更易于设置和维护。
有限的端口数量。 NAT通过在不同端口上将源地址转换为自身来工作，例如：
直到你有很多传出的连接，比如一个大的networking或者一个小的networking，这些networking连接的机器可以做很多的连接（比如实现bittorrent协议的P2P应用可以创build许多并发的连接），这一切都很好。 IP协议只有65536个端口，less于保留的1024个端口。 虽然60,000可能听起来很多，但它可以很快被消耗，然后NAT盒子需要决定哪些旧的映射可以被删除，这通常不像“删除最老的”那样简单。 这可能导致一些奇怪的错误（随机连接丢失，难以诊断），或者机器暂时无法build立新的连接。
加载到NAT盒子上。 如果你正在使用一些低功耗的设备（例如现成的支持NAT的路由器，而不是一台带有笨重的CPU的完整的个人电脑）来做你的NAT，额外的翻译工作（与简单地按照基本路由表）可能会减慢通过他们的转移。 对于互联网访问来说，这可能不是一个问题（你的networking连接将成为瓶颈），但是当你在本地网段之间进行NAT时，它可能变得相当明显。
性能损失/速度实际上取决于您使用的路由器的质量。
对于好的/坏的想法，我可以简单地使用路由，但是，它真的取决于环境和你正在努力完成的事情。
如果机器只需要运行一些在标准端口上共享的东西，就可以进入路由器/自动给予设备，并设置一个规则来允许你想要的（1）。 但是，如果您将要执行大量的设备到设备任务，那么在每台拥有自己的唯一IP的计算机上进行适当的路由将变得更加容易（2）。
（1）例如，一对多 – 一台机器有一台networking服务器，您想将它分享给其他人 – 您可以在路由器中设置一条规则到机器的端口80，然后从外部networking（或内部如果nat-loopback被启用）可以简单地转到http：//router.ip并且可以访问。
（2）如果每一台机器都打开一个networking服务器，或者你将要使用大量的服务，你将会有一个噩梦设置所有的规则（但这不是不可能的）。
至于你的情况 – 如果一个部门使用192.168.xx和其他192.168.yx，我会通过设备，如果没有重叠，可能只是可能将子网从/ 24更改为/ 16（或另一种方式），然后用交换机或类似的交换机来replace路由器，并且不会有服务中断。
如果不知道更多关于你的networking的信息真的很难，只要设置正确，双NAT就没有什么“错误”。 但是，除非你真的需要，否则有一个很好的理由，如果可以的话，我会考虑迁移（个人意见）
@iamrohitbanga – 回应你的问题（很多评论）。
比较很难 – 对于每台机器都能够访问每台机器的专用networking，路由工作良好。 Nat运行良好，但主要用于不需要路由的networking，因为您通常需要手动设置传入的规则/路由。
例如，如果您有互联网连接并禁用NAT，则手动设置路由或桥接模式 – 您的机器将直接在互联网上 – 所有端口均可访问，任何机器都可以按照自己的意愿进行操作。
另一方面，如果你有一个路由器与NAT，它将采取外部的IP，并提供“自然？ （不确定的术语…）互联网 – 所有的内部机器有一个IP不能从互联网上访问，但是，你可以设置手动规则 – 例如端口80到一台机器…它适用于传出连接（防火墙规则允许），但如果您主持许多服务，可能会成为一个噩梦来build立传入的规则…如果你做任何需要dynamic端口（FTP，Windows AD等），它可能是一个噩梦。
希望这有助于，如果你想知道什么，随时问。
NAT的主要问题（一般来说，特别是多层）是非常难以排除故障。
NAT最大的问题就是当networking软件翻译过时，很多应用受到伤害（FTP，VoIP等）。 现代防火墙/网关具有翻译（以思科术语进行修正），这使得它更容易。
我不明白你的公司为什么在私有子网之间使用NAT。 为什么不直接路由呢？
只需将您的networking和客户端升级到IPV6，就不需要再次使用NAT了。
回答你的问题的新的第二部分…
路由器中断广播域 – 路由器不转发ARP数据包，它们停留在子网内*。 你的Windows文件共享（严重吗？）Netbios广播stream量不会离开子网。
使用子网：
如果您需要从子网外访问Windows共享，则可以通过直接使用其IP地址或通过主机名设置DNS或WINS服务器来访问它。
与NAT：
如果你的NAT是PAT的types，因此不是一对一的映射，你需要configuration端口转发这个工作 – 这将是糟糕的。
正如已经讨论过的那样，NAT通常是一件坏事，因为它会破坏networkingfunction，我们只能使用，因为我们必须这样做。 在IPv6上滚动。
*当然广播代理/继电器/佣工确实存在