EdgeMAX - exemplo VTI na EdgeRouter

VTI (Interface de túnel Virtual) é uma forma de vinculação a uma interface de túnel ipsec.  Esse recurso foi adicionado no EdgeOS v 1.6.0.

 

Neste exemplo, teremos o seguinte de rede para o roteador R1 e R2:

R1

==

eth0: 20.0.0.2/30 WAN, gateway 20.0.01/30

eth1: LAN 192.168.1.1/24

 

R2

==

eth0: 30.0.0.2/30 WAN, gateway 30.0.01/30

eth1: LAN 172.16.1.1/24

 

Primeiro vamos usar o assistente de configuração WAN + 2LAN2 2 para que nós podemos mudar a sub-rede LAN no R2.  Então sobre o GUI usaremos a guia VPN para criar um túnel de site-to-site IPSec padrão.  Por último, usaremos o CLI para converter o túnel IPSec para usar a interface VTI.

A tela VPN para R1 se parece com:

 

Depois de fazer o mesmo no R2 podemos verificar o status do túnel.

 

ubnt@R1:~$ show vpn ike sa
Peer ID / IP                            Local ID / IP               
------------                            -------------
30.0.0.2                                20.0.0.2                               

    State  Encrypt  Hash    D-H Grp  NAT-T  A-Time  L-Time
    -----  -------  ----    -------  -----  ------  ------
    up     aes128   sha1    14       no     14730783 28800  

 
ubnt@R1:~$ show vpn ipsec sa
Peer ID / IP                            Local ID / IP               
------------                            -------------
30.0.0.2                                20.0.0.2                               

    Tunnel  State  Bytes Out/In   Encrypt  Hash  NAT-T  A-Time  L-Time  Proto
    ------  -----  -------------  -------  ----  -----  ------  ------  -----
    1       up     0.0/0.0        aes128   sha1  no     967     3600    all

 

Vamos agora tentar ping o outro R2 sub-rede usando o - I para especificar a sub-rede LAN para usar para o endereço de origem.

 

ubnt@R1:~$ /bin/ping -I eth1 172.16.1.1
PING 172.16.1.1 (172.16.1.1) from 192.168.1.1 eth1: 56(84) bytes of data.
64 bytes from 172.16.1.1: icmp_req=1 ttl=64 time=1.27 ms
64 bytes from 172.16.1.1: icmp_req=2 ttl=64 time=0.791 ms
64 bytes from 172.16.1.1: icmp_req=3 ttl=64 time=0.827 ms
^C
--- 172.16.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.791/0.964/1.276/0.223 ms


ubnt@R1:~$ show vpn ipsec sa
Peer ID / IP                            Local ID / IP               
------------                            -------------
30.0.0.2                                20.0.0.2                               

    Tunnel  State  Bytes Out/In   Encrypt  Hash  NAT-T  A-Time  L-Time  Proto
    ------  -----  -------------  -------  ----  -----  ------  ------  -----
    1       up     252.0/252.0    aes128   sha1  no     1127    3600    all

 

Anexados são os arquivos de configuração do trabalho para R1 e R2 antes que converter para VTI.

 

/Config/config.boot R1

/Config/config.boot R2

 

Agora vamos mudar para VTI e ver quais são os prós e do contras  Primeiro vamos criar um VTI interfaces em ambos R1 e R2 e dê a ele um endereço.

 

ubnt@R1:~$ configure 
[edit]
ubnt@R1# set interfaces vti vti0 address 40.0.0.1/30
[edit]
ubnt@R1# commit
[ interfaces vti vti0 ]
Warning: Interface vti0 is not referenced in vpn configuration.

 

Procura no nosso site-para-site config R1, temos:

 

ubnt@R1# show vpn ipsec site-to-site 
 peer 30.0.0.2 {
     authentication {
         mode pre-shared-secret
         pre-shared-secret secret
     }
     connection-type initiate
     ike-group FOO0
     local-address 20.0.0.2
     tunnel 1 {
         allow-nat-networks disable
         allow-public-networks disable
         esp-group FOO0
         local {
             prefix 192.168.1.0/24
         }
         remote {
             prefix 172.16.1.0/24
         }
     }
 }
[edit]

 

 Nós basicamente queremos substituir o túnel com a vinculação de vti:

 

