7.2. Firewalls

The two major types of firewalls commonly used include proxy firewalls and packet-filtering firewalls. The main difference between them is the layer in the protocol stack at which they operate, and consequently the way IP addresses and port numbers are used. The packet-filtering firewall is an Internet router that drops datagrams that (fail to) meet specific criteria. The proxy firewall operates as a multihomed server host from the viewpoint of an Internet client. That is, it is the endpoint of TCP and UDP transport associations; it does not typically route IP datagrams at the IP protocol layer.

包过滤防火墙在网络层和传输层工作，通过检查 IP 地址和端口号决定是否转发数据报，速度快但只能做基本安全控制；而代理防火墙在应用层工作，作为客户端和服务器之间的中介终止连接，可以检查应用层数据内容，安全性更高但性能相对较低。

顺便提一嘴， WAF 属于啥？ 四层代理 & 七层检测。

7.2.1. Packet-Filtering Firewalls

最简单的包过滤防火墙是无状态（stateless）的，它们逐个数据报独立判断是否放行；而更高级的状态防火墙（stateful）能够跟踪和关联同一传输会话中的数据包或 IP 分片，从而对数据流做更智能的判断，无状态防火墙在处理 IP 分片时容易出错。

7.2.2. Proxy Firewalls

有点感慨，一点题外话：90 年代的《TCP/IP 详解》，它对代理防火墙的描述——多接口主机、应用层网关、客户端与代理连接——已经非常接近 WAF 的雏形理念。， 书里已经抓住了应用层防护安全的核心：

• 多接口隔离内外网 → 隐藏内部网络

• 应用层检查 → 控制协议流量，而不是单纯丢包

• 客户端连接代理 → 安全控制和流量转发

本章主要内容

1. 定义与本质
   • 代理防火墙不是传统意义上的 IP 路由器
   • 本质上是 多接口主机（multihomed host），运行一个或多个 应用层网关（Application-Layer Gateway, ALG）
   • 客户端与防火墙建立连接，防火墙再代表客户端与真实服务器通信
   • IP 层转发通常被禁用，但可以隐藏内部私有网络
2. 工作方式
   • 终止 TCP/UDP 连接：
     • 防火墙终止客户端的 TCP/UDP 会话，并在应用层建立新的会话到服务器，从而实现流量检查和控制。
   • 应用层检查：
     • 根据协议类型（HTTP、FTP、SMTP 等）解析和转发流量
     • 可以检查内容、执行安全策略
   • 多接口配置：
     • 核心是代理防火墙可以多接口（多网卡）连接不同网络，内部和外部网络隔离是一种部署策略，而不是工作原理。
     • 外部接口使用全局可路由 IP
     • 内部接口使用私有 IP
     • 支持私有地址空间和内部网络隔离
3. 客户端配置
   • 客户端通常需配置为连接代理而非真实服务器
   • 支持的应用需具备 代理模式配置选项
4. 安全特性与优势
   • 能隔离内部网络，隐藏真实服务器
   • 可以根据应用层协议做精细化安全控制
   • 支持对特定协议或服务类型的流量进行过滤和转发
5. 演化与现代联系
   • 代理防火墙理念与 WAF 非常接近：
     • 反向代理、多接口主机
     • 应用层检查和流量控制
     • 内部服务保护与私有地址使用
   • 为后来 Web 应用防火墙（WAF）提供了雏形思想

总结一句话：

代理防火墙通过多接口主机和应用层网关终止连接、检查应用层流量，实现内部网络保护和协议级安全控制，是包过滤防火墙向应用层安全防护的延伸。

7.3 Network Address Translation (NAT)

1. 定义与作用
   • NAT 是一种机制，允许在 Internet 的不同部分重复使用同一组 IP 地址。
   • 核心动机：
     • IPv4 地址空间有限且逐渐枯竭
     • 路由可扩展性问题（与 CIDR 配合解决）
   • 典型使用场景：
     • 一个站点只有一个公网 IP（或少量 IP），但内部有多台计算机需要 Internet 访问。
     • 所有进出流量通过 NAT 设备，使内部私有 IP 可以访问公网。
   • 内部私有系统对外提供服务更复杂，详见 7.3.4 内部服务器 NAT 配置。
