自反列表Reflexive access-lists

自反访问列表的应用

实验拓扑:

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

1.初始配置:

R1

interface Ethernet0/0

 ip address 192.168.12.1 255.255.255.0

ip route 192.168.23.0 255.255.255.0 192.168.12.2

�D�D�D�D�D�D�D�D�D�D�D�D�D�D�D�D

R2

interface Ethernet0/0

 ip address 192.168.12.2 255.255.255.0

interface Ethernet0/1

 ip address 192.168.23.2 255.255.255.0

�D�D�D�D�D�D�D�D�D�D�D�D�D�D�D�D

R3

interface Ethernet0/1

 ip address 192.168.23.3 255.255.255.0

ip route 192.168.12.0 255.255.255.0 192.168.23.2 

 

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

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

r2(config)#access-list 100 deny tcp host 192.168.23.3 host 192.168.12.1  

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

r2(config)#int e0/1

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

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

现在进行验证:

r3#telnet 192.168.12.1

Trying 12.0.0.1 ...

% Destination unreachable; gateway or host down

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

r1#telnet 192.168.23.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请求。这是不合题意的。因此就目前而言，扩展访问列表无法满足这个需求。于是就引出了一个新型的访问列表�D�D�D自反访问控制列表。

 

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

注意：自反访问列表只能建立在命名访问控制列表中

1. 建立命名扩展访问列表:
   Extended IP access list REFIN
       deny tcp host 192.168.23.3 host 192.168.12.1
       permit ip any any
       evaluate REF  /根据上面的列表产生自反项,当使用此命令后,再
   show ip access-lists会看到产生了一个自反列表:
   Reflexive IP access list REF
2. 根据产生的自反项建立自反列表:
   

   Extended IP access list REFOUT

       permit ip any any reflect REF

3. 将两个访问列表应用到接口上:
   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 192.168.12.1

Trying 192.168.12.1 ...

% Destination unreachable; gateway or host down

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

r1#telnet 192.168.23.3

Trying 192.168.23.3 ...

% Connection timed out; remote host not responding

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

R2#show ip access-lists

Extended IP access list REFOUT

10 permit ip any any reflect ref (6 matches)

Extended IP access list REFIN

10 deny tcp host 192.168.23.3 host 192.168.12.1 (9 matches)

20 permit ip any any

30 evaluate ref

Reflexive IP access list REF

permit tcp host 192.168.23.3 eq telnet host 192.168.12.1 eq 45735 (5 matches) (time left 296)

 

让我们仔细的分析一下这个过程:

当R3登陆R1时，R2 in 方向的REFIN 列表的第一条语句 deny tcp host 192.168.23.3 host 192.168.12.1 起了作用，因此登陆失败。

当R1登陆R3时，R1先向R3发起TCP请求，当这个请求数据包从R2的E0/1接口出来时匹配了REFOUT 列表的permit ip any any reflect REF 的这条语句。并触发了一条自反项。我们可以看到permit tcp host 192.168.23.3 eq telnet host 192.168.12.1 eq 45735 (5 matches) (time left 296) 这个自反项是由于触发自动产生的。它的意思是允许R3用自己的23端口对R1向自己发出的telnet请求作出回应，这个回应向R1的随机端口45735发出。虽然看到产生了这个自反项，但验证R1登陆到R3却失败了,这是因为虽然产生了这条自反项，但要使数据包按照这个自反项来走，还需要匹配  evaluate REF 这条语句。这条语句是建立在列表REFIN 中。当R3向R1的回应数据包到达R2时先要匹配列表REFIN 。这时我们可以看到这个数据包直接匹配上了deny tcp host 192.168.23.3 host 192.168.12.1 这条语句，而不再匹配下面的语句了。所以它就被直接拒绝了。evaluate REF 这条语句在这里实际上被架空了，因此控制列表语句的顺序是至关重要的。

 

 

下面我们就对这个列表进行修改:

R2#show access-list

Reflexive IP access list REF

permit tcp host 192.168.23.3 eq telnet host 192.168.12.1 eq 14403 (32 matches) (time left 4)

Extended IP access list REFIN

10 evaluate fuck

20 deny tcp host 192.168.23.3 host 192.168.12.1

30 permit ip any any

Extended IP access list REFOUT

10 permit ip any any reflect fuck (21 matches)

 

我现在将REFIN 列表中 evaluate REF 条目放在了第一位,这时当R1向R3的TCP 请求触发了自反列表后，R3向R1的回应在到R2的REFIN列表时匹配的是 evaluate REF 语句，这条语句直接按照自反项 permit tcp host 23.0.0.3 eq telnet host 12.0.0.1 eq 14403 执行。按照我们的分析现在，R1应该可以成功telnet R3。

现在进行验证:

r1#telnet 192.168.23.3

Trying 192.168.23.3 ... Open

r3>

r3#telnet 192.168.12.1

Trying 192.168.12.1 ...

% Destination unreachable; gateway or host down

我们看到R1可以成功登陆到R3，而R3无法登陆到R1 需求满足。

 

现在我们做进一步的扩展，现在的需求是禁止R3对R1和R2的所有TCP连接，而不能影响R1和R2对R3的TCP连接。

1.在R2上建立命名访问列表和自反列表

r2#sh ip access-lists

Reflexive IP access list REF

Extended IP access list REFIN

    evaluate REF

    deny tcp host 192.168.23.3 any   /禁止192.168.23.3向所有目的发出的TCP连接

    permit ip any any (3 matches)

Extended IP access list REFOUT

    permit ip any any reflect REF (19 matches)

 

2.进行验证

r3#telnet 192.168.12.1

Trying 192.168.12.1 ...

