[toc]
一、 实验目的:
内网PC 192.168.10.2,由于工作需要,要使用公网地址200.1.1.2来访问处于内网的服务器192.168.10.1
二、 拓扑:
三、 防火墙配置
四、 数据抓包
五、 查看会话表与Server-MAP
六、安全策略分析
七、通讯过程分析与思考
1 数据包通讯过程: 发送包: 192.168.10.2:38400 --> 200.1.1.2: 23 转换成 200.1.1.3:2048 --> 192.168.10.1:23 回包: 192.168.10.1:23 --> 200.1.1.3:2048 转换成 200.1.1.2:23 --> 192.168.10.2:38400
2 防火墙会话表:
dis firewall session table Telnet VPN: public --> public 192.168.10.2:38400[200.1.1.3:2048] --> 200.1.1.2:23[192.168.10.1:23]
3 防火墙Server-map
Type: Nat Server, ANY -> 200.1.1.2:23[192.168.10.1:23], Zone:---, protocol:tcp Vpn: public -> public
4 一次telnet的通信过程分析
- 内网用户192.168.10.2,访问200.1.1.2:23,数据包到达防火墙
- 防火墙根据转发流程,进行状态检测,查找发现是首包,先匹配了Server-map,所以将目的地址转换成了:192.168.10.1:23
- 防火墙继续转发,查找路由表,发现192.168.10.1是Trust区域,所以数据包将发送给Trust区域
- 接着检查安全策略,由于数据源是Trust区域,目的也是Trust区域,不受安全策略控制
- 再检查源NAT策略,源NAT策略中:源是Trust区域,目的是Trust区域的192.168.10.1:23,需要进行源NAT转换
- 防火墙创建会话
- 在转发的第三个阶段,进行源地址转换,数据包被转换成:200.1.1.3:2048 --> 192.168.10.1: 23
- 防火墙将数据包,送往trust区域的g1/0/0接口
- Telnet服务器(192.168.10.1)收到这个数据包,进行回应,回应的地址为: 192.168.10.1:23 --> 200.1.1.3:2048
- 防火墙根据会话表,还原数据包为 200.1.1.2:23 --> 192.168.10.2:38400 (这一步,是猜测的,因为数据包的交换是在Trust区域到Trust区域的同一个接口,如果将它想像成,Trust--untrust之间的通信,就好理解了。虽然抓包显示一次通信过程有4个包,其实只是防火墙将数据进行了源目地址的重新封装,每两个包里面的内容是一样的。)
八、 不做双向NAT,只做了NAT-Server,内网用户用公网地址200.1.1.2:23访问处于内网的服务器会发生什么情况?
- 192.168.10.2:38048 --> 200.1.1.2:23
- 防火墙收到数据包,根据会话表
telnet VPN: public --> public 192.168.10.2:38408 --> 200.1.1.2:23[192.168.10.1:23] - 将数据包转换为: 192.168.10.2:38048 --> 192.168.10.1:23 ,并从Trust端口g1/0/0发送出去 【SYN包】
- Telnet服务器收到数据包后,回应: 192.168.10.1:23 --> 192.168.10.2:38048 【SYN+ACK】
- 发起访问的客户端192.168.10.2收到这个数据包,会回应一个【RST】,从而三次握手失败。 在这一步,因为客户端没有发起一个到达192.168.10.1:23的访问,所以它拒绝了192.168.10.2:23的连接请求,会将TCP三次握手中断,从而导致通讯失败。
- 接着开始新一轮的数据包重传。
九、 不做Nat-Server, 只做了去往192.168.10.1:23,做源地址转换。内网用户用公网地址访问200.1.1.2:23,会是什么情况
- 客户端192.168.10.2:38049 --> 200.1.1.2:23
- 在防火墙上的流量日志显示: trust: 192.168.10.2 --> untrust 200.1.1.2 :23,但防火墙没有将这个数据包从公网地址转发出去,也没有进行回应。
- 客户端由于收不到回应,进行TCP重传
十、应用场景
- 公司网络中的内网服务器,因为接口等原因只支持公网地址访问