Nat 是客气地说是跨层处理，或者不客气地说是公然的分层违规。

关于模型有句俗语，“所有模型都是错的，有些模型是有用的”。模型是分解问题和帮助理解的有用工具，但您不应该期望现实完全符合您的模型。

在 OSI 的主题上，网络供应商喜欢使用 OSI 层数，但重要的是要意识到我们今天使用的现实世界网络协议通常并非旨在符合 OSI 模型。

同样重要的是要认识到网络标准主要关注的是可以在网络上看到的东西。计算机或中间盒内部究竟发生了什么主要是个人实现者关心的问题。

IPv4 报头包含一个“协议”字段，该字段携带正在使用的传输协议的协议号。这旨在供接收数据包的终端主机使用，但 NAT（或 L4 感知防火墙）也将使用它来识别正在使用的传输协议。

对于最常见的传输协议 TCP、UDP 和 ICMP，NAT 肯定会有特定于协议的实现来提取和转换数据包数据。对于 TCP 和 UDP，它将知道如何提取/修改端口号以及如何重新计算校验和以考虑新的 IP 地址和端口。

NAT 可以处理的 ICMP 流量通常分为两类。查询/响应和错误。可以以与 TCP 和 UDP 数据包类似的方式处理查询/响应消息，以与端口号类似的方式处理 Type/Code 和 Identifier 字段。通过提取“上下文”数据包的内部标头并翻译它们来处理错误消息。

值得注意的是，虽然 NAT 必须知道一些传输层字段，但 NAT 过程不必完全实现传输协议。一个特定协议的 NAT 和防火墙的实现很可能与该协议的常规实现是分开的，并且中间盒可能对它不支持充当终端主机的协议具有 NAT 和防火墙支持。

我的问题是当 layer3 使用 layer4 内容时它会破坏 IPv4 数据报以了解端口号等？真的没有意义。

NAPT在出口将privateSourceIP-privateSourcePort转换为publicSourceIP-publicSourcePort元组，并反转该转换以返回数据包/段/数据报。

源端口可能会或可能不会改变。IP 地址是 IPv4 标头的一部分。端口号是 TCP 或 UDP 标头的一部分。所有校验和都需要修复。

首先，OSI 模型只是一个参考模型，用于理解不同的层、它们的角色和关注点的分离。

实际上，我们不必拥有所有层，例如应用层可以直接使用数据链路层（如果不需要传输层和网络层的服务）。某些工业数据网络（如 Profibus 和 HART）恰好遵循这种模式。

也就是说，层之间的边界只是理论上的，在实践中我们可以很容易地构建跨层函数。

此外，在某些系统上，IP、TCP 和 UDP 校验和在它们在线传输（校验和卸载）之前在 NIC 上计算，并且在此类系统上，NAT 功能甚至不关心重新计算这些校验和