2. NAT 历史背景
   • 引入时间：1990s 初期，作为 IPv6 部署前的临时措施。
   • 优势：
     • 节约全球可路由地址
     • 提供一定的防火墙功能
     • 配置简单
   • 影响：
     • NAT 的普及在某种程度上延缓了 IPv6 的推广
     • IPv6 设计初衷是避免 NAT 的需要 [RFC4864]
3. NAT 的局限
   • 内部系统对外提供服务需要特殊配置
   • 所有连接的进出包必须通过同一个 NAT 设备，以保持映射一致性
   • 违反 Internet “smart edge, dumb middle” 原则
     • NAT 需要维护每个连接的状态（stateful）
     • 必须跨多协议层操作
     • 修改 IP 需要同时修改传输层校验和
4. 对应用协议的影响
   • 对某些协议存在问题，尤其是 在应用层负载中嵌入 IP 地址信息的协议
     • 典型协议：FTP [RFC0959]、SIP [RFC5411]
   • 解决方案：
     • 使用 应用层网关（ALG） 修改应用层内容
     • 或使用 NAT 穿透技术
   • 应用设计趋势：尽量“NAT-friendly” [RFC3235]
5. 工作原理
   • NAT 通过修改通过路由器的数据包中的标识信息实现：
     • 出方向：修改源 IP 地址为 NAT 设备的公网 IP
     • 返方向：修改目标 IP 地址为内部主机 IP
   • 对 Internet 主机而言，来自私有网络的流量显示为 NAT 的公网 IP
   • 基本形式：源地址转换（SNAT）+ 目标地址转换（DNAT）
   • NAT 设备同时隔离私有地址与 Internet，如图 7-3 所示：
     • 私有地址不会直接被 Internet 路由
     • 所有流量必须通过 NAT 翻译
6. NAT 与包过滤
   • 大多数 NAT 同时执行 包过滤，基于 NAT 状态动态决定策略
   • 例如：
     • 对未关联的入站包（非内部发起）进行处理
     • 包过滤可根据源/目的 IP 和端口做不同策略
   • NAT 的行为可能因设备不同或随时间变化而不同
   • 这对应用在不同 NAT 后面运行提出了挑战
7. 总结
   • NAT 是 IPv4 网络中私有网络访问 Internet 的核心技术
   • 它提供：
     • 地址节约
     • 内部网络隔离
     • 基本防火墙功能
   • 同时引入了：
     • 状态维护需求
     • 对某些应用协议的特殊处理需求

7.3.1 Traditional NAT: Basic NAT and NAPT

1. NAT 类型概览
   • NAT（Network Address Translation）是一种允许不同网络重复使用 IP 地址的机制，主要动机是 IPv4 地址资源有限。
   • 传统 NAT（Traditional NAT）包括：
     1. Basic NAT
        • 仅修改 IP 地址，将私有地址映射为公网地址（通常来自 ISP 提供的地址池）。
        • 缺点：
          • 无法大幅减少公网 IP 需求。
          • 内部主机同时访问 Internet 时，每台主机通常需要一个独立公网 IP。
     2. NAPT / IP Masquerading
        • 使用传输层标识符（TCP/UDP 端口或 ICMP 查询 ID）区分内部主机对应的数据包。
        • 可以让大量内部主机（数百到数千台）使用少量公网地址（甚至单个公网 IP）同时访问 Internet。
   • 在大多数场景下，“NAT”一词通常包含 Basic NAT + NAPT，除非需要特别区分。
2. 工作示意
   • Basic NAT
     • 仅修改 IP 地址，不改变端口号。
     • 每台内部主机需要一个公网 IP 来与外网通信。
   • NAPT
     • 修改 IP 地址，同时可能修改端口号以避免冲突。
     • 示例：
       • 内部主机 192.168.1.2 和 192.168.1.35 都使用同一公网 IP 203.0.113.10。
       • 若两者的源端口相同（例如都为 50000），NAT 会修改其中一个端口（例如改为 30000）以区分返回流量。
     • 这样就允许数千台内部主机共享单个公网 IP。
   • 图示参考：图 7-4（Basic NAT 左，NAPT 右）。
