¿Cómo conecto la nueva VPN Local que contraté con ETECSA para mis instituciones con Mi Red Local? (Parte II)

Saludos nuevamente.

En el post anterior describí someramente [y basado en mi experiencia] cómo debe ser el proceso de conexión de la VPN local que instala ETECSA con la Red Local. En este pondré un ejemplo para ganar un poco más en claridad.

Para ilustrar dicho proceso, supongamos que tenemos la empresa cubana de diseño multipropósito llamada KARAS Project con su Nodo Central y ya se convenió con ETECSA conectar sus 6 sucursales ubicadas en distintos puntos de la isla la cual tiene la infra mostrada en el post TIP sobre configuración de la red de Proxmox.

Primero que todo vamos a recordar el direccionamiento IP interno:

  • VLAN 1: Dispositivos de conectividad, 10.0.1.0/28
  • VLAN 2: Gestión de los Hipervisores Proxmox, 10.0.1.8/29
  • VLAN 3: Administradores de Red de la Empresa, 10.0.1.16/29
  • VLAN 4: Servidores de Red de la Empresa, 10.0.1.32/28
  • VLAN 5: Red LAN de la Empresa, 10.0.1.128/25
  • VLAN 6: Red WAN – Red CUBA (ETECSA), 190.6.YYY.120/29

 

Como se ve, ya el administrador tiene bien definido su direccionamiento IP dentro de su Nodo Central.

Ahora bien, viene la parte de la VPN local. Supongamos que a ETECSA, en vez de “proponerle” al administrador del nodo un direccionamiento IP establecido por ellos, el administrador le propone un direccionamiento IP ya pensado por él.

OJO: No pretendo crear un conflicto entre la gente de ETECSA y los administradores de organizaciones. Si los primeros ya traen una propuesta y el administrador no tiene con qué defenderse o tiene muchas dudas en la cabeza, pues, tendrá que aceptar los términos, pero la parte discutible está en el rango a utilizar en la conexión entre el router de ETECSA que apunta a la VPN y la Red Local de la organización porque un dato mal puesto creará un problema posterior.

Direccionamiento IP para las conexiones remotas

——————————–

NOTA: Como dije en la primera parte, el administrador debe tener nociones de subnetting. Una forma de ayudar a ubicarse en tiempo y espacio es la siguiente relación:

Un rango /24 tiene:

2 rangos /25

4 rangos /26

8 rangos /27

16 rangos /28

32 rangos /29

64 rangos /30

Entonces, a medida que se divide el subrango inferior, el primer /25 por ejemplo, da la mitad de la totalidad del rango superior, o sea:

Un rango /25 tiene:

2 rangos /26

4 rangos /27

8 rangos /28

16 rangos /29

32 rangos /30

Y así sucesivamente para los inferiores.

No obstante, toda la documentación de Cisco recomienda hacer una tabla con los rangos de direcciones IP e ir llenándolos a medida que se van ocupando.

——————————–

Subred sumaria para las sucursales: 10.0.2.0/24

Subred para 16 enlaces WAN de las sucursales: 10.0.2.0/26

Subred para 16 enlaces LAN de las sucursales: 10.0.2.128/25

NOTA: ¿Por qué estos rangos? Pues, porque un rango /26 tiene 16 subrangos /30, y un rango /25 tiene 16 subrangos /29.

Subred para 16 enlaces a posibles VPNs Locales contra el Nodo Central: 10.0.3.0/26

NOTA: Claro está que, en el caso de una red de una PYME, nunca se llegará a esa cantidad de VPNs locales, pero es para no preocuparse más por pensar en un rango aleatorio para establecer conexiones. Ah, y lo cogí del rango 10.0.3.0/24 porque ya el rango 10.0.1.0/24 está ocupado completamente.

Integración a la Red Local

Ya teniendo bien claro el direccionamiento propuesto a ETECSA, queda integrar ese segmento de red (la VPN Local) a la red existente. Para ello se deben realizar los siguientes pasos:

1.- Crear el espacio en el switch central

Retomando una de las imágenes del post TIP sobre configuración de la red de Proxmox:

VyOS - VLANs

La variante más fácil es crear una nueva VLAN con ID 10 llamada “VPN Local KARAS” a la cual se le asignará, de momento, un puerto del switch (se le puede quitar perfectamente a la VLAN 5).

2.- Modificar la configuración del PC-Router para añadir el nuevo segmento de red

Añadir la nueva subinterfaz de red al PC-Router con el primer rango WAN para conexiones VPN de ETECSA

set interfaces ethernet eth0 vif 10 address 10.0.3.2/30

set interfaces ethernet eth0 vif 10 description “VLAN de la VPN IP-MPLS Local de KARAS Project”

NOTA: La dirección IP 10.0.3.1/30 la tendrá la interfaz LAN del router que ETECSA pone en la empresa. En este punto asumamos, además, que su dirección IP WAN es 192.168.87.2/30 (esta la establece ETECSA internamente).

Añadir las rutas estáticas al PC-Router

NOTA: En este punto para añadir las rutas estáticas se pueden optar por dos variantes:

  • Establecer solamente las rutas sumarias
  • Establecer ruta por ruta de cada sucursal (WAN y LAN)

En mi caso, como soy medio paranoico, prefiero poner en mi PC-Router (o router Cisco) cada ruta estática, tanto la de la WAN como la de la LAN de la institución u organización cliente de mi red:

set protocols static route 10.0.2.0/30 next-hop 10.0.3.1

set protocols static route 10.0.2.128/29 next-hop 10.0.3.1

set protocols static route 10.0.2.4/30 next-hop 10.0.3.1

set protocols static route 10.0.2.136/29 next-hop 10.0.3.1

