NAT Server 与目的Nat

目的NAT：数据到达NAT设备之后，更换IP头部的目的地址，用的比较多的是NAT Server

产生背景

Server Map 类型	是否需要经过安全策略检查？
ASPF（动态通道）	不需要（直接放行）
NAT Server（静态端口映射）	需要
NAT No-PAT（一对一 IP 映射）	需要

三种 Server Map 表的"反向"区别

特性	NAT Server	NAT No-PAT	ASPF
产生时机	静态：配置完成后立即生成，永久存在。	动态：内网主机首次访问外网触发后生成，有老化时间。	动态：在多通道协议（如FTP）协商过程中动态生成。
"反向"表的作用	为"出"服务：允许内网服务器主动访问外网时，直接使用表项进行源地址转换，无需额外的源NAT策略。	为"入"开门：在表项有效期内，允许外网主机使用相同的五元组信息主动访问内网主机。	为"回"放行：为已通过安全策略的会话，开辟一条临时的数据通道，临时允许外部主机向内网发起连接
表项内容	正向：`Any -> 公网IP:端口 [内网IP:端口]` 反向：`内网IP [公网IP] -> Any`	正向：`内网IP:端口 <-> 公网IP:端口` 反向：`外网主机:端口 <-> 内网IP:端口`	单向动态：`外网服务器IP:端口 <-> 内网客户端IP:动态端口`
本质目的	双向地址转换蓝图，打通出入通道，简化配置。	动态地址映射快照，加速回包转换，并临时允许反向访问。	临时通道许可证，解决特定协议的兼容性问题。

❓ 为什么NAT Server会产生"反向"的Server Map？

NAT Server 产生反向表，主要是为了 简化配置，让内网服务器访问外网更便捷。

NAT Server 本身就是为了让外部能够访问内部而设计的，但它也考虑到了内网（Trust）区域的这台服务器本身可能也有访问外网（Untrust）的需求。如果没这张反向表，就需要额外再为这台服务器配置一个源 NAT（NAT Outbound）策略。而反向表默认被创建，使得内部服务器访问外部时，能直接匹配它来进行源地址转换：

bash 复制代码

Nat Server Reverse, 10.1.1.2[1.1.1.1] -> any

这意味着，仅通过一条 nat server 命令，防火墙就为服务器"出入"两个方向都打通了地址转换通道，简化了管理员的配置工作量。

当然，如果你不想要这个行为（比如希望强制服务器所有对外访问也必须通过严格的源NAT策略来管控），可以在配置 nat server 命令时，加上 no-reverse 参数来禁止生成反向表。

❓ 为什么ASPF不会产生"反向"的Server Map？

ASPF 不产生反向表，最核心的原因是：压根不需要，因为会话表（Session Table）已经完成了这个工作。

对于FTP这类多通道协议，ASPF的工作流程是：

建立控制通道 ：内网客户端访问外网FTP服务器，通过安全策略检查，建立控制通道，并生成会话表（Session Table）。

协商数据通道：服务器通过控制通道告知客户端即将使用的数据通道端口。

创建动态通道：ASPF 捕获到这个端口信息，动态生成一个临时的 Server Map 表。

这个临时表的作用是告诉防火墙："稍后会有一个从外网发起的连接，它的目的地址和端口是X，这是合法的，直接进来吧。"（这就是你理解的"反向"）

数据通信 ：当服务器向客户端发起数据通道连接时，由于它匹配了ASPF生成的Server Map，报文被允许通过。防火墙会根据这个报文，为这条临时的数据通道也创建一个会话表（Session Table）。

一旦这个数据通道的会话表建立，服务器的后续回包就能直接匹配这个会话表进行转发，ASPF Server Map 的临时使命就完成了。

因此，ASPF 产生的临时 Server Map 不是为了创建一个"永久反向通道"，而是作为"敲门砖"，用来触发建立一条新会话。它的生命周期极短，不像NAT Server那样需要常驻来为两个方向服务。

