三臺路由器串聯，要求阻止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 這條語句在這里實際上被架空了因此 控制列表語句的順序是至關重要的。

【編輯推薦】

1. 思科認證專區
2. 軟考專區