1,首先回顾一下协议:
TCP数据包中有六个标志位(Code Bits):6
位标志域。表示为:紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是:URG、ACK、PSH、
RST、SYN、FIN。在整个TCP数据传输过程中ACK位除了在第一次握手的时候置位为0外,其他任何时候都置位为1。
三次握手过程:
在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。
第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器 进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入 ESTABLISHED状态,完成三次握手。
2,再次拿一个来举例说明(摘自TCP/IP路由技术 第一卷 第556页):
假设你实现了一个访问列表可以阻止外部发起的TCP会话进入到你的网络中,但是你又想让内部发起的TCP会话的响应通过,那应该怎么办?通过检查TCP段
头内的ACK和RST标记,关键字established可以实现这一点。如果这两个标记都没有被设置,表明源点正在向目标建立TCP连接,那么匹配不会
发生。最终报文将会在访问列表中的后继行中被拒绝。示例如下:
access-list 110 permit tcp any 172.22.0.0 0.0.255.255 established
access-list 110 permit tcp any host 172.22.15.83 eq 25
access-list 110 permit tcp 10.0.0.0 0.255.255.255 172.22.114.0 0.0.255 eq 23
第1行:如果链接是从网络172.22.0.0发起的,那么允许从热和原电到该网络的TCP报文通过;
第2行:允许来自任意源点,且目标端口号是主机172.22.16.83的端口25的TCP报文通过;
第3行:允许来自网络10.0.0.0,去向网络172.22.114.0/24且目标端口为23的TCP报文通过。
通过上面的ACL,大家有没有注意过,一个从any到172.22.15.83的25端口的连接,TCP的三次握手,第一次握手肯定是需要匹配第2行
ACL,因为此报文的标志位ACK置位为0,不能匹配第1行ACL。但是此会话的后面的所有数据报文都会匹配第1行了,因为此报文的标志ACK已经置位为
1了。这里是否有问题,请相关牛人鉴定!
3,ACL对分片包的处理(摘自一英文技术宝典,经我翻译如下):
当一IP包被分片时,仅在第一个分片中包含所有三层与四层信息,而后续分片则只包含三层信息,四层信息丢失。
ACL的处理机制:
对于permit ACEs:当第一分片被匹配上后,后续分片也会匹配上(不检查四层信息);
对于deny ACEs:所有分片都要检查三、四层信息。实际上,对于deny
ACEs,当第一分片被匹配上后被丢弃,而后续分片由于无四层信息则不能匹配该deny
ACEs,可能在后面检查时允许通过,则传到目标地后,由于不能进行重组而被丢弃。但这样占用了带宽及目标主机的CPU。
综合以上,根据3,是否可以判定ACL的处理机制有点smart,它可以根据每条ACE条目记录某一个时段的匹配内容,匹配内容主要包括源和目标IP地
址,甚至端口号(tcp条目),从而不会将流量报文匹配错。也就是说根据2说的同一会话的后续报文不会去匹配第1行ACL,而根据ACL的记录内容去匹配
第2行ACL。
阅读(1049) | 评论(0) | 转发(0) |