这次实验把一条完整的访问链路搭起来：外部访问流量先进入防火墙，经由策略放行和目的 NAT 转发后，再交给 WAF 进行应用层处理，最后由 WAF 转发到后端 Web 服务器。这样一套结构虽然规模不大，但已经具备了比较典型的边界防护 + 应用层防护 + 后端业务主机思路。
一、搭建思路
整个实验的访问逻辑可以概括成一句话：
外部主机访问防火墙的 WAN 口地址，防火墙根据目的 NAT 把 HTTP 请求转发给 WAF，WAF 再把请求代理到后端 Web 服务器。
这样做有几个明显好处：
第一，后端服务器不直接暴露在外网。
第二，防火墙负责网络层入口控制，WAF 负责应用层的攻击检测。
第三，出了问题时，比较容易定位到底是路由问题、策略问题、NAT 问题，还是 WAF 站点配置问题。
二、奇安信 NGFW 配置说明
NGFW 是这套实验里的第一道入口。它主要承担以下几项工作：定义内部网段，指定内外网通信的下一跳。给内网主机分配地址，将外部访问请求通过目的NAT转发给 WAF，通过安全策略允许对应流量通过
1. 配置地址对象
在防火墙上，我先定义了一个地址对象 SUBNET，对应网段为：192.168.10.0/24
这个网段在本实验中承担的是内网业务侧网络的角色，WAF 和部分后端相关节点都在这个范围里。
从配置逻辑来看，这一步属于先把网络身份定义清楚。后面在配置的的时候直接输入IP貌似无法加入/或者空格，我没成功写入子网掩码。
2. 配置静态路由
接着我配置了一条默认静态路由，目的地址/掩码为：
0.0.0.0/0
出接口选择 ge2，下一跳设置为：172.16.11.254
默认路由的作用，是告诉防火墙：凡是不知道更精确去向的流量，就统一从 ge2 口往这个网关转发。
ge2 承担的是外网方向接口，所以这条默认路由本质上就是让防火墙具备向外找路的能力。没有这一条，容易出现访问异常或者页面长时间无响应。
3. 配置 LAN 口 DHCP
在内网侧，启用ge3接口上的DHCP 服务.
ge3 是本实验中的LAN(trust)口，同时也是内网网段的网关。
4. 配置目的 NAT
为了让外部流量能够访问到内部的 WAF，在防火墙上配置一条目的 NAT
这条规则的核心逻辑是：
当外部流量从 ge2 口进入，目标访问的是 172.16.11.92 的 HTTP 服务时，防火墙把它改写并转发到 192.168.10.101:80。
源地址写 any
表示只要满足其他匹配条件，任何来源的客户端都可以命中这条 NAT。实验环境里这样写比较方便，因为便于从不同测试主机发起访问。
目的地址写 172.16.11.92
这通常就是外部用户眼里看到的“被访问地址”，可以理解为防火墙外网侧承接业务的地址。
转换后地址写 192.168.10.101
这个地址就是 WAF 在内网侧的地址。也就是说，防火墙并不是直接把流量送给后端 Web，而是先交给 WAF。
外部请求先到防火墙，再到 WAF，最后才到真实业务主机。
5. 配置安全策略
NAT 配好了以后，还必须配置对应安全策略，否则报文在策略检查阶段就会被丢弃。
这条策略表达得很直接：
允许来自外部不可信区域的 HTTP 访问流量，进入内部 trust 区域中的 SUBNET 网段。
为什么这里是 untrust -> trust？
因为防火墙做安全域划分时，外部网络属于不信任区域，内部网络属于信任区域，目的地址是设置过的SUBNET
勾选记录日志非常重要。如果访问失败，可以去看策略日志，确认有没有命中这条规则；如果后面做攻击测试，也可以观察哪些流量被允许、哪些流量触发告警。很多企业一旦不记日志，后期排障会非常难受，勾上是个好习惯。
到这里，NGFW 这一侧的链路逻辑就完整了：
有网段定义
有出方向路由
有内网 DHCP
有外部到 WAF 的目的 NAT
有外部到内网的放行策
也就是说，防火墙层面已经具备把外部 HTTP 流量送进内网 WAF 的能力。
三、山石网科 WAF 配置说明
创建站点防护配置
站点状态：防护
请求经过 WAF 时，会进入规则检测和处理流程。
虚拟路由器：trust-vr
这通常表示该站点绑定在 WAF 当前所使用的业务路由实例上，保证它能正确找到前端监听地址和后端服务器。
服务地址：192.168.10.101:80
这里的192.168.10.101实际上就是 WAF 用来承接业务流量的地址，也和前面防火墙目的 NAT 的转换后地址保持一致。
防火墙把流量 NAT 到 192.168.10.101:80，WAF 在这个地址上接收 HTTP 请求
域：172.16.11.92
这一项可以理解为该站点对外提供服务时对应的访问标识。在实验环境里，它和防火墙外部可访问地址形成对应关系。这样配置后，整条访问路径就统一起来了。
从工作逻辑上看，这一步的本质，是在 WAF 上创建一个前端接入点。
配置负载均衡与回源服务器
在my_web这个站点下，继续配置负载均衡参数。
这个配置其实是在告诉 WAF：
当前站点接收到的请求，最终需要转发给后端的 192.168.10.100:80。
这个前后端分离关系很重要，很多人第一次搭 WAF 时容易把这两个地址混淆。
后端 Web 服务器部署在内网业务网段中，WAF 与它处于可达状态。WAF 的职责不是自己提供页面，而是把合法请求代理并转发给真正的业务主机。
IP Hash的特点是：
同一个来源 IP 的请求，尽量固定落到同一台后端服务器上，当前只有一台后端时，它更多体现的是配置思路上的完整性。
因为目前只有一个后端节点，所以权重写 1 就够了。
四、整条访问链路是怎么工作的
结合前面的配置，整个访问过程可以这样理解：
第一步：客户端发起访问
外部测试主机访问防火墙外网侧地址 172.16.11.92 的 HTTP 服务。
第二步：防火墙做目的 NAT
NGFW 检查到这是一条从 ge2 进入、目的地址为 172.16.11.92、服务为 HTTP 的流量，于是命中目的 NAT 规则，把数据改写为发往：
192.168.10.101:80
第三步：安全策略放行
同时，这条流量还需要命中 WAF_Access 安全策略，也就是从 untrust 到 trust 的 HTTP 放行规则。命中之后才会被正式转发。
第四步：WAF 接收并处理请求
WAF 在 192.168.10.101:80 这个前端服务地址接收请求，并根据 my_web 站点配置对其进行应用层处理。
第五步：WAF 回源到后端 Web
站点配置中指定的后端服务器是 192.168.10.100:80，因此 WAF 会把请求进一步转发到真实 Web 服务器。
第六步：响应再返回客户端
后端服务器返回页面，响应经由 WAF 返回，再由防火墙回送给外部客户端，完成整个访问闭环。
所以这条链路可以压缩成一句话：
客户端 → NGFW（策略/NAT）→ WAF（代理/防护）→ Web Server
至此已经是一条完整可解释的访问链。
效果展示:
Comments NOTHING