**************************************************************************************************************

有关server map表跟session表的一些思考总结

场景	第一个包（首包）	后续包（同一连接）	长期/新连接
NAT Server	匹配 Server Map（静态）	匹配 Session 表	新连接再次匹配 Server Map
ASPF	匹配 Server Map（动态临时）	匹配 Session 表	新连接（如另一个数据通道）再次匹配新的 Server Map

关键点 ：无论哪种 Server Map，一旦首包创建了会话（Session），后续所有属于该连接的报文都会直接走 Session 表，不会再查 Server Map。

Session 表完全能够支撑双向流量的来回传递，这正是状态化防火墙的核心能力。

1️⃣ NAT Server：首包走 Server Map，后续走 Session

场景：外网用户 1.2.3.4:12345 访问 203.0.113.2:80（映射到 10.0.0.1:80）

首包到达防火墙（TCP SYN）：

防火墙查找会话表 → 未命中（因为这是一个新连接）。

查找 Server Map → 命中静态 NAT Server 表项：203.0.113.2:80 → 10.0.0.1:80。

执行 DNAT（目的地址转换）：目的 IP 改为 10.0.0.1，目的端口保持 80。

检查安全策略（允许通过后）。

创建会话表项，记录这个连接的五元组及转换信息。

转发报文。

后续同连接的报文（同一个 TCP 连接，比如后续的 SYN-ACK、ACK、数据包）：

防火墙查找会话表 → 命中（因为已经有了该连接的会话）。

直接使用会话表中的转换信息，不再查找 Server Map。

转发。

为什么不能一直走 Server Map？

Server Map 是静态的、无状态的。它只告诉防火墙"如何转换地址"，但不知道这个连接是否已经建立、处于什么状态。会话表则维护了连接的状态（如 TCP 序列号、老化时间等），并且查找速度极快。如果每个包都查 Server Map，不仅效率低，而且无法实现状态跟踪（比如 TCP 攻击防御、连接老化等）。

2️⃣ ASPF：首包（数据通道）走临时 Server Map，后续走 Session

场景：内网客户端经过 FTP 控制通道协商后，外网服务器主动发起数据通道连接（从服务器 20 端口到客户端某个高位端口）

控制通道已经建立，会话表里有控制通道的会话。
数据通道的第一个报文（外网服务器 → 内网客户端，TCP SYN，源端口 20，目的端口 34567）：

防火墙查找会话表 → 未命中（因为这是一个新的连接，目的端口 34567 不是平时允许的）。

查找 Server Map → 命中 ASPF 动态生成的临时表项（该表项是在控制通道协商时由 ASPF 提前创建的，记录了允许这个数据通道的五元组）。

由于该 Server Map 自带"放行"属性（绕过安全策略检查）。

立即为该数据通道创建会话表项。

转发报文。

此后该数据通道的所有后续报文（同一连接的后续包）：

查找会话表 → 命中。

走会话表，不再查 Server Map。

临时 Server Map 的命运：在创建会话表后，ASPF Server Map 可能很快被删除（或者保留很短的老化时间）。因为它已经完成了"开门"的使命，后续全部由会话表接管。

Session 表里必须同时存储正向和反向两条信息，否则防火墙根本不知道如何处理回程报文。

Session 表里到底有什么？

一个典型的 Session 表项（以 NAPT 为例，内网 192.168.1.100:12345 访问 8.8.8.8:80，防火墙出接口 IP 为 203.0.113.2）：

方向	原始源 IP:端口	原始目的 IP:端口	转换后源 IP:端口	转换后目的 IP:端口
正向（内→外）	`192.168.1.100:12345`	`8.8.8.8:80`	`203.0.113.2:56789`	`8.8.8.8:80`
反向（外→内）	`8.8.8.8:80`	`203.0.113.2:56789`	`8.8.8.8:80`	`192.168.1.100:12345`