3. 私有地址空间
   • NAT 后面的私有网络地址由本地管理员控制，可以使用全球可路由地址，但可能与 Internet 上现有地址冲突。
   • 为避免冲突，IPv4 保留了三类私有地址空间 [RFC1918]：
     • 10.0.0.0/8
     • 172.16.0.0/12
     • 192.168.0.0/16
   • 这些私有地址常用于 DHCP 默认分配池。
4. 安全与访问控制
   • NAT 具有一定的防火墙功能：
     • 默认情况下，私有网络主机 不可从 Internet 直接访问。
     • 内部主机的所有外部通信必须经过 NAT。
   • 常见策略：
     • 内部发起的出站流量及其返回流量通常允许通过 NAT。
     • 阻止大多数新的入站连接请求，以防止扫描、攻击或未经授权访问。
   • NAPT 还可以提供 Topology Hiding：
     • 隐藏内部网络拓扑和地址数量，避免外部探测内部结构。
   • NAT 对安全而言只是附带效果，并非真正防火墙；复杂策略通常需要结合防火墙设备实现。
5. 协议相关性
   • NAT 的行为受所处理协议影响：
     • TCP：NAT 修改 IP + 端口，必须保证返回流量映射正确。
     • UDP：使用端口映射追踪请求和响应。
     • ICMP：可能使用查询 ID 做映射。
   • 某些协议在应用层报文中也包含地址/端口（如 FTP、SIP），需要 应用层网关（ALG） 支持，否则通信会失败。
   • NAT 在混合 IPv4/IPv6 环境中需要考虑：
     • IPv4 NAT 与 IPv6 地址的互通
     • NAT64/NAT46 的特殊处理
   • IETF BEHAVE 工作组（2007 起）发布规范：
     • 统一 NAT 的行为标准
     • 帮助应用程序设计者和 NAT 实现者确保互操作性
     • 包括端口分配、超时策略、协议穿透等细节。
6. 总结
   • Basic NAT 适用于每台内部主机有独立公网 IP 的场景，但公网 IP 消耗大。
   • NAPT 是实际部署中最常用的 NAT 类型，允许多台内部主机共享少量公网 IP。
   • NAT 既是地址转换机制，也是基础安全隔离手段，但对应用层协议的兼容性、端口映射和加密流量需要额外支持。
7. NAT 与 传输层关系 NAT 本质上工作在三层（IP 层），但为了让返回流量正确到达内部主机，它必须记录和管理 传输层的端口号或标识符：TCP 需要维护连接状态、区分不同会话；UDP 没有连接状态，需要靠端口和计时器维护映射；ICMP 的错误消息中可能包含原始 IP/端口信息，也需要修改才能被内部主机识别。因此，NAT 虽然改的是 IP，但传输层信息直接决定映射的唯一性和返回流量的可达性。

7.3.1.1 NAT and TCP

1. TCP 连接回顾
   • TCP 使用 IP 地址和端口号标识每一端的连接。
   • 一个 TCP 连接由两个 IP 地址 + 两个端口号唯一标识。
   • TCP 建立连接的三次握手：
     1. 客户端（active opener）发送 SYN。
     2. 服务器（passive opener）回复 SYN + ACK。
     3. 客户端回复 ACK。
   • TCP 断开连接：
     • 正常关闭：交换 FIN 包。
     • 强制关闭：发送 RST 包。
   • NAT 对 TCP 的行为参考 [RFC5382]，主要关注三次握手和会话状态管理。
2. NAT 与 TCP 建立连接示例
   • 以家庭网络为例（图 7-3）：
     • 内部无线客户端：10.0.0.126:9200
     • Web 服务器：212.110.167.157:80
     • 初始请求包： (10.0.0.126:9200; 212.110.167.157:80)
   • NAT 处理：
     1. 检测到新连接（SYN 位被置位）。
     2. 根据策略允许连接，将源 IP 修改为 NAT 外部接口的公网 IP，例如 63.204.134.177。
     3. 转发数据包： (63.204.134.177:9200; 212.110.167.157:80)
     4. 创建 NAT 会话状态（NAT mapping），记录内部 IP + 源端口。
   • 返回流量：
     • 服务器回复到 (63.204.134.177:9200)。
     • NAT 根据映射表修改目的地址： (212.110.167.157:80; 10.0.0.126:9200)。
     • 客户端收到回复，连接建立完成。
