ACL学习：自反访问列表引入和配置

三台路由器串联，要求阻止R3对R1的远程访问（telnet），但只能在R2上做。R1可以对R3进行telnet登陆。

　1 底层配置

　　R1

　　interface Serial2/1

　　p address 12.0.0.1 255.255.255.0

　　router eigrp 90

　　network 12.0.0.0 0.0.0.255

　　o auto-summary

　　R2

　　interface Serial2/1

　　p address 12.0.0.2 255.255.255.0

　　interface Serial2/2

　　p address 23.0.0.2 255.255.255.0

　　router eigrp 90

　　network 0.0.0.0

　　o auto-summary

　　R3

　　interface Serial2/1

　　p address 23.0.0.3 255.255.255.0

　　router eigrp 90

　　network 23.0.0.0 0.0.0.255

　　o auto-summary

　　2 在R2上做ACL 拒绝R3对R1的所有TCP连接，但不能影响R1对R3的telnet

　　在这里我们先用扩展访问列表做一下，看能不能实现。

　　r2(config)#access-list 100 deny tcp host 23.0.0.3 host 12.0.0.1

　　r2(config)#access-list 100 permit ip any any

　　r2(config)#int s2/2

　　r2(config-if)#ip access-group 100 in / 将ACL应用到接口

　　为了验证将R1和R3的VTY线路配置成直接登陆，无需密码。

　　r1(config)#line vty 0 4

　　r1(config-line)#no login

　　r3(config)#line vty 0 4

　　r3(config-line)#no login

　　现在进行验证。

　　r3#telnet 12.0.0.1

　　Trying 12.0.0.1 ...

　　 Destination unreachable; gateway or host down

　　在R3上无法telnetR1，访问列表起了作用。我们再去R1做一下验证。

　　r1#telnet 23.0.0.3

　　Trying 23.0.0.3 ...

　　 Connection timed out; remote host not responding

　　这时，R1也无法telnet R3 这可不是我们所希望的结果。那为什么会产生这种结果呢？这是因为R1向R3发起telnet请求时，是R1的一个随机端口与R3的23号端口通信。R3收到这个请求后，再用自己的23号端口向R1的随即端口回应。在这个例子中，R1向R3的请求，R3可以收到。但当R3向R1回应时，却被R2上的ACL阻止了。因为R2的ACL的作用是阻止R3向R1的所有TCP连接。这个TCP回应也就被阻止掉了，所以就间接的造成了R1无法telnet到R3.

　　综上所述，在R2上用扩展访问列表可以阻止R3主动向R1发起的TCP连接。但也阻止了R3被动向R1发的TCP回应。这是不合题意的。因此就目前而言，扩展访问列表无法满足这个需求。于是就引出了一个新型的访问列表―――自反访问控制列表。

　　3 用自反访问列表解决此问题。

　　注意：因为自反列表只能建立在命名访问控制列表中，所以这里只能用命名控制列表

　　r2#sh ip access-lists

　　Reflexive IP access list REF

　　 触发的自反列表项，匹配自反列表后自动产生

　　Extended IP access list REFIN

　　deny tcp host 23.0.0.3 host 12.0.0.1

　　permit ip any any

　　evaluate REF

　　 根据上面的自反列表项执行

　　Extended IP access list REFOUT

　　permit ip any any reflect REF

　　 建立自反列表

　　r2(config)#int s2/2

　　r2(config-if)#ip access-group REFIN in

　　 在进方向调用列表REFIN

　　r2(config-if)#ip access-group REFOUT out

　　/在出方向调用列表REFOUT

　　下面进行检验

　　r3#telnet 12.0.0.1

　　Trying 12.0.0.1 ...

　　 Destination unreachable; gateway or host down

　　R3无法登陆R1，这一步成功。再到R1上验证

　　r1#telnet 23.0.0.3

　　Trying 23.0.0.3 ...

　　 Connection timed out; remote host not responding

　　R1也无法登陆R3，这个需求失败了，我们到R2上查看一下ACL

　　r2#sh ip access-lists

　　Reflexive IP access list REF

　　permit tcp host 23.0.0.3 eq telnet host 12.0.0.1 eq 11013 (5 matches) (time left 285)

　　Extended IP access list REFIN

　　deny tcp host 23.0.0.3 host 12.0.0.1 (18 matches)

　　permit ip any any (150 matches)

　　evaluate REF

　　Extended IP access list REFOUT

　　permit ip any any reflect REF (5 matches)

　　让我们仔细的分析一下这个过程，当R3登陆R1时，R2 in 方向的REFIN 列表的第一条语句 deny tcp host 23.0.0.3 host 12.0.0.1 起了作用，因此登陆失败。

　　当R1登陆R3时，R1先向R3发起TCP请求，当这个请求数据包从R2的S2/2接口出来时匹配了REFOUT 列表的permit ip any any reflect REF 的这条语句。并触发了一条自反项。

　　我们可以看到permit tcp host 23.0.0.3 eq telnet host 12.0.0.1 eq 11013 （5 matches） （time left 285） 这个自反项是由于触发自动产生的。它的意思是允许R3用自己的23端口对R1向自己发出的telnet请求作出回应，这个回应向R1的随机端口11013发出。我开始看到产生了这个自反项，就觉得R1应该能成功登陆R3.但事实并不是如此。这是因为虽然产生了这条自反项，但要使数据包按照这个自反项来走，还需要匹配 evaluate REF 这条语句。而这条语句是建立在列表REFIN 中。当R3向R1的回应数据包到达R2时先要匹配列表REFIN .这时我们可以看到这个数据包直接匹配上了deny tcp host 23.0.0.3 host 12.0.0.1 这条语句，而不再匹配下面的语句了。所以它就被直接拒绝了。evaluate REF 这条语句在这里实际上被架空了因此 控制列表语句的顺序是至关重要的。