我正在尝试了解 NAT 和 NAT 表的工作原理，但似乎无法在线找到答案。我有几个关于 NAT 的问题。假设已建立 TCP 连接。
假设路由器有 WAN 201.22.14.15
1) 假设 IP 为 192.168.1.1 的设备想要连接到 IP 为 137.132.1.15 的服务器。该设备首先将数据封装在 IP 数据报中，源 IP 为 192.168.1.1，目标 IP 为 137.132.1.15？
2) 之后数据报被发送到发生 NAT 的路由器。假设这是在专用网络中发送的第一个数据包，NAT 表最初是空的？
3) 现在表中有一个条目将 192.168.1.1:1234 映射到 201.22.14.15:2345。？
192.168.1.1:1234 -> 201.22.14.15:2345
IP 数据报在发送之前会重新打包相应的路由器地址 (201.22.14.15) 和端口号 2345。路由器与服务器之间是否有单独的 TCP 连接？或者该条目只是分配了一个虚拟端口号？
4) 数据从服务器 137.132.1.15 返回，其目标 IP 为 201.22.14.15，目标端口为 2345。路由器进行表查找，发现 201.22.14.15:2345 映射到 192.168.1.1:1234。因此，它重新打包 IP 数据报，源地址为 137.132.1.15:80，目标地址为 192.168.1.1:1234
我不确定我强调的步骤是否正确。
答案1
我将尽量简单解释。NAT 主要有两种类型：
- 源 NAT：通常称为“伪装”，它用他的地址掩盖您的本地 IP 地址，以便它可以与不知道到您的本地网络的路由的网络中主机进行通信。
- 目标 NAT：通常称为“端口转发”，它将目标网络地址转换为外部网络中的本地地址。
我认为您描述的是源 NAT，即从本地网络到互联网服务器的通信。发生的事情正如您所说的，但让我稍微改述一下：
- 您从本地网络到互联网建立连接：
192.168.1.1 -> 137.132.1.15:PORT，您的源端口是随机的。 - 根据您的路由表，在 IP 为 192.168.1.1 的本地主机中，您的数据包将到达下一跳，通常是互联网目的地的默认网关。
- 当你的数据包到达配置了源 NAT 的设备时，它会转换源地址，伪装数据包的源并将其转换为
201.22.14.15 -> 137.132.1.15:PORT。它会记住此连接来自你的本地 IP 192.168.1.1。 - 我们假设，大多数情况下， 137.132.1.15 是一个防火墙，它会将目标端口 PORT NAT 到外部本地网络，例如 10.0.0.1，并且假设它是一个 Web 服务器，因此它会将数据包转换为
201.22.14.15 -> 10.0.0.1:80。 - 10.0.0.1 的服务器将会收到来自 201.22.14.15 的请求，当返回时，另一边也会发生同样的事情，根据他的路由表，他将返回到 201.22.14.15。
- 路由器/防火墙将需要以另一种方式进行伪装，将数据包地址更改为
137.132.1.15 -> 201.22.14.15。 - 您的路由器 201.22.14.15 将接收数据包，将能够检测到与 192.168.1.1 生成的流相关的数据包并返回响应。192.168.1.1 将看到来自 137.132.1.15 的数据包，因为 10.0.0.1 已被伪装。
希望它能有所帮助并且不会造成更多混乱。
边注
TCP 连接不是以数据报的形式组织的，而是以流的形式组织的。数据报是 UDP。
答案2
以下是针对 Linux 内核的，但我认为 MacOS 和 Windows 的工作方式类似。
所谓的“NAT表”连接追踪器或conntrack简称。您可以使用一些工具来检查此表。
1)是的。
2) 是的。确切地说，连接跟踪表没有此连接的条目，它不必为空。连接的特征是源地址、源端口、目标地址和目标端口；它所映射的端口号是一个附加条目。
3a) 是的，其中 2345 是尚未使用的端口。如果我没记错的话，它默认为原始源端口。之所以创建连接跟踪器条目，是因为存在一条iptables带有 SNAT（源 NAT）目标的规则。
b) 不，此连接不会被跟踪为普通 TCP 连接。netfilter 连接跟踪器和 TCP 连接状态表完全不同。
4) 是的。请注意，不需要有反向iptables规则；这让很多人感到困惑。