IETF 定义的 NAT 行为要求 (RFC 4787) — 第二部分：过滤行为
2013年9月23日 | 作者：Netmanias (tech@netmanias.com) | 汉化：ie12
由 IETF 定义的 NAT 行为要求 (RFC 4787)
在上一篇文章中我们了解了 NAT 的映射行为，下面我们将学习 RFC 4787 中定义的过滤行为。
有关下文中涉及的术语（内部端点、外部端点、出站流量、入站流量等），请参阅前一篇文章中给出的定义。
2. 过滤行为
上一篇文章讨论的是出站数据包的映射，而本文则探讨入站数据包的过滤。也就是说，上次我们讨论了 NAT 如何根据出站数据包的目的 IP 和目的端口来映射/转换其外部端口；这次我们则重点关注 NAT 在收到入站数据包时，如何依据数据包的源 IP 和源端口（如上图蓝框所示）进行过滤，并决定将其放行（Pass）至内部端点还是直接丢弃（Drop）。
端点无关过滤 (Endpoint-Independent Filtering)
在“端点无关过滤”中，所谓的“端点”是指外部端点。
“端点无关过滤”在决定是否放行外部端点发送的入站数据包时，仅检查该数据包的 1) 目标 IP 和 2) 目标端口。因此，它完全不在意外部端点的源 IP 或源端口值是什么（即任何 IP 和端口均可）。换言之在入站方向上，外部端点的信息（源 IP 和源端口）不会被作为过滤条件。
如下图所示，当主机 A 向主机 B 发送数据包时，会生成以下绑定表项和过滤表项：
- 绑定表项：{内部 IP : 内部端口} <-> {外部 IP : 外部端口} = {10.1.1.1:5000} <-> {5.5.5.1 : 1000}
- 过滤表项：如果入站数据包为 {任意 IP : 任意端口} 发往 {5.5.5.1 : 1000} 则允许放行
只要主机 B 或主机 C 发送的入站数据包的目标 IP 和目标端口为 5.5.5.1 和 1000，无论其源 IP 是什么（1.1.1.1 或 2.2.2.2），源端口是什么（80 或 8080），NAT 都会将其放行至主机 A。
地址相关过滤 (Address-Dependent Filtering)
在“地址相关过滤”中，所谓的“地址”是指外部端点的源 IP 地址。
“地址相关过滤”在决定是否放行外部端点发来的入站数据包时，仅检查该数据包的 1) 目标 IP、2) 目标端口 以及 3) 源 IP。它不在意外部端点的源端口是多少（即任意端口均可）。只有此前被内部端点作为出站目的地的那个外部端点，所发来的数据包才能被通过。
如下图所示，当主机 A 向主机 B 发送数据包时，会生成如下绑定表项和过滤表项：
- 绑定表项：{内部 IP : 内部端口} <-> {外部 IP : 外部端口} = {10.1.1.1:5000} <-> {5.5.5.1 : 1000}
- 过滤表项：如果入站数据包为 {1.1.1.1 : 任意端口} 发往 {5.5.5.1 : 1000} 则允许放行
NAT 会放行由主机 B（源 IP = 1.1.1.1）发送的入站数据包（即目标 IP/目标端口 = 5.5.5.1/1000），而丢弃由主机 C（源 IP = 2.2.2.2）发送的数据包。在此过程中，源端口号不会被作为过滤条件。
地址和端口相关过滤 (Address and Port-Dependent Filtering)
在“地址和端口相关过滤”中，“地址”和“端口”分别指的是外部端点的地址和端口（源 IP 和源端口）。
“地址和端口相关过滤”在决定是否放行外部端点发送的入站数据包时，会检查该数据包的 1) 目标 IP、2) 目标端口、3) 源 IP 以及 4) 源端口。只有作为对内部端点先前发送的出站数据包的响应数据包（即这四个值完全匹配的数据包），才会被允许放行。
如下图所示，当主机 A 向主机 B 发送数据包时，会生成如下绑定表项和过滤表项：
- 绑定表项：{内部 IP : 内部端口} <-> {外部 IP : 外部端口} = {10.1.1.1:5000} <-> {5.5.5.1 : 1000}
- 过滤表项：如果入站数据包为 {1.1.1.1 : 80} 发往 {5.5.5.1 : 1000} 则允许放行
NAT 仅会放行主机 A 此前发往主机 B 的出站数据包（即 5.5.5.1:1000 > 1.1.1.1:80）所返回的响应包（即 1.1.1.1:80 > 5.5.5.1:1000），并丢弃所有其他数据包。
RFC 4787 规范要求 (REQ-8)：若应用透明性最为关键，建议（RECOMMENDED）NAT 采用“端点无关过滤”行为。若侧重更严格的过滤策略，则建议（RECOMMENDED）NAT 采用“地址相关过滤”行为。
依据 RFC 4787 的规定，采用“端点无关过滤”或“地址相关过滤”的 NAT，可以通过交互式连接建立机制（ICE，RFC 5245）实现点对点（P2P）通信。然而，对于同时采用“地址和端口相关映射”与“地址和端口相关过滤”的 NAT 来说，点对点直连是无法实现的。因为所有流量都不可避免地需要通过中继服务器（TURN 服务器）进行转发。
3. 回流行为 (Hairpinning Behavior)
回流（Hairpinning）机制允许位于同一个 NAT 后面的两个内部端点通过该 NAT 互相通信。Skype 就是其中最典型的应用例子。使用这类应用时，两台移动设备可以通过 3G/LTE 网络中部署的大规模 NAT（LSN，也称运营商级 NAT/CGN）直接进行通信。
回流行为主要分为以下两种类型：
外部源 IP 与端口 (External Source IP Address and Port)
设想以下由主机 A 发往主机 B（并被 NAT 接收）的数据包：
- 目标 IP = 主机 B 的外部地址 (5.5.5.2)
- 目标端口 = 主机 B 的外部端口 (1001)
- 源 IP = 主机 A 的内部地址 (10.1.1.1)
- 源端口 = 主机 A 的内部端口 (5000)
当 NAT 收到该数据包后，会通过查阅绑定表对其进行如下修改，然随后转发给主机 B。此处值得注意的是，修改后的源 IP 与源端口已替换为主机 A 的外部地址与外部端口：
- 目标 IP = 主机 B 的内部地址 (10.1.1.2)
- 目标端口 = 主机 B 的内部端口 (5001)
- 源 IP = 主机 A 的外部地址 (5.5.5.1)
- 源端口 = 主机 A 的外部端口 (1000)
上述情况可以被视为一种理想的 NAT 行为，因为主机 A（发送方）收到的响应数据包（源 IP/端口 = 5.5.5.2/1001）正是来自其先前发送数据包的目标 IP/端口 (5.5.5.2/1001)。因此，两者之间的通信没有任何问题。
需要补充的是，尽管在下图中主机 A 和主机 B 拥有不同的外部地址（5.5.5.1 和 5.5.5.2），但根据 NAT 实现的不同，它们也可能映射为相同的外部地址。
内部源 IP 与端口 (Internal Source IP Address and Port)
同样地，再次假设主机 A 发送给主机 B（并由 NAT 接收）一个相同的数据包。
当 NAT 收到该数据包后，会通过查阅绑定表对其进行如下修改，然后转发给主机 B。与之前情况不同的是，此时数据包的源 IP 和源端口保留了主机 A 的内部地址与内部端口：
- 目标 IP = 主机 B 的内部地址 (10.1.1.2)
- 目标端口 = 主机 B 的内部端口 (5001)
- 源 IP = 主机 A 的内部地址 (10.1.1.1)
- 源端口 = 主机 A 的内部端口 (5000)
在这种情况下，主机 A（发送方）收到的响应数据包（源 IP/端口 = 10.1.1.2/5001），与其先前发包时的目的 IP/端口 (5.5.5.2:1001) 不一致。因此，该数据包会在内核的 TCP/IP 协议栈中直接被丢弃。
RFC 4787 规范要求 (REQ-9)：NAT 必须（MUST）支持“回流（Hairpinning）”。
a) NAT 的回流行为必须（MUST）为“外部源 IP 地址和端口”。