3. 会话清理与超时
   • 会话状态通常通过 FIN 包清理，但非所有 TCP 连接都能优雅关闭。
   • 异常情况（如计算机关机）可能导致 NAT 映射残留 → 需要超时清理。
   • NAT 会设置：
     • 连接建立超时：发送 SYN 后若无 ACK，删除会话状态。
     • 会话超时：收到 ACK 后，启动较长超时（例如数小时）。
     • 探测（Probing）：超时后可能向内部主机发送测试包，确认连接是否仍活跃。
     • RST 或无响应 → 删除会话。
4. TCP Keepalive 与 NAT
   • RFC5382：
     • TCP Keepalive 默认每 2 小时发送一次（可选）。
     • NAT 等待时间：
       • 已建立连接：至少 2 小时 4 分钟
       • 部分建立/关闭连接：至少 4 分钟
5. 复杂 TCP 场景
   • P2P 与同时打开（Simultaneous Open）
     • 双方几乎同时发送 SYN 包，TCP 可以完成快速连接。
     • 多数 NAT 早期实现无法正确处理。
     • RFC5382 要求：
       • 支持所有合法 TCP 报文交换，包括同时打开。
       • 对未知连接的外部 SYN，NAT 应静默丢弃。
     • 可能发生外部 SYN 到达 NAT 先于内部 SYN 的情况：
       • NAT 丢弃外部 SYN
       • 内部 SYN 建立 NAT 映射
       • 若 6 秒内未收到内部 SYN，可向外部主机报错
6. 总结
   • NAT 对 TCP 的核心作用：
     1. 改写源 IP（及必要时端口）以实现地址转换。
     2. 创建 NAT 映射以跟踪连接状态。
     3. 管理会话超时，清理死连接。
     4. 支持复杂 TCP 场景（如同时打开）。
   • 正确处理 TCP 的 NAT 对 TCP 应用的可靠性和 P2P 场景尤为重要。

7.3.1.2 NAT and UDP

1. UDP NAT 行为标准
   • 参考 [RFC4787]，定义了单播 UDP 的 NAT 行为。
   • UDP NAT 遇到的问题类似 TCP NAT，但有几个区别：
     1. UDP 没有连接建立与关闭机制（无 SYN/FIN/RST）
     2. UDP 的会话端点可能不明确
     3. UDP 不使用四元组标识连接（仅依赖两个端点的 IP + 端口）
2. NAT 状态管理
   • 使用 映射计时器（mapping timer） 清理未使用的 NAT 映射。
   • RFC4787 要求：
     • 计时器至少为 2 分钟
     • 推荐值为 5 分钟
   • 计时器刷新规则：
     • Outbound Refresh（出站刷新）：发送出 NAT 的包 → 必须刷新
     • Inbound Refresh（入站刷新）：接收入 NAT 的包 → 可刷新，可不刷新
3. 分片问题
   • UDP 和 IP 数据报可能被分片（fragmentation）
   • 非首片缺少端口号信息 → NAPT 无法正确操作
   • 同样问题也适用于 TCP 和 ICMP
   • 简单 NAT/NAPT 对分片通常处理不了

7.3.1.3 NAT and Other Transport Protocols (DCCP, SCTP)

1. DCCP (Datagram Congestion Control Protocol)
   • 提供拥塞控制的数据报服务
   • NAT 行为标准：[RFC5597]
   • 支持 TCP 式同时打开的扩展：[RFC5596]
2. SCTP (Stream Control Transmission Protocol)
   • 提供可靠消息传递，支持多地址主机
   • NAT 行为考虑参考：[HBA09], [IDSNAT]

⚠️ 总结：除了 TCP/UDP，NAT 对 DCCP 和 SCTP 也有规范，主要关注端口/IP 映射和会话状态维护。

7.3.1.4 NAT and ICMP

1. ICMP 简介
   • 详见第 8 章
   • 提供 IP 状态信息，也可用于网络测量或诊断
