波仔
📡 第五章 防火墙功能与防范威胁的对策
📄 一句话概括

NAT 表条目决定「能同时有多少条连接做地址转换」。 而它与公网 IP 是乘法关系：一个 IP 约 6.4 万条。

📝 本节和前面几节的关系

上一节讲会话数，这一节讲它的「近亲」——NAT 表。 两者的关系是「NAT 表是会话表的子集」：只有需要转换的会话才占 NAT 表。

一、一个公网 IP 有多少条

端口空间 65536 个，减去 1024 以下的知名端口，约 6.4 万个可用。 这就是「一个公网 IP 能提供 6.4 万条 NAT 条目」的来历。

按内网规模算要几个公网 IP： 500 台 × 每台 50 条并发 ＝ 2.5 万条 → 1 个 IP。 2000 台 × 100 条 ＝ 20 万条 → 4 个 IP。 2 万台 × 50 条 ＝ 100 万条 → 16 个 IP。

注意最后一行：两万台主机其实只要 16 个公网 IP， 因为 NAPT 是按「五元组」区分的，不是一个会话占一个端口。 这是 NAPT 相对「一对一 NAT」最大的优势。

二、真正的瓶颈是热门目的地

上面那个算法有个隐含前提：不同会话的目的地址和端口是分散的。

如果几千台主机同时访问「同一个服务器的同一个端口」， 那么「目的地址、目的端口、协议」这三项完全相同，能用来区分的只剩「源端口」一个维度——上限就是 6.4 万条。

这个场景并不罕见： 全公司早上九点同时打开同一个 OA 系统、同一个代理服务器、同一个视频会议服务，都会撞上这个上限。

所以 NAT 表的真实瓶颈，往往不是「主机数」，是「热门目的地」。 判断方法很简单：按目的地址统计 NAT 表条目，看有没有某一行占了绝大比例。

三、NAT 表与日志的关系

这里有一个容易忽略的合规问题：NAT 之后，服务器日志里记的全是「公网地址加端口」。 要追到具体是谁，必须有一张「某个时刻，这个端口对应哪个内网地址」的表。

所以 NAT 日志的保留要求往往比会话日志更长： 会话日志可以只留几天，NAT 映射日志通常要求留半年以上。

而 NAT 日志的量级不小： 每一次「新建映射」都要记一条，20 万条并发的网络一天可能产生上千万条记录。 这也是为什么很多单位宁可做「固定端口映射」而不做动态 NAT——固定映射不需要记流水账。

一句话总结： NAT 表不只是性能指标，它还是一份「地址翻译的账本」，而这份账本在追查事件时是不可替代的。

四、动手 Demo：NAT 表条目和公网 IP 的换算

这段按「一个公网 IP 约 6.4 万条」算三种规模各要几个 IP， 再说明「热门目的地」为什么会让这个换算失效。

for hosts, conc in ((500, 50), (2000, 100), (20000, 50)):
    need = hosts * conc
    ips = -(-need // 64000)
    T([u"%s" % format(hosts, u","), u"%d" % conc,
       u"%s" % format(need, u","), u"%d" % ips], [0, 0, 0, 0])

实跑输出：

--------------------------------------------------------------------
NAT 表条目和公网 IP 的换算
--------------------------------------------------------------------
**NAT 表条目数决定「能同时有多少条连接做地址转换」**，**而它与公网 IP 的数量是乘法关系。**

**一个公网 IP 能提供多少条 NAT 条目**：
  端口空间 65536 个，其中 1024 以下留给知名服务，
  再留一部分给「同一目的地址复用」的冲突，实际约 6.4 万个。

**算不同规模要多少公网 IP**：

  内网主机     每台并发     总条目        公网 IP
  ---------------------------------------------------
  500          50           25,000        1
  2,000        100          200,000       4
  20,000       50           1,000,000     16

**注意第三行**：两万台主机其实只要 16 个公网 IP，
**因为同一台主机的多条连接是「按五元组」区分的，不是一个会话占一个端口。**

**但这里有个陷阱**：

  如果内网主机访问的是同一个服务器的同一个端口，
  那么「源端口」就必须各不相同 → 一个目的端最多 6.4 万条。
  两万台主机同时访问一个热门站点，就会卡在这个上限。

**所以 NAT 表的真正瓶颈，往往不是主机数，是「热门目的地」。**

「两万台只要 16 个 IP」这个结论会让人意外，但它正是 NAPT 的价值所在： 它把「每台一个地址」变成了「每几千条并发一个地址」。

注意「热门目的地」那段：它说明「平均数」在容量规划里是不可靠的， 要看的是「最热的那一个目的地占了多少」。 这也是为什么真实网络里，「上不了网」有时只影响「某个网站」。

最后那段 NAT 日志的合规问题最容易被忽视： 很多单位能做到「查得到谁上了网」，但做不到「查得到某个公网端口当时是谁」， 因为 NAT 映射日志没留。 这一条在做等保或审计时经常被提出来。

30 秒实验

  1. 查一下你单位出口有几个公网 IP。
  2. 看 NAT 表的条目按目的地址排，前三名各占多少。
  3. 想一想：如果要做「谁在什么时间访问了什么」，需要留哪些日志？

常见误区

  1. 以为一个公网 IP 只能带 254 台主机。NAPT 靠端口，能带几千台。
  2. 以为主机数决定 NAT 表大小。热门目的地才是真瓶颈。
  3. 以为 NAT 表只是性能指标。它还是追查事件时不可替代的账本。
自测三问（点开对答案） 1. 一个公网 IP 大约能提供多少条 NAT 条目？为什么？ —— 约 6.4 万条，因为端口空间 65536 减去 1024 以下的知名端口。 2. 为什么「热门目的地」会成为 NAT 表的真瓶颈？ —— 目的三元组相同时只能靠源端口区分，上限就是 6.4 万条。 3. 为什么 NAT 映射日志的保留要求比会话日志更长？ —— 因为追查「某时刻某公网端口对应哪个内网地址」只能靠它。

下一节：第三个数字——每秒能新建多少条会话。

相关笔记