Network Manage Tech Experience

Welcome to my tech home !!!
posts - 32, comments - 35, trackbacks - 0, articles - 0
  IT博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

怎么使用ACL的established?

Posted on 2008-05-22 21:52 chris_lee 阅读(2166) 评论(0)  编辑 收藏 引用 所属分类: CISCO技术篇

1,首先回顾一下TCP协议:

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,再次拿一个ACL来举例说明(摘自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。

以上纯粹是我个人针对ACL的分析,有任何不对或者有争议之处,还请牛人指正,不胜感激!!!

只有注册用户登录后才能发表评论。