2. ICMP NAT 行为标准
   • 定义参考 [RFC5508]
   • 两类消息：
     1. Error messages（错误消息）
        • 通常包含导致错误的原始 IP 包的副本
        • NAT 需要修改原始 IP 地址（ICMP fix-up）才能让接收方正确识别
     2. Informational messages（信息消息）
        • 多为查询/响应或客户端/服务器交互
        • 包含 Query ID 字段 → 类似 TCP/UDP 端口
        • NAT 可识别外发请求，设置计时器以等待返回响应
3. 关键点
   • ICMP Error 消息必须重写原始数据报的 IP 地址
   • ICMP Query 消息的端口/ID 也需要映射和计时管理
   • NAT 必须正确维护这些状态，确保客户端收到可理解的响应

7.3.1.5 NAT and Tunneled Packets

1. 隧道流量与 NAT 的关系
   • 在某些场景下，隧道封装的数据包（见第 3 章）需要穿越 NAT。
   • 此时 NAT 的工作不再局限于：
     • 重写最外层 IP 头
   • 还可能需要：
     • 修改被封装的 内部协议头
     • 甚至修改 封装负载（payload）
2. 示例：GRE / PPTP
   • PPTP 使用 GRE（Generic Routing Encapsulation） 进行隧道封装。
   • GRE 头中包含 Call-ID 字段：
     • 用于区分不同的隧道会话
   • NAT 问题：
     • 不同内部主机的 GRE Call-ID 可能发生冲突
     • 也可能与 NAT 自身或其他主机的隧道冲突
   • 如果 NAT 未对 Call-ID 进行映射和重写：
     • 隧道通信将无法正常工作
3. 复杂性问题
   • 每增加一层封装：
     • NAT 需要理解更多协议格式
     • 映射和状态维护难度显著上升
   • 结论：
     • 多层隧道封装 显著增加 NAT 的实现复杂度
     • 这也是许多隧道协议对 NAT 不友好的根本原因

7.3.1.6 NAT and Multicast

1. NAT 与组播的基本情况
   • 前文讨论的 NAT 主要针对 单播（unicast）流量
   • NAT 也可以被配置为支持 组播（multicast）
     • 但在实际部署中 较为少见
2. 相关标准
   • NAT 处理组播流量的行为要求定义于：
     • RFC 5135
3. 实现方式
   • 支持组播的 NAT 通常需要：
     • 集成 IGMP Proxy
       • 参考 RFC 4605 和第 9 章
   • 行为特点：
     • 外部 → 内部 的流量：
       • 不修改目的 IP 地址和端口号
     • 内部 → 外部 的流量：
       • 源地址和端口号
       • 可按照 与单播 UDP 相同的 NAT 行为 进行修改
4. 要点总结
   • NAT 对组播的支持并非“原生”
   • 本质上是：
     • NAT + IGMP Proxy 的组合
   • 这进一步说明 NAT 的设计核心并非为组播而生

7.3.1.7 NAT and IPv6

1. 是否需要 IPv6 NAT？
   • 鉴于 IPv4 中 NAT 的广泛使用，自然会问：
     • IPv6 是否也需要 NAT？
   • 该问题在业界存在较大争议：
     • 参考 RFC 5902
2. 反对 IPv6 NAT 的主要理由
   • 许多协议设计者认为：
     • NAT 是 IPv4 时代的“必要但不理想的补丁（wart）”
     • 它显著增加了其他协议的设计复杂度
   • 在 IPv6 中：
     • 地址空间充足，不再需要通过 NAT 节省地址
     • NAT 的其他“优点”可以通过替代机制实现：
       • 防火墙功能
       • 拓扑隐藏
       • 隐私保护
3. Local Network Protection (LNP)
   • 定义于 RFC 4864
   • LNP 是一组 IPv6 技术集合：
     • 在功能上 等价或优于 NAT
     • 不引入 NAT 带来的协议复杂性
4. 地址域共存与前缀转换
   • NAT 的一个现实价值：
     • 支持多个地址域共存
     • ISP 变更时无需重编号整个网络
   • IPv6 对应机制：
     • ULA（Unique Local IPv6 Unicast Address）
       • 定义于 RFC 4193
     • NPTv6（IPv6-to-IPv6 Prefix Translation）
       • 定义于 RFC 6296
