Hola a todos,
En el mundo de la VozIP, a menudo nos encontramos con distintos escenarios y en la gran mayoría de los casos, el mayor de los retos suele ser poder tener una RED controlada en la cual no haya NAT ni elementos que puedan influir en la comunicación SIP de nuestras soluciones.
Una de las soluciones más habituales suele ser utilizar los productos de conexión que actualmente ofrecen la mayoría de los operadores de red, como pueden ser MPLS o CONNECT-LAN. Se trata de soluciones profesionales y con altos niveles de fiabilidad y seguridad que, no obstante, suelen generar ciertas dudas. Más allá de ser respuestas que no resultan rentables para grupos de usuarios pequeños, ¿qué ocurre cuando en las distintas delegaciones en las que queremos tener una conexión de este tipo, el operador no es capaz de ofrecernos esta solución?
En Irontec ya hemos experimentado este tipo de problemática con ciertos clientes que, queriendo conectar distintas sedes por todo España, no podían disfrutar de este tipo de conexiones en algunas ubicaciones.
A continuación os proponemos una solución aplicable en estas situaciones.
Crear una Red Privada Virtual propia
Para crearla necesitamos tener una serie de requisitos cumplidos:
Sede central:
- Conexión a Internet fiable y con un ancho de banda suficiente para albergar todo el tráfico IN/OUT de las sedes.
- IP Pública fija.
- Router con soporte para OPENVPN y BGP
Sedes remotas:
- Conexión a Internet con un ancho de banda suficiente para albergar el tráfico de la sede.
- Router con soporte para OPENVPN y BGP
La solución: Ubiquiti EdgeRouter X
Utiliza una versión bifurcada de la edición opensource de Vyatta 6.3 (ahora mantenido como VyOS después de ser adquirido por parte de Brocade). La mejor forma de aprender acerca de cómo funciona pasa por leer páginas de documentación de los viejos documentos vyatta, teniendo en cuenta siempre que Ubiquiti ha modificado muchísimas cosas.
No obstante, en la página de la comunidad hay una gran cantidad de ayuda. Por extraño que parezca, no todo lo que hacen está documentado, por lo que la mayoría son Release notes. Otra opción es acosar 😉 a los empleados que rondan los foros.
En Irontec estamos muy contentos con estos router, a los que ya hemos dado distintos usos. Si queréis echarle un vistazo a un ejemplo, en el post de @zetagor Mecanismos de supervivencia local con kamailio y edge-router podéis ver una de las posibilidades.
En primer lugar, vamos a imaginar un escenario con una sede central con muchos usuarios y múltiples sedes pequeñas.
Para dar respuesta a esta situación, en la que las delegaciones no disponen de conexiones como las mencionadas antes –MPLS, CONNECT-LAN, etc- podríamos poner un EdgeRouterX en la sede central a modo de Servidor, y otro EdgeRouterX en cada delegación a modo de cliente.
Preparando el equipamiento:
En primer lugar, hay que preparar los Edgerouters. Estos dispositivos vienen configurados con un IP estática en la interfaz eth0, lo cual hace muy cómodo acceder a ellos y empezar la configuración. Conviene apuntar que la mayoría de opciones se puede configurar vía WEB, pero hay ciertas cosas que, o bien no se puede, o bien es más sencillo hacerlo por el CLI de los dispositivos.
Una vez actualizado el firmware del dispositivo a su versión más reciente (Sep 2016) habrá que configurar la parte de red local, tanto de la sede central como de las delegaciones.
Sede central: Servidor OpenVPN
Entramos por ssh al Router. Vamos al path /config/ y crear un archivo de configuración para OpenVPN con los datos del servidor.
root@central:/config# vi servidor.conf dev vtun0 dev-type tap mode server port 1200 comp-lzo keepalive 10 60 ifconfig 10.10.10.1 255.255.255.0 tls-server dh /config/dh1024.pem client-config-dir /config/vpnsedes/ ccd-exclusive client-to-client #LOGGING log-append /var/log/openvp.log status /var/log/openvp-status.log #verb 6 <ca> -----BEGIN CERTIFICATE-----
Una vez creado el archivo, hay que habilitar el servicio OpenVPN creando una interfaz y asignándole este archivo.
configure set interfaces openvpn vtun0 config-file /config/servidor.conf commit save exit
Es necesario tener un archivo por cada delegación en el path /config/vpnsedes con la interfaz de vpn que le corresponde a cada sede.
root@central:/config# cat vpnsedes/router.sede1 ifconfig-push 10.10.10.2 255.255.255.0
Sede remota: Cliente OpenVPN
Entramos por ssh al Router. Vamos al path /config/ y crear un archivo de configuración para OpenVPN con los datos del servidor.
root@central:/config# vi sede.conf dev tun1 dev-type tap remote X.X.X.X 1200 nobind comp-lzo tls-client keepalive 10 60 pull <ca> -----BEGIN CERTIFICATE-----
Una vez creado el archivo, hay que habilitar el servicio OpenVPN creando una interfaz y asignándole este archivo.
configure set interfaces openvpn vtun0 config-file /config/sede.conf commit save exit
Una vez llegados a este punto, ya tenemos las sedes conectadas entre sí y podríamos llegar desde cualquier router hasta los demás, pero ¿llegaríamos desde un equipo en la central hasta otro en las delegaciones? La respuesta es no. No tenemos rutas para tener conectividad entre las distintas redes internas y por tanto los equipos de las delegaciones no se ven entre sí, ni llegan a la sede central.
En este punto podríamos pensar en introducir rutas estáticas, pero esto haría que por cada delegación hubiera que introducir una ruta estática en cada router. Una forma de solventar este inconveniente es utilizar Quagga con BGP. Los EdgeRouters vienen con soporte nativo para Quagga y BGP, por lo que tan solo será necesario configurarlo para que funcione como queremos.
Sede central: Servidor
configure set policy access-list 1 rule 1 source network 192.168.0.0 set policy access-list 1 rule 1 source inverse-mask 0.0.255.255 set policy access-list 1 rule 1 action permit set policy access-list 1 rule 1 source network 10.10.10.0 set policy access-list 1 rule 1 source inverse-mask 0.0.0.255 set policy access-list 1 rule 1 action permit set protocols bgp NUMEROAS parameters router-id IPHOST set protocols bgp NUMEROAS network 192.168.1.0/24 set protocols bgp NUMEROAS neighbor 10.10.10.2 remote-as REMOTEAS01 set protocols bgp NUMEROAS neighbor 10.10.10.2 soft-reconfiguration inbound set protocols bgp NUMEROAS neighbor 10.10.10.2 distribute-list export 1 set protocols bgp NUMEROAS neighbor 10.10.10.3 remote-as REMOTEAS02 set protocols bgp NUMEROAS neighbor 10.10.10.3 soft-reconfiguration inbound set protocols bgp NUMEROAS neighbor 10.10.10.3 distribute-list export 1 set protocols bgp NUMEROAS parameters disable-network-import-check commit save exit
Sede remota: Cliente
configure set policy access-list 1 rule 1 source network 192.168.2.0 set policy access-list 1 rule 1 source inverse-mask 0.0.0.255 set policy access-list 1 rule 1 action permit set protocols bgp REMOTEAS01 parameters router-id IPHOST set protocols bgp REMOTEAS01 network 192.168.2.0/24 set protocols bgp REMOTEAS01 neighbor 10.10.10.1 remote-as NUMEROAS set protocols bgp REMOTEAS01 neighbor 10.10.10.1 soft-reconfiguration inbound set protocols bgp REMOTEAS01 neighbor 10.10.10.1 distribute-list export 1 set protocols bgp REMOTEAS01 parameters disable-network-import-check commit save exit
Con esta configuración, cada sede remota publicará su red interna a la sede central. La sede central recibirá las redes de las sedes remotas, las re-publicará hacia las otras sedes remotas y también publicará la red interna de la sede central. De este modo, todas las redes son visibles entre sí, pudiendo registrar cualquier terminal desde cualquier sede en la centralita que tengamos en la sede central:
En caso de que una sede pierda conectividad, esta sede se quedará sin telefonía y las demás sedes seguirán funcionando perfectamente, pero ¿qué ocurriría si la sede central tiene una caída de Internet? Todas las delegaciones, incluida la central, se quedarán sin telefonía. La solución para evitar esto sería montar una conectividad redundada.
Crear una Red Privada Virtual propia HA
Para poder crear una red redundante, lo primero que necesitaremos es tener dos salidas independientes a Internet. Esta segunda conexión también tendrá que tener una IP publica fija y es recomendable tener el mismo ancho de banda para que, en caso de caída, la calidad de la conexión no se vea afectada. Por otra parte, también es recomendable que las conexiones sean de distintas compañías y que tengan su propia infraestructura, ya que de lo contrario, si cae una conexión, lo más seguro es que caiga la otra. En la siguiente infografía se puede observa cómo funcionaría el esquema de esta conexión.
Para desarrollar este esquema, hay que dar los siguientes pasos.
- Crear el router HA con la configuración similar a la del router principal. OPENVP, Quagga, BGP
- Crear los túneles para el HA y levantarlos en los clientes.
- Modificar Quagga y BGP en los clientes para que publiquen las redes por los nuevos enlaces.
- Modificar Quagga y BGP en los dos router de central para que se envíen la información entre ellos.
Sede central: Configuración Router HA
Crear un archivo de configuración para OpenVPN con los datos del servidor y habilitar el servicio. La única diferencia en el archivo, además de los certificados, será la IP/MAK en de la red VPN
< ifconfig 10.10.10.1 255.255.255.0 --- > ifconfig 10.10.20.1 255.255.255.0
Para las delegaciones, hay que crear también un archivo como ya habíamos hecho en el router principal, con el direccionamiento de la red escogida para el HA.
En parte de QUAGGA quedaría de la siguiente manera:
configure set policy access-list 1 rule 1 source network 192.168.0.0 set policy access-list 1 rule 1 source inverse-mask 0.0.255.255 set policy access-list 1 rule 1 action permit set policy access-list 1 rule 1 source network 10.10.10.0 set policy access-list 1 rule 1 source inverse-mask 0.0.0.255 set policy access-list 1 rule 1 action permit set policy access-list 1 rule 1 source network 10.10.20.0 set policy access-list 1 rule 1 source inverse-mask 0.0.0.255 set policy access-list 1 rule 1 action permit set protocols bgp NUMEROAS2 parameters router-id IPHOST set protocols bgp NUMEROAS2 network 192.168.1.0/24 set protocols bgp NUMEROAS2 neighbor 10.10.20.2 remote-as REMOTEAS01 set protocols bgp NUMEROAS2 neighbor 10.10.20.2 soft-reconfiguration inbound set protocols bgp NUMEROAS2 neighbor 10.10.20.2 distribute-list export 1 set protocols bgp NUMEROAS2 neighbor 10.10.20.3 remote-as REMOTEAS02 set protocols bgp NUMEROAS2 neighbor 10.10.20.3 soft-reconfiguration inbound set protocols bgp NUMEROAS2 neighbor 10.10.20.3 distribute-list export 1 set protocols bgp NUMEROAS2 neighbor 192.168.1.254 remote-as NUMEROAS set protocols bgp NUMEROAS2 neighbor 192.168.1.254 soft-reconfiguration inbound set protocols bgp NUMEROAS2 neighbor 192.168.1.254 distribute-list export 1 set protocols bgp NUMEROAS parameters disable-network-import-check commit save exit
Sede central: Configuración Router
En la configruación de QUAGGA del router principal hay que hacer unos cambios para que permita la re-publicación de la red VPN de HA y añadir el nuevo neighbor, que es el router HA.
configure set policy access-list 1 rule 1 source network 192.168.0.0 set policy access-list 1 rule 1 source inverse-mask 0.0.255.255 set policy access-list 1 rule 1 action permit set policy access-list 1 rule 1 source network 10.10.10.0 set policy access-list 1 rule 1 source inverse-mask 0.0.0.255 set policy access-list 1 rule 1 action permit set policy access-list 1 rule 1 source network 10.10.20.0 set policy access-list 1 rule 1 source inverse-mask 0.0.0.255 set policy access-list 1 rule 1 action permit set protocols bgp NUMEROAS parameters router-id IPHOST set protocols bgp NUMEROAS network 192.168.1.0/24 set protocols bgp NUMEROAS neighbor 10.10.10.2 remote-as REMOTEAS01 set protocols bgp NUMEROAS neighbor 10.10.10.2 soft-reconfiguration inbound set protocols bgp NUMEROAS neighbor 10.10.10.2 distribute-list export 1 set protocols bgp NUMEROAS neighbor 10.10.10.3 remote-as REMOTEAS02 set protocols bgp NUMEROAS neighbor 10.10.10.3 soft-reconfiguration inbound set protocols bgp NUMEROAS neighbor 10.10.10.3 distribute-list export 1 set protocols bgp NUMEROAS neighbor 192.168.1.1 remote-as NUMEROAS2 set protocols bgp NUMEROAS neighbor 192.168.1.1 soft-reconfiguration inbound set protocols bgp NUMEROAS neighbor 192.168.1.1 distribute-list export 1 set protocols bgp NUMEROAS parameters disable-network-import-check commit save exit
Sede remota: Cliente OpenVPN para HA
En las sedes remotas habrá que crear un nuevo archivo para la configuración del servicio de openvpn cliente. La única diferencia que habrá será la IP pública a la que se conecten, así como los certificados.
< dev vtun0 --- > dev vtun1 < remote X.X.X.X 1200 --- > remote Y.Y.Y.Y 1200
De la misma manera, hay que modificar QUAGGA para añadir el nuevo neighbor:
configure set policy access-list 1 rule 1 source network 192.168.2.0 set policy access-list 1 rule 1 source inverse-mask 0.0.0.255 set policy access-list 1 rule 1 action permit set protocols bgp REMOTEAS01 parameters router-id IPHOST set protocols bgp REMOTEAS01 network 192.168.2.0/24 set protocols bgp REMOTEAS01 neighbor 10.10.10.1 remote-as NUMEROAS set protocols bgp REMOTEAS01 neighbor 10.10.10.1 soft-reconfiguration inbound set protocols bgp REMOTEAS01 neighbor 10.10.10.1 distribute-list export 1 set protocols bgp REMOTEAS01 neighbor 10.10.20.1 remote-as NUMEROAS2 set protocols bgp REMOTEAS01 neighbor 10.10.20.1 soft-reconfiguration inbound set protocols bgp REMOTEAS01 neighbor 10.10.20.1 distribute-list export 1 set protocols bgp REMOTEAS01 parameters disable-network-import-check commit save exit
Una vez configurado todo ello, ya tenemos una ruta alternativa por la que llegar a la sede central desde cualquier delegación, y por tanto, si hubiera una caída de cualquiera de los dos enlaces a internet de los que disponemos en la central, el servicio no se vería afectado. Aún así, aquí surge un problema: ¿cuál de las dos rutas se escogerá para llegar a la central y cuál de las dos para volver?
En este punto no lo sabemos, y por tanto para que la ruta escogida sea la que nosotros queremos le daremos más peso a las rutas que se publiquen desde el router HA. De este modo, salvo que la ruta inicial no esté accesible, nunca se escogerá la ruta HA y quedará de backup.
Esto lo haremos modificando QUAGGA en el router HA de la central
configure set policy access-list 1 rule 1 source network 192.168.0.0 set policy access-list 1 rule 1 source inverse-mask 0.0.255.255 set policy access-list 1 rule 1 action permit set policy access-list 1 rule 1 source network 10.10.10.0 set policy access-list 1 rule 1 source inverse-mask 0.0.0.255 set policy access-list 1 rule 1 action permit set policy access-list 1 rule 1 source network 10.10.20.0 set policy access-list 1 rule 1 source inverse-mask 0.0.0.255 set policy access-list 1 rule 1 action permit set policy route-map concatenar rule 10 set as-path-prepend NUMEROAS2 set protocols bgp NUMEROAS2 parameters router-id IPHOST set protocols bgp NUMEROAS2 network 192.168.1.0/24 set protocols bgp NUMEROAS2 neighbor 10.10.20.2 remote-as REMOTEAS01 set protocols bgp NUMEROAS2 neighbor 10.10.20.2 soft-reconfiguration inbound set protocols bgp NUMEROAS2 neighbor 10.10.20.2 distribute-list export 1 set protocols bgp NUMEROAS2 neighbor 10.10.20.2 route-map export concatenar set protocols bgp NUMEROAS2 neighbor 10.10.20.3 remote-as REMOTEAS02 set protocols bgp NUMEROAS2 neighbor 10.10.20.3 soft-reconfiguration inbound set protocols bgp NUMEROAS2 neighbor 10.10.20.3 distribute-list export 1 set protocols bgp NUMEROAS2 neighbor 10.10.20.3 route-map export concatenar set protocols bgp NUMEROAS2 neighbor 192.168.1.254 remote-as NUMEROAS set protocols bgp NUMEROAS2 neighbor 192.168.1.254 soft-reconfiguration inbound set protocols bgp NUMEROAS2 neighbor 192.168.1.254 distribute-list export 1 set protocols bgp NUMEROAS2 neighbor 192.168.1.254 route-map export concatenar set protocols bgp NUMEROAS parameters disable-network-import-check commit save exit
¿Qué ventajas obtenemos de todo esto? Lo más importante será que podremos tener un entorno de trabajo controlado y sin NAT de forma independiente, en el que no tendremos que preocuparnos de si a una delegación llega la conectividad del operador con el que tenemos contratada la conectividad entre sedes. De esta manera, también seremos independientes del operador y podremos elegir el que más nos convenga en cada zona.
Además de todo esto, hay que recordar el coste que tienen las conexiones tipo MPLS o CONNECT-LAN, lo cual será de agradecer para el cliente 🙂
Todo ello, eso sí, no quiere decir que estas ventajas no puedan tener una contrapartida negativa. Gestionar personalmente la red puede suponer un quebradero más de cabeza, aunque si la monitorización es correcta y está bien ejecutado no tiene por qué ser así.
Desde Irontec, os animamos a que probéis la solución planteada y nos hagáis llegar las dudas al respecto. Y como siempre, por supuesto, toda aportación será bienvenida.
Un saludo
Queremos tu opinión :)