ubnt@R1# edit vpn ipsec site-to-site peer 30.0.0.2 
[edit vpn ipsec site-to-site peer 30.0.0.2]
ubnt@R1# delete tunnel 1
[edit vpn ipsec site-to-site peer 30.0.0.2]
ubnt@R1# set vti bind vti0 
[edit vpn ipsec site-to-site peer 30.0.0.2]
ubnt@R1# set vti esp-group FOO0 
[edit vpn ipsec site-to-site peer 30.0.0.2]
ubnt@R1# top
[edit]
ubnt@R1# compare
[edit vpn ipsec site-to-site peer 30.0.0.2]
-tunnel 1 {
-    allow-nat-networks disable
-    allow-public-networks disable
-    esp-group FOO0
-    local {
-        prefix 192.168.1.0/24
-    }
-    remote {
-        prefix 172.16.1.0/24
-    }
-}
+vti {
+    bind vti0
+    esp-group FOO0
+}
[edit]
ubnt@R1# commit
[edit]

 

Uma grande diferença com o VTI é que nós já não está definindo o que entram no túnel baseado na sub-rede local e remoto.  Com VTI temos uma interface roteável, assim por diante R1 bem adicionar uma rota para 172.16.1.1 através da interface VTI.

 

set protocols static interface-route 172.16.1.0/24 next-hop-interface vti0

E para o R2:

set protocols static interface-route 192.168.1.0/24 next-hop-interface vti0

Com isso nós pode ping a sub-rede remota.  No entanto desde que é uma interface roteável, vamos apagar o estático rotas e em vez disso use o OSPF para dinamicamente aprender as rotas.

 

ubnt@R1:~$ configure 
[edit]
ubnt@R1# delete protocols static interface-route 
[edit]
ubnt@R1# set protocols ospf parameters router-id 20.0.0.2
[edit]
ubnt@R1# set protocols ospf area 0.0.0.0 network 40.0.0.0/30
[edit]
ubnt@R1# set protocols ospf area 0.0.0.0 network 192.168.1.0/24
[edit]
ubnt@R1# set protocols ospf area 0.0.0.0 network 192.168.2.0/24
[edit]
ubnt@R1# set interfaces vti vti0 ip ospf network point-to-point
[edit]
ubnt@R1# commit
[ protocols ospf ]
Starting routing daemon: ospfd.

[edit]
save;exit

 

Da tabela de roteamento podemos ver as rotas aprendidas.

ubnt@R1:~$ show ip route 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 20.0.0.1, eth0
C>* 20.0.0.0/30 is directly connected, eth0
O   40.0.0.0/30 [110/10] is directly connected, vti0, 24w2d15h
C>* 40.0.0.0/30 is directly connected, vti0
C>* 127.0.0.0/8 is directly connected, lo
O>* 172.16.1.0/24 [110/20] via 40.0.0.2, vti0, 00:13:53
O   192.168.1.0/24 [110/10] is directly connected, eth1, 24w2d15h
C>* 192.168.1.0/24 is directly connected, eth1
O   192.168.2.0/24 [110/10] is directly connected, eth2, 24w2d15h
C>* 192.168.2.0/24 is directly connected, eth2

Observe que nós podemos saber atingir ambas as sub-redes remotas de LAN, mas se nós não estávamos usando VTI teria que criar 4 túneis para realizar o mesmo:

192.168.1.0/24  ---  172.16.1.0/24
192.168.1.0/24  ---  172.16.2.0/24
192.168.2.0/24  ---  172.16.1.0/24
192.168.2.0/24  ---  172.16.2.0/24

Anexados são os arquivos de configuração completa para R1 e R2 com VTI e OSPF.

R1 /config/config.boot VTI

/Config/config.boot R2 VTI

 

Observe também que desde que o VTI é uma interface, você também pode aplicar firewall, QoS, etc.

 

ubnt@R1# set interfaces vti vti0 ?
Possible completions:
  address	IP address
  description	Description
  disable	Disable interface
  firewall	Firewall options
  ip		IPv4 routing parameters
  ipv6		IPv6 routing parameters
  mtu		Maximum Transmission Unit (MTU)
  redirect	Incoming packet redirection destination
  traffic-policy
  		Traffic-policy for interface

 

Limitações conhecidas:

  1. Uma vez que é uma interface de ponto a ponto, o ponto de extremidade deve ser um endereço conhecido.  Então ele não funciona com "endereço local qualquer" ou "peer 0.0.0.0".
Powered by Zendesk