5. NPTv6 的特点
   • 使用 算法 而非 连接状态表 进行地址转换
   • 优点：
     • 不需要维护每连接状态
     • 不需要访问传输层端口号
     • TCP / UDP 校验和在转换前后保持不变
   • 结果：
     • 显著降低 NAT 的实现复杂度
     • 转换仅发生在网络层
6. NPTv6 的局限
   • 不提供防火墙或包过滤能力
   • 应用若需要感知外部地址：
     • 仍需 NAT 穿越机制
     • 或依赖 ALG
   • 实际部署中：
     • 需要配合额外的安全和访问控制机制

小结

• NAT 在隧道、组播和 IPv6 场景下的复杂性显著增加
• IPv6 设计目标之一正是避免重蹈 IPv4 NAT 的复杂性
• NPTv6 体现了“尽量不越层”的设计取向

7.3.2. Address and Port Translation Behavior

本文是对《TCP/IP Illustrated, Volume 1》中 7.3.2 Address and Port Translation Behavior 一节的整理与总结，采用读书笔记与技术博客的写作风格，重点放在 NAT 地址与端口映射行为的设计逻辑及其影响，而非逐句翻译。

一、为什么需要讨论 NAT 的映射行为

在现实网络环境中，NAT 的实现方式存在显著差异，而这些差异几乎全部集中在一个问题上：

地址和端口映射是如何建立、复用以及失效的？

不同 NAT 设备在以下方面的选择并不一致：

• 映射是否依赖外部通信对端
• 是否复用外部端口
• 是否保持内部端口不变
• 多个公网地址如何分配给内部主机

这种不一致直接导致：

• 应用行为不可预测
• NAT 穿越困难
• 不同网络环境下“同一应用表现不同”

IETF 的 BEHAVE 工作组正是基于这些问题，对 NAT 的常见行为进行归纳，并在 RFC4787 中给出了推荐与约束。7.3.2 的目的，就是为后续讨论 NAT 穿越和过滤行为奠定基础。

二、通用 NAT 映射模型

设：

• 内部主机使用私有地址和端口：X:x
• 外部通信对端为：Y:y
• NAT 在公网侧分配的地址和端口为：X′:x′

若同一个内部主机先后访问：

• Y1:y1
• Y2:y2

NAT 将建立两个映射：

• X1′:x1′
• X2′:x2′

NAT 行为的本质问题在于：

在什么条件下，X1′:x1′ 会等于 X2′:x2′？

不同的答案，定义了不同类型的 NAT。

三、三类典型的 NAT 映射行为

1. 端点无关映射（Endpoint-Independent Mapping）

在端点无关映射中：

• 只要内部源地址和端口 X:x 相同
• 无论外部访问的是哪个 Y:y
• NAT 都会复用同一个公网地址和端口 X′:x′

也就是说，映射 仅依赖内部端点，与外部通信对象无关。

这种行为的优点是：

• 外部看到的源地址和端口稳定
• 应用更容易判断自身的“公网映射”
• NAT 穿越成功率更高

因此，RFC4787 明确要求 NAT 对 TCP 和 UDP 采用端点无关映射（对 ICMP 也给出类似推荐）。

2. 地址相关映射（Address-Dependent Mapping）

在地址相关映射中：

• 如果外部目标 IP 地址相同，映射可以复用
• 如果外部目标 IP 地址不同，则使用不同的公网端口

这种 NAT 的映射依赖：

• 内部源地址和端口
• 外部 IP 地址

但不依赖外部端口。

与端点无关映射相比，这种行为会导致：

• 同一内部主机在访问不同外部主机时
• 对外呈现不同的公网端口

从而增加应用判断和 NAT 穿越的复杂度。

3. 地址和端口相关映射（Address-and-Port-Dependent Mapping）

这是最严格、也是最保守的一种 NAT 行为：

• 只有当外部 IP 和端口 完全一致时
• NAT 才会复用已有映射
• 否则就分配新的公网端口

其结果是：