set protocols static route 10.0.2.8/30 next-hop 10.0.3.1

set protocols static route 10.0.2.144/29 next-hop 10.0.3.1

set protocols static route 10.0.2.12/30 next-hop 10.0.3.1

set protocols static route 10.0.2.152/29 next-hop 10.0.3.1

set protocols static route 10.0.2.16/30 next-hop 10.0.3.1

set protocols static route 10.0.2.160/29 next-hop 10.0.3.1

set protocols static route 10.0.2.20/30 next-hop 10.0.3.1

set protocols static route 10.0.2.168/29 next-hop 10.0.3.1

Ahora bien el router que pone ETECSA en la empresa, el cual es el enlace a la VPN local, debe tener también las rutas anteriores donde ya la puerta de enlace sería el equipamiento intermedio interno que tengan; de ahí que su ruta de salida por defecto (0.0.0.0/0) debe tener como puerta de enlace la dirección IP de la subinterfaz correspondiente en nuestro PC-Router (10.0.3.2) para que haya conectividad entre los dos. Ah, pero ahí no acaba la cosa. Aún falta hacer ajustes en el equipo intermedio interno dentro de ETECSA, o sea, el proveedor de conectividad.

En dicho equipamiento intermedio (que no tengo ni la más remota idea de cómo está conectado todo dentro de ETECSA) estarían ya configuradas las rutas estáticas de las sucursales. La tabla de rutas se vería más o menos así (OJO, los datos de rangos de IP WAN dentro del equipamiento son ficticios, estoy tirando a pura memoria de lo que vi cuando me lo enseñaron hace años):

10.0.2.0/30        10.0.2.1        Ethernet2/0/3.20
10.0.2.1/32        127.0.0.1        InLoopBack0
10.0.2.3/32        127.0.0.1        InLoopBack0
10.0.2.4/30        10.0.2.5        Ethernet2/0/3.24
10.0.2.5/32        127.0.0.1          InLoopBack0
10.0.2.7/32        127.0.0.1        InLoopBack0
(…)
10.0.2.20/30    10.0.2.21        Ethernet2/0/5.47
10.0.2.21/32    127.0.0.1        InLoopBack0
10.0.2.23/32    127.0.0.1        InLoopBack0
(…)
192.168.87.0/30    192.168.87.1    Ethernet2/0/0.98
192.168.87.1/32    127.0.0.1        InLoopBack0
192.168.87.3/32    127.0.0.1        InLoopBack0

Se acuerdan que asumimos que la dirección IP WAN del router de ETECSA era 192.168.87.2/30, ¿verdad? Aquí ya está definida la ruta del otro extremo de la conexión.

Entonces, entre ellos no hay problemas, pero aún falta añadir más rutas. ¿Cuales? Pues, las de nuestra red, claro está. Quedaría, al menos, una ruta más:

10.0.0.0/8        192.168.87.2    Ethernet2/0/0.98

Con esta ruta se le está “diciendo” a ese equipamiento intermedio que busque las otras direcciones IP contenidas en el rango 10.0.0.0/8 que no están definidas en él a través de la puerta de enlace 192.168.87.2. ¿Por qué el rango completo y no los rangos que tiene la empresa? Sencillamente, tener lo más sencilla y limpia posible la tabla de rutas asociada a nuestro servicio de conectividad, imagínense la cantidad de tablas de rutas que los técnicos de Datos de ETECSA tiene que ver diariamente, se vuelven locos. Además, ya a este nivel lo más recomendable es usar rutas sumarias, para restringir el acceso está el administrador del nodo de la empresa.

Claro está que este proceso de ajuste tiene que hacerse durante las pruebas del servicio. Esta parte donde hablo del trabajo interno de ETECSA (que quizás muchos consideren que fue un atrevimiento de mi parte) es para que vean que no es sencillo dicho proceso para ambas partes, y también para que, a través de un ejemplo hipotético, capten la idea general.

Ah, por cierto, si la empresa es tan “pobrecita” que solamente tiene todo en una sola subred, pues, se deben hacer dos cosas:

  • Escoger una dirección IP del rango /24 interno de la empresa para la interfaz LAN del router de ETECSA.
  • Hay que añadir el rango /24 interno en la tabla de rutas del equipamiento interno intermedio dentro de ETECSA.

 

Téngase en cuenta que esto suma unas cuantos riesgos de seguridad a la Red Local, por lo tanto, el cortafuegos se convierte en el primer mejor amigo del administrador.

Bueno, creo que eso es todo por el momento. Si se me olvidó o dejé pasar por alto algún dato lo añadiré posteriormente.

Espero les sirva.

😀

 

Acerca de Hector Suarez Planas

Es Licenciado en Ciencia de la Computación (3 de julio de 2002). Ha sido Administrador de Red en varias organizaciones, Programador y Analista de Sistemas. Actualmente se desempeña como Administrador de Red del Telecentro Tele Turquino de Santiago de Cuba. Tiene experiencia con sistemas Windows y GNU/Linux, Infraestructura de Redes (Cisco, AlliedTelesis, Netgear y HP ProCurve, Vyatta/VyOS), Servidores tanto físicos como virtuales (plataformas VMWare, Proxmox VE y Xen), Sistemas de Seguridad Informática (Snort/Suricata IDS, appliances AlienVault OSSIM), programador (Delphi, C++ Builder, Perl [poco], Python [algo]), entre otras cosas. Actualmente estoy incursionando en todo lo que tiene relación con Cloud Computing (OpenStack) y Centros de Datos. :-)
Esta entrada fue publicada en ETECSA, Routing, VLAN, VPN, Vyatta/VyOS/EdgeOS. Guarda el enlace permanente.