目录
1.防火墙如何处理双通道协议?
2.防火墙如何处理NAT?
3.防火墙支持哪些NAT技术,主要应用的场景是什么?
4.当内网PC通过公网域名解析访问内网服务器的时候,会存在什么问题,如何解决?请详细说明
5.防火墙使用VRRP实现双机热备会遇到什么问题,如何解决?请详细说明
6.防火墙支持哪些接口模式,一般使用在哪些场景?
7.NAT实验
8.双机热备实验
FTP协议原理图
FTP是一个典型的多通道协议,在主动模式客户端向服务端的TCP的21号端口发起三次握手,建立控制连接,客户端通过FTP PORT命令通知服务端自己的随机端口为P,由服务端向客户端的TCP PORT P 发起三次握手,建立传输连接其中服务端的源端口为20.
在被动模式下,客户端向服务端的TCP 的21端口发起三次握手,建立控制连接,客户端向服务端发送PASV命令,服务端通过Enter PASV命令告知客户端自己的随机端口为M,由客户端向服务端的TCP PORT M发起三次握手,建立传输连接。
安全策略存在的问题:对于类似于FTP这种双通道协议,由于其中端口的随机性,导致无法书写安全策略的参数,假如对于端口参数选择any,会使得颗粒度较大,以至于让防火墙失去效果。
ASPF(Application Specific Packet Filter,针对应用层的包过滤)也叫基于状态的报文过滤,ASPF功能可以自动检测某些报文的应用层信息(可以理解为在双方建立传输通道之前协商端口的报文)并根据应用层信息放开相应的访问规则,开启ASPF功能后,FW通过检测协商报文的应用层携带的地址和端口信息,自动生成相应的Server-map表,用于放行后续建立数据通道的报文,相当于自动创建了一条精细的“安全策略”。
dis firewall server-map //查看server-map表
2023-03-18 06:47:53.330
Current Total Server-map : 1
Type: ASPF, 10.1.1.3 -> 100.1.1.2:2054, Zone:---
Protocol: tcp(Appro: ftp-data), Left-Time:00:00:13
Vpn: public -> public
dis firewall session table //查看会话表
2023-03-18 06:47:57.650
Current Total Sessions : 14
ftp VPN: public --> public 10.1.1.3:2059 +-> 100.1.1.2:21
ftp VPN: public --> public 10.1.1.3:2065 +-> 100.1.1.2:21
ftp VPN: public --> public 10.1.1.3:2049 --> 100.1.1.2:21
ftp VPN: public --> public 10.1.1.3:2063 +-> 100.1.1.2:21
ftp-data VPN: public --> public 10.1.1.3:2066 --> 100.1.1.2:2054
在路由器上NAT针对多通道协议也会像防火墙那样抓取控制进程中协商传输进程网络参数的报文,进而生成传输进程返回的NAT映射(在NAT中的主要参数是IP)。
困境
某些协议会在应用层携带通信ip,这个ip用于下一阶段通信。但是NAT的地址转换并不是转应用层IP而是转三层IP,这就导致某些协议的通信阶段在NAT场景下失败。
这也是导致交换机一般没有nat的主要原因。(由于NAT需要抓取控制进程的特殊报文来进行分析,从而计算出后续传输进程所需要的网络参数,并且在发送端和接受端以及NAT后的数据需要进行校验计算,会消耗大量的计算资源,对于设备的内存和CPU是一个很大的考验。由于交换机是通过硬件芯片工作的,本身计算资源有限,无法完成NAT的强大计算量,这也就是一般交换机没有NAT的主要原因)
防火墙nat类型的server-map
dis firewall server-map
2023-03-18 08:07:54.050
Current Total Server-map : 1
Type: Nat Server, ANY -> 100.1.1.111:80[10.1.2.2:80], Zone: untrust , protoc
ol:tcp
Vpn: public -> public
源NAT
场景:主要应用在内网用户没有外网服务的路由时,在内网用户想要访问外网的某台服务器时,发送的数据包的源IP为自己的私网IP,目的IP为服务器的公网IP,在通过边界路由器或者防火墙时,需要将自己的私网IP转换成公有IP去访问。服务端回包时的源IP为自己的公有IP,目的IP为私网用户的公有IP。
server-nat
场景:私网服务器需要对外网用户提供服务时;在网络中无法访问一个私网的用户,当服务器处于私网内部时,外部人员无法访问;此时,就需要将内网服务器的IP和服务通过server-nat映射到私网边界的路由器或者防火墙的公网IP。让外网人员通过访问边界设备的公有IP来达到访问内网服务器的目的。
域间双向转换
场景:假设内网服务器只允许内网用户访问,但是由于某种特殊要求,现在需要外网用户对内网服务器也发起访问,就需要在访问的时候将源目IP都进行NAT。
域内双向转换
场景:假设内网有一台服务器,在内网用户想要去访问的时候,一般先去DNS服务器解析出服务器的IP地址,在服务映射的情况下,向外提供的是公网IP,所以在内网用户访问的时候也是使用公网IP访问,就需要在做域内双向转换。
双出口nat
场景:某个企业使用两条运营商的宽带;需要将属于某个运营商的网段进行nat然后与该运营商的下一跳进行关联,就不会出现nat转换错乱的问题。
场景:私网内部有一台服务器提供服务(192.168.56.63),现私网内部人员(192.168.1.15)通过DNS解析出来的地址去访问私网服务器,由于DNS解析出的地址为公有IP(14.2.23.5);
转换前数据包格式:
源IP:192.168.1.15 目IP:14.2.23.5
如果只是在简单的server-nat下,只会转换目的IP
转换后数据包格式:
源IP:192.168.1.15 目IP:192.168.56.63
在服务端回包时,会按照转换后的数据包进行回包,但接收方(客户端)收到的报文格式与本端发送时不一致,就回丢弃该报文,导致双方通信失败。
解决方法:域间双向nat
转换前数据包格式:
源IP:192.168.1.15 目IP:14.2.23.5
转换后数据包格式:
源IP:14.2.23.6(公网池地址) 目IP:192.168.56.63
发包和收包报文格式一致,双方正常通讯。
出现的问题:假设上面的防火墙为PC1的主网关,下面为备网关。当PC的数据流来到上面的防火墙时,查询会话表,未果后查询策略表,若命中创建会话表,后续报文基于会话表转发。但是当主网关左侧线路断掉的话,因为VRRP的存在会将PC 的网关切换到下面的一台防火墙,但是由于下面一台防火墙没有会话表,又没有首包可以创建,故导致数据转发失败。由于数据包一般要求来回路径一致,回包此时发往上面的防火墙,也会导致数据转发失败。
解决办法:使用VGMP进行统一管理,防火墙两侧线路状态需要一致。
VGMP-------统一组管理协议,将VRRP组进行统一管理,在开启抢占的时候统一由VGMP进行管理,看是否需要切换。
在主备防火墙之间使用线路连接,俗称“心跳线”,负责主备网关之间的配置同步(包括会话表,安全策略,路由情况等)
- 路由模式 --- 以第三层对外连接(接口具有IP 地址)
- 交换模式 --- 通过第二层对外连接(接口无IP 地址)
- 旁路模式 --- 该接口一般用于接收镜像流量,向主机一样旁观在设备上。通过旁观设备的端口镜像技术收集流量给旁路接口,这个场景防火墙可以做IPS,审计,流量分析等任务。
- 接口对模式 --- 加快接口的转发效率(不需要查看MAC地址表)
1.源nat
抓包分析:
使用trust区的10.1.1.2去访问untrust的100.1.1.22.server-nat
测试:
通过访问公网100.1.1.11映射到内网服务器3.域内双向nat
映射内网服务器抓包分析:
转换后的数据包4.域间双向nat
抓包分析:
转化后数据包创建心跳接口----端口聚合
配置主防火墙
查看当前状态
备防火墙
查看备防火墙的同步配置
与主防火墙配置一致
双机热备测试
关闭主防火墙的1/0/0口进行测试,在备防火墙的接口上抓包,观察有流量通过