• 内部主机几乎每访问一个不同服务
• 都会使用不同的公网端口

这种行为对 P2P、实时通信等场景极不友好，是 NAT 穿越中最困难的一类情况。

四、端口复用、端口保持与冲突处理

如果 NAT 为多个连接分配了相同的外部端口（x1′ == x2′），称为 映射复用。

在条件允许时，NAT 可能尝试 端口保持（Port Preservation）：

• 即外部端口号等于内部端口号

端口保持有助于兼容部分应用，但并非强制要求。当端口发生冲突、无法保持时，NAT 必须重新选择端口，并确保公网侧连接仍然可以被正确区分。

五、公网侧五元组唯一性：不可突破的底线

无论采用哪种映射策略，NAT 都必须保证：

公网侧的五元组是唯一的

即：

1

{ 源IP, 源端口, 目的IP, 目的端口, 传输层协议 }

如果 NAT 不仅复用地址，还复用端口（即所谓 端口过载）：

• 多个内部主机
• 映射到完全相同的公网五元组

那么返回流量将无法被正确解复用。这种行为在 RFC 中已被明确禁止。

六、NAT 地址池与地址配对行为

在中大型 NAT 部署中，通常会有多个公网地址可用，称为 NAT 地址池。

当同一个内部主机建立多个连接时，NAT 有两种典型策略：

• 任意分配（Arbitrary）：

  • 每次连接随机选择公网 IP

• 地址配对（Paired）：

  • 同一内部主机始终使用同一个公网 IP

RFC 推荐采用 地址配对，原因是：

• 对端更容易将多个连接视为来自同一主机
• 有利于应用层会话的一致性判断

对于只有一个公网地址的 NAT，该问题自然不存在。

七、端口奇偶保持（Port Parity）

部分 NAT 还实现了 端口奇偶保持：

• 内部端口为偶数 → 外部端口尽量为偶数
• 内部端口为奇数 → 外部端口尽量为奇数

这种行为：

• 不如端口保持严格
• 但对早期依赖端口对的协议（如 RTP）有一定帮助

RFC 将其列为 推荐但非必须 的特性，并指出其重要性会随着 NAT 穿越技术的发展而逐渐降低。

八、整体设计思想总结

7.3.2 这一节并不关注某种具体 NAT 的实现细节，而是试图明确一个整体设计取向：

NAT 的地址和端口映射，应尽量减少对外部通信端点的依赖，从而提高连接的稳定性和可预测性。

端点无关映射、地址配对、避免端口过载，都是围绕这一目标提出的具体规则。

结语

NAT 的复杂性并不来自协议本身，而是来自对“映射复用边界”的不同选择。7.3.2 通过系统化这些选择，为后续的 NAT 过滤行为和 NAT 穿越机制提供了清晰、可讨论的基础。

7.3.4. Servers behind NATs

位于 NAT 后面的主机由于使用私有、不可路由的地址，无法被 Internet 直接访问；要在 NAT 后提供对外服务，必须由 NAT 参与转发入站流量。通常的解决方式是端口转发（port forwarding），即在 NAT 上配置静态映射，将特定的公网地址和端口的流量转发到指定的内网服务器。端口转发本质上是一条永久存在的静态 NAT 映射，但它要求人工配置并随服务器地址变化而更新，同时受限于端口资源——在只有一个公网 IP 的情况下，同一传输协议的同一端口只能映射到一个内部服务器。

7.3.5. Hairpinning and NAT Loopback

略

Hairpinning（又称 NAT loopback）解决的是这样一种场景：客户端和服务器位于同一个 NAT 的私有侧，但客户端使用服务器的“公网地址+端口”来访问它。

7.3.6. NAT Editors

当应用层协议在数据负载中显式携带 IP 地址或端口信息时，普通只修改 IP 和传输层头部的 NAT 已无法正确工作，必须进一步解析并重写应用层内容，这类具备应用层修改能力的 NAT 被称为 NAT Editor。以 FTP、PPTP 等协议为代表，NAT Editor 不仅要改写报文头，还可能改变应用数据长度，从而引发 TCP 序列号和确认号的连锁调整，使实现复杂、脆弱且强依赖具体协议，这也从根本上暴露了 NAT 与端到端通信模型之间的结构性冲突。

