NAT 网关 - 最大连接限制

Dan*_*ick 11 networking nat tcp

我知道足够的网络是危险的。NAT 的底层细节并不是我特别了解的。

今天早些时候,我无意中发现自己参与了关于将一堆节点置于 NAT 网关后面的讨论。(1 个公共 IP 地址和 X 个私有 LAN 地址)。我调用了 TCP 协议中源和目标端口字段的 16 位限制(http://www.ietf.org/rfc/rfc793.txt - 第 15 页)并提到它会将我们限制为大约 65,000 个连接( 65536)。——我对那个答案不再那么有信心了。你能帮我提供一些细节吗?

我知道我们这边的传入端口(服务器端口)可以接受与 sourceIP x SourcePort 组合一样多的连接。让我们暂时忽略这些,重点关注源自 LAN、通过 NAT 网关并在随机端口的随机主机上结束的连接。

在普通的 [Linux] 系统上,我认为每个源 IP 的每个端口只能有 1 个传出连接。如果我们假设我们生活在一个简单的世界中,其中每个系统只有 1 个 IP 地址,那么“正常系统”将被限制为绝对最大 65536 个连接。

1) 在 TCP 中是单源 IP 限制为 65536 MAX 理论传出连接?

2) 还是每个远程主机的限制实际上是 65536 个连接?

2) [Written another way]:同一个源端口可以用于不同的remoteHostIP:RemotePort组合吗?

例如:(以下可以吗?)

Source IP   |Source Port |Remote IP|Remote Port   
192.168.0.20:36500   -->    8.8.8.8:23
192.168.0.20:36500   -->    8.8.4.4:23
Run Code Online (Sandbox Code Playgroud)

3) 问题 1 和问题 2 的答案对于……“非正常系统”[充当 NAT 网关的思科路由器] 是否不同?

例如:一种专用网络设备,它有一个面向公众的 IP 和多达约 65,000 个 LAN IP [或更多]?是否有魔法,或者问题 2 的答案总是:是的?(或没有)

4)以上问题均假设有状态的TCP连接。对于像 UDP 这样的无状态连接,情况有什么不同吗?

最终:

5) 我们的 LAN 是否会被限制为 65536(或其他一些理论限制)通过单个公共 IP 地址与外部世界的并发连接?

谢谢!:)


出于这个问题的目的,我们支持非常强大且全新的 Cisco Nexus 设备(我认为是 7000 系列)。除非可以具体量化,否则最好忽略内存/等限制。

hoo*_*enz 8

如果我错了,请纠正我,但这是我理解的方式。限制是每个客户端/服务器/端口。所以有鉴于此。

1) 在 TCP 中是单源 IP 限制为 65536 MAX 理论传出连接?

不。我相信它被限制为 65536 理论最大值到相同的目标 IP。

Windows 工作站(非服务器版本)有一些限制,这使得这个数字要少得多。Linux 有资源限制,但它们通常不会受到普通用户的影响,您可以轻松调整它们。

当您开始增加接近 64K 的数量时,您可能会遇到其他资源限制。

由于资源有限,消费级路由器的限制可能要低得多。

2) 还是每个远程主机的限制实际上是 65536 个连接?

是的

3) 问题 1 和问题 2 的答案对于……“非正常系统”[充当 NAT 网关的思科路由器] 是否不同?

4)以上问题均假设有状态的TCP连接。对于像 UDP 这样的无状态连接,情况有什么不同吗?

UDP 是无连接的。所以这与UDP并没有真正的关系。

5) 我们的 LAN 是否会被限制为 65536(或其他一些理论限制)通过单个公共 IP 地址与外部世界的并发连接?

不。


在跟踪连接并提供其他跟踪功能的有状态防火墙的上下文中,是的,这些模块本身可能有限制。op 没有说明正在使用哪个防火墙/NAT 路由器,因此我们甚至无法推测它目前可能施加的限制。

  • UDP 受相同限制的影响。当 UDP 数据包离开 NAT 防火墙时,它必须将该端口和远程 IP 地址保持打开一段时间,以便返回数据包通过。 (3认同)
  • 根据 Socket Reuse 对 user8162 的回答的评论,可以想象构建一个使用完整的 5 部分元组(协议 [udp/tcp]、源 ip、目标 ip、源端口、目标端口)作为唯一键的 NAT 平台每个传出套接字。Host1:port1 -> host2:port2 和 Host1:port1 -> host3:port2 是可以想象的布局,理论上可以指向单独的套接字。考虑到这一点,除非我在 TCP 规范或其他官方文档中看到阻止此功能的内容,否则我将不得不接受 Matt 的回答是正确的。(考虑到 udp 的考虑)。 (3认同)