% Destination unreachable; gateway or host down

r3#telnet 192.168.23.2

Trying 192.168.23.2 ...

% Destination unreachable; gateway or host down

这时，R3已经无法登陆到R1和R2上，需求满足

r1#telnet 192.168.23.3

Trying 192.168.23.3 ... Open

r3>

R1可以成功登陆到R3，需求满足

r2#telnet 192.168.23.3

Trying 192.168.23.3 ...

% Connection timed out; remote host not responding

R2无法登陆到R3，需求不满足。这是什么原因呢，让我们再来看一下控制列表:

r2#sh ip access-lists

Reflexive IP access list REF

Extended IP access list REFIN

    evaluate REF

    deny tcp host 192.168.23.3 any (21 matches)

    permit ip any any (531 matches)

Extended IP access list REFOUT

    permit ip any any reflect REF (28 matches)

 

我们看到这时没有自动产生一条自反项，也就意味着自反列表没有被触发，说明没有数据匹配到permit ip any any reflect REF 这条语句。所以当R2向R3发起TCP连接后，R3向R2进行TCP回复的数据包到达R2的S2/2接口后，按照REFIN 列表进行匹配，先匹配第一条evaluate REF,由于没有自反项被触发，所以这条语句不执行，接着匹配下一条语句：deny tcp host 192.168.23.3 any 数据包匹配上了这条语句，所以被拒绝。那为什么R2向R3的TCP请求没有触发自反列表呢？这是由于控制列表的一个原则，那就是：本路由器上out方向的控制列表对本路由器自身产生的流量不起作用。在本例中R2对R3的TCP请求根本没有匹配上REFOUT 列表的permit ip any any reflect REF 语句，原因如上所述。

那么如何解决这个问题，让R2能登陆到R3，目前有两种方法：

 

方法一 ：对访问控制列表进行修改

r2#sh ip access-lists

Reflexive IP access list REF

Extended IP access list REFIN

    permit tcp host 23.0.0.3 eq telnet host 23.0.0.2 established

    evaluate REF

    deny tcp host 23.0.0.3 any

    permit ip any any (15 matches)

Extended IP access list REFOUT

    permit ip any any reflect REF (29 matches)

 

permit tcp host 23.0.0.3 eq telnet host 23.0.0.2 established  这条语句表示允许R3用自己的23号端口对R2的TCP请求进行回复。这条语句也可以换一种写法：
permit tcp host 23.0.0.3 eq telnet host 23.0.0.2 ack rst 

 

下面再次进行验证；

r3#telnet 192.168.12.1

Trying 192.168.12.1 ...

% Destination unreachable; gateway or host down

r3#telnet 192.168.23.2

Trying 192.168.23.2 ...

% Destination unreachable; gateway or host down

R3无法登陆R1和R2 需求满足

�D�D�D�D�D�D�D�D�D�D�D�D�D�D�D�D

r1#telnet 192.168.23.3

Trying 192.168.23.3 ... Open

 

r3>

R1可以登陆R3，需求满足

�D�D�D�D�D�D�D�D�D�D�D�D�D

r2#telnet 192.168.23.3

Trying 192.168.23.3 ... Open

 

r3>

R2现在也成功登陆R3，需求满足。

方法二：不修改原来的控制列表，而使用本地策略路由

1.建立route-map

r2(config)#route-map R2 permit 10

r2(config-route-map)#match ip add REFOUT

这个route-map匹配刚才建立的REFOUT列表

 

2.在全局下建立本地策略调用route-map

r2(config)#ip local policy route-map R2

 

3.验证

r2#telnet 192.168.23.3

Trying 192.168.23.3 ... Open

 

r3>

R2成功登陆R3,现在看一下控制列表:

 

r2#sh ip access-lists

Reflexive IP access list REF

    permit tcp host 23.0.0.3 eq telnet host 23.0.0.2 eq 11018 (54 matches) (time left 0)

Extended IP access list REFIN

    evaluate REF

    deny tcp host 23.0.0.3 any (27 matches)

    permit ip any any (1257 matches)

Extended IP access list REFOUT

    permit ip any any reflect REF (63 matches)

 

这个策略的作用是让本路由器产生的数据匹配本路由器的控制列表（本例为REFOUT列表）。从而打破了上面所说的那个控制列表的规则。

现在R2向R3的TCP请求的数据包也要匹配出方向的控制列表REFOUT ，所有也就触发了自反列表，从而自动产生一条自反项。当R3向R2的TCP请求数据包到达R2后匹配入方向的控制列表REFIN 先匹配第一条 evaluate REF 匹配成功。所以就按照自反项permit tcp host 23.0.0.3 eq telnet host 23.0.0.2 eq 11018 执行。所以登陆成功。

 

 

和established区别

 

概念:

1.ESTABLISHED是访问列表中用于反射性的，相当于反谢访问列表--相似。
也就是只有TCP会话先建立，返回的数据包中必须有源TCP相对应的端口
和一定的标识字段，才被允许通过 ，换句话话说，它有局限性，
一是，会话必须邮内向外发起，
二是它只适合于TCP会话，不适合于UDP
三是对于FTP这种在客户端和服务器端建立会话时会改变PORT NUMBER的，它不适用。

 2.自反访问控制列表
自反访问列表的英文名字是Reflexive Access Lists，Reflexive这个词我们翻译成自反，他会根据一个方向的访问控制列表，自动创建出一个反方向的控制列表，是和原来的控制列表—IP的源地址和目的地址颠倒，并且源端口号和目的端口号完全相反的一个列表。并且还有一定的时间限制，过了时间，就会超时，这个新创建的列表就会消失，这样大大增加了安全性。