7.3.7. Service Provider NAT (SPNAT) and Service Provider IPv6 Transition

服务提供商 NAT（SPNAT，也称 CGN/LSN）将 NAT 从用户侧前移到运营商网络，以便让大量用户共享少量甚至单个公网 IPv4 地址，从而缓解 IPv4 地址枯竭问题；在协议行为上它与传统 NAT 并无本质差异，但在规模、状态管理和控制权上显著不同。SPNAT 削弱了端到端可达性，使用户难以部署对外服务器并失去对入站流量和防火墙策略的控制，同时引发安全与应用兼容性问题。因此，SPNAT 被视为权宜之计，而通过双栈、隧道和转换等组合技术逐步过渡到 IPv6，才是恢复互联网端到端模型的长期解决方案。

7.4 NAT Traversal —— 应用如何在 NAT 环境中通信

后续三章做简要说明：这三章从应用、设备配置到互联网演进三个层面，系统性地说明了 NAT 对端到端通信模型的破坏性影响，以及现实网络如何在这一前提下勉强维持可用性并推进向 IPv6 过渡。

核心问题

NAT 会阻断来自外部的主动连接，导致位于 NAT 后的主机无法直接被访问，这对 P2P、实时通信、在线游戏等需要双向连接的应用构成根本性障碍。

主要思路

NAT Traversal 并不是绕过 NAT，而是 利用 NAT 的映射和过滤行为：

• 通过向外发送数据包，主动建立 NAT 映射
• 复用该映射来接收返回流量

典型手段

• 地址发现：获知 NAT 分配的公网地址和端口（如 STUN）
• 打洞（Hole Punching）：通信双方同时发包，在各自 NAT 上形成可用映射
• 中继（Relay）：当 NAT 行为过于严格时，通过第三方服务器转发数据（如 TURN）

小结

NAT Traversal 是应用层为弥补 NAT 破坏端到端可达性而付出的复杂代价。

7.5 Configuring Packet-Filtering Firewalls and NATs —— NAT 与防火墙的协同配置

核心问题

• NAT 会修改 IP 地址和端口
• 包过滤防火墙基于这些字段做安全决策
• 同一个数据包在不同处理阶段具有不同的“地址语义”

如果不明确 NAT 与防火墙的处理顺序，防火墙规则在逻辑上就可能完全失效。

关键原则

• 明确防火墙规则基于的是 地址转换前 还是 地址转换后 的报文
• NAT 映射与防火墙决策必须保持一致

现实解决方式

• 使用 状态化防火墙（stateful filtering）
• 将 NAT 映射与连接状态绑定（连接跟踪 / conntrack）

• 常见安全模型：

  • 允许所有出站连接
  • 允许已建立连接的返回流量
  • 默认拒绝新的入站连接

小结

NAT 与防火墙的联合配置，本质上是在地址被动态重写的前后阶段，维持一致的安全语义。

7.6 NAT for IPv4/IPv6 Coexistence and Transition —— NAT 在过渡期的角色变化

背景

• IPv4 地址耗尽
• IPv6 推进缓慢
• IPv4-only、IPv6-only 与双栈系统长期共存

主要过渡技术

• Dual Stack（双栈）：最干净，但资源和运维成本高
• 隧道（Tunneling）：用于连接不连续的网络环境
• 地址与协议转换：如 NAT64、DS-Lite、464XLAT

NAT 的角色变化

• 从用户侧的地址复用工具
• 演变为运营商网络中的过渡性基础设施（CGN / SPNAT）

代价与结论

• 进一步削弱端到端通信模型
• 用户对入站连接和安全策略的控制权下降

NAT 是 IPv4/IPv6 过渡期的工程性妥协，而非长期理想架构。

综合总结

第 7.4–7.6 章共同展示了 NAT 从一种简单的地址复用机制，逐步演变为影响应用设计、网络安全配置以及互联网演进路径的关键因素：应用被迫学习如何穿越 NAT，网络设备必须谨慎协调 NAT 与防火墙的语义，而整个互联网则在 NAT 的复杂性与原生 IPv6 端到端模型之间艰难过渡。