EdgeMAX - VTI ejemplo en EdgeRouter

VTI (interfaz de túnel Virtual) es una manera de atar una interfaz de túnel de ipsec.  Esta función fue añadida en EdgeOS v1.6.0.

 

En este ejemplo vamos a tener la siguiente red para el router R1 y R2:

R1

==

eth0: 20.0.0.2/30 WAN, el gateway 20.0.01/30

eth1: 192.168.1.1/24 LAN

 

R2

==

eth0: 30.0.0.2/30 WAN, el gateway 30.0.01/30

eth1: LAN 172.16.1.1/24

 

Primero vamos a usar al asistente de configuración WAN + 2LAN2 2 º por lo que podemos cambiar la subred LAN de R2.  Luego en la interfaz gráfica utilizaremos la pestaña VPN para crear un túnel de sitio a sitio IPSec estándar.  Por último vamos a usar la CLI para convertir el túnel IPSec para utilizar la interfaz VTI.

Se parece a la pantalla VPN para R1:

 

Después de hacer lo mismo en R2 podemos verificar el estado del 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

 

Ahora intentaremos ping otra R2 subred utilizando el - I para especificar la subred de la LAN para la dirección de origen.

 

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

 

Unido son los ficheros de configuración de trabajo para R1 y R2 antes que convertir a VTI.

 

R1 /config/config.boot

R2 /config/config.boot

 

Ahora cambio a VTI y ver cuáles son los pros y los contras  Primero vamos a crear un VTI interfaces tanto R1 y R2 y una dirección.

 

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.

 

Busca en nuestra configuración de sitio a sitio para R1 tenemos:

 

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]

 

 Básicamente queremos sustituir el túnel con el enlace 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]

 

Una gran diferencia con VTI es que ya no estamos definiendo lo que entra en el túnel base de subred local o remota.  Con VTI tenemos una interfaz enrutable, así sucesivamente R1 bien agregar una ruta a 172.16.1.1 vía el interfaz VTI.

 

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

Y para R2:

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

Con eso nos podemos hacer ping a la subred remota.  Sin embargo puesto que es una interfaz enrutable, vamos a eliminar la estática las rutas y en su lugar usar OSPF para dinámicamente aprender las rutas.

 

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

 

De la tabla de enrutamiento podemos ver las rutas 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

Aviso que sabemos que podemos llegar a ambas subredes LAN remotas, pero si no estábamos usando VTI tendría que crear 4 túneles para realizar la misma:

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

Adjunto están los archivos de configuración completos para R1 y R2 con VTI y OSPF.

R1 /config/config.boot VTI

R2 /config/config.boot VTI

 

También tenga en cuenta que puesto que el VTI es una interfaz, usted también puede 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

 

Limitaciones conocidas:

  1. Puesto que es una interfaz punto a punto, el punto final debe ser una dirección conocida.  Por lo que no funciona con "dirección local cualquier" o "peer 0.0.0.0".
Tecnología de Zendesk