Montar una VPN full-mesh con tinc

Una Red Privada Virtual (VPN en inglés) permite conectar varias redes entre sí, utilizando un medio público (potencialmente inseguro) como puede ser Internet. Las ventajas son multiples. Todos los equipos de cada red se pueden “ver” entre sí, utilizando direcciones de red privadas, que de otra forma no serían enrutables a través de Internet. Nos olvidamos del NAT, de la redirección de puertos, etc.

Hasta hace poco, solo había trabajado con OpenVPN. Es facil de configurar, y en la versión 2 habían incorporado el modo cliente-servidor, de forma que podíamos tener 1 servidor que interconectase a n clientes, con sus correspondientes redes.

Hasta aquí bien, aunque más de uno se dará cuenta del problema, y es que como te falle el servidor, la VPN se cae. Además, y esto también es importante en términos de latencia y ancho de banda, las comunicaciones entre clientes las enruta el servidor. No hay canreinvite en OpenVPN

La solución que se viene a la cabeza, es que todos los nodos sean servidores. Correcto. Pero el problema entonces viene por la escasa escalabilidad de la solución. Por cada nodo adicional que añadas a la VPN, tienes que configurar n+1 nodos (los n que ya había más el nuevo). Con 3 o 4 nodos se lleva bien, pero a partir de ahi olvídate.

Full-Mesh VPN

Y un día, buscando cómo hacía otra gente las VPN full-mesh (todos los nodos conectados directamente entre sí), descubrí tinc. Entre sus características:

Encryption, authentication and compression. Nada nuevo, encriptación para que nuestra información viaje segura por el medio inseguro (Internet). Autenticación, para que nodos desconocidos no puedan inyectar tráfico en nuestra red. Compresión, que nos permite sacar un poco más de partido a nuestra ADSL, comprimiendo los paquetes, antes de enviarlos.
Automatic full mesh routing. Aquí empieza lo bueno. Cada nodo en tinc se intercambia información de enrutamiento con el resto de nodos, de forma que cada uno se hace responsable de su subred (nodoa 192.168.0.0/24, nodob 192.168.1.0/24, etc). Cuando queremos acceder a una red en concreto, tinc contacta si puede con el nodo responsable de esa subred. Si no, utiliza un nodo intermedio para ello.
Easily expand your VPN. Para añadir un nuevo nodo, solo tenemos que configurar 2 nodos. El nuevo y uno de los que ya esté funcionando. Como la información de rutado se propagará por el resto de nodos automáticamente, esta es la configuración mínima que tendremos que hacer. Por supuesto, si configuramos dos o tres nodos, la VPN ganara en fiabilidad y robustez.

Escenario

Tenemos 3 sedes, cada una con su red privada y un acceso a internet:

Sede A: 192.168.1.0/24. IP pública en Internet: 1.2.3.4
Sede B: 192.168.2.0/24. IP pública en Internet: 2.3.4.5
Sede C: 192.168.3.0/24. IP pública en Internet: 3.4.5.6

La máquina linux que corre tinc está siempre en la IP acabada en .1: 192.168.1.1, 192.168.2.1, 192.168.3.1.

En este ejemplo, por ser la configuración más común, la IP pública está asignada a un router ADSL. En este router, tendremos que configurar una nueva ruta, de forma que todo lo que llegue con destino a las otras sedes, se enrute por nuestro tinc. Algo como “route add -net 192.168.0.0 netmask 255.255.0.0 gw 192.168.1.1″. También abriremos el puerto 655 (TCP y UDP) redirigiéndolo a nuestra máquina con tinc.

Configuración

Creamos los directorios de configuración:

# mkdir /etc/tinc # mkdir /etc/tinc/hosts

Creamos el fichero /etc/tinc/tinc.conf

Name = SedeA Device = /dev/net/tun ConnectTo = SedeB ConnectTo = SedeC

Creamos el fichero /etc/tinc/hosts/SedeA

Subnet = 192.168.1.0/24 Address = 1.2.3.4 Compression = 10

Generamos el par de claves para este nodo:

# tincd -K Generating 1024 bits keys: ..............++++++ p ..............++++++ q Done. Please enter a file to save private RSA key to [/etc/tinc/rsa_key.priv]: Please enter a file to save public RSA key to [/etc/tinc/hosts/SedeA]: Appending key to existing contents. Make sure only one key is stored in the file.

Ahora configuramos el interfaz tun0. Tinc llamará al script “/etc/tinc/tinc-up” al arrancar:

#!/bin/sh ifconfig $INTERFACE 192.168.1.1 netmask 255.255.0.0

Marcamos el fichero como ejecutable:

# chmod +x /etc/tinc/tinc-up

Repetimos el proceso con las otras dos sedes, y como paso final, intercambiamos los ficheros SedeA, SedeB y SedeC entre todos los nodos, para que todos ellos se conozcan entre sí.

Finalmente, ejecutamos el demonio:

tincd

O si queremos depurar algun problema, lo ejecutamos con depuración y sin desconectarse de la consola:

tincd -d5 -D

Si todo va bien, desde cualquier equipo de la red podremos hacer ping a cualquier otro, aunque sea de otra sede:

Suerte.

Julián J. Menéndez

Actualización 08-09-2007: La versión de tinc en el respositorio ipkg de openwrt es la 1.0.4. La versión a día de hoy es la 1.0.8. Podéis encontrar el paquete para esta versión aquí: http://augsburg.freifunk.net/ipkg/

Escrito por julianjm el 6/09/2007. |
Tags: full mesh, tinc, VPN

48 Comments »

Vaya! Parece interesante. Yo antes montaba las VPN con CIPE y ahora con OpenVPN. Este último me gusta bastante, pero también me encuentro con los problemas de tener un nodo central.

Le echaré un ojo a este tinc, a ver cómo funciona.

Comment by davidp — 6 September 2007 @ 20:56
En mi caso fueron 4 sedes. En todas ellas ya tenía routers Linksys WRT54G en cabecera (con la IP pública). Todos con firmware OpenWRT, así que solo quedaba instalar tinc (ipkg install tinc), y configurarlo.

Comment by julianjm — 7 September 2007 @ 7:03
lo del canreinvite no acabo de verlo… cualesquiera dos telefonos podrán enviarse el audio directamente siempre, no???

Comment by PACO — 7 September 2007 @ 21:48
Paco, era una broma… me refería a que con OpenVPN, todo pasa por el nodo central (el que hace de servidor), ya que los nodos cliente no se ven entre sí.

Comment by julianjm — 7 September 2007 @ 22:12
ah vale
lo que sí que se nota tanto con OpenVPN como con tinc(por lo que he leido) es la calidad de la llamada por VoiP (usando o no asterisk)… es curioso pero mejora bastante.
por cierto, julian, la versión 1.08 no he visto que esté portada a openwrt (o incluso a dd-wrt que es el que utilizo ahora).

Comment by PACO — 7 September 2007 @ 22:18
Yo uso la que hay disponible en ipkg, la 1.0.4-2, y no he tenido problemas… A ver si un día con tiempo y ganas hago el paquete para la 1.0.8…

Respecto a la calidad de la llamada, no se como podría afectar positiva o negativamente el pasar o no por una VPN…

Comment by julianjm — 7 September 2007 @ 22:23
Paco, he actualizado el artículo con el enlace a la versión 1.0.8 para OpenWRT. Probada y funcionando sin cambios.

Comment by julianjm — 8 September 2007 @ 13:18
pues a probarla se ha dicho!!!!

gracias julian

Comment by paco — 9 September 2007 @ 9:23
Según leí y comenté con compañeros más expertos que yo, la principal característica de utilizar VPN frente a tráfico UDP exclusivamente, es la desventaja de UDP a la hora de chequear errores: si se te pierden paquetes, pues los has perdido y punto. Con la VPN esto no pasa y por tanto parece que la calidad aumenta.
Yo te digo que utilizo VPN’s y, además, dándole bastante caña con VOIP y la gente no se me queja en absoluto ( a no ser que falle el proveedor, claro está)…

Comment by paco — 9 September 2007 @ 9:26
Paco, me temo que no es así. De hecho, tanto OpenVPN como tinc trabajan por defecto usando paquetes UDP para tunelizar el tráfico.

El modo TCP solo recomiendan utilizarlo si tienes algún firewall por medio que te esté filtrando el tráfico UDP.

Además, para la VozIP se usa UDP porque aunque no es fiable (si se pierde un paquete se perdió), es mejor que generar un retardo esperando que llegue. Es decir, prefiero perder 1 segundo de audio a que se retrase toda la conversación ese segundo.

En este caso, usar una VPN UDP (como tinc), solo provocaría que los paquetes RTP se encapsulasen a su vez en paquetes UDP de la VPN.

Si en este caso encuentras diferencia entre usar VPN o no usarla (a favor de la VPN), es probable que alguien te esté haciendo “traffic shaping” con tus paquetes de voz

Comment by julianjm — 9 September 2007 @ 14:31
Hola Jualian:
He estado montando dos maquinas en Ubuntu para probar las vpn y tenido que añadir una ruta en cada maquina para poder hacer un ping entre las dos:
Maquina 1:
route add -net 192.168.7.0 netmask 255.255.255.0 dev tun0

Maquina 2:
route add -net 10.10.0.0 netmask 255.255.0.0 dev tun0

Entre ellas se ven, pero otras conectadas en cada red no.
¿Que estoy haciendo mal?
Gracias.

Comment by Manolo — 25 September 2007 @ 13:32
Manolo, el resto de máquinas qué puerta de enlace predeterminada tienen configurada? Seguramente sea un router ADSL/Cable.

Es en ese router en el que tienes que definir las rutas 192.168.7.0/24 y 10.10.0.0/16, y enrutarlas a la máquina donde tengas instalado el software vpn.

De otro modo, los paquetes saldrán a internet, y se perderán

Julián J. M.

Comment by julianjm — 25 September 2007 @ 14:03
Cada maquina tiene como gw el ubuntu que tiene el tinc, osea que para la maquina 192.168.7.5/24 tiene como gw la 192.168.7.250(Ubuntu con Tinc) y para la otra maquina que tiene 10.10.101.100/16 tiene como gw la 10.10.101.111 (Ubuntu con Tinc). Tambien hice la prueba de introducir la ruta en el router Cable pero tampoco me funciono.

Manolo.

Comment by Manolo — 25 September 2007 @ 14:28
Entonces comprueba que el firewall no está filtrando el forwarding desde eth0 a tun0.

También asegurate de que /proc/sys/net/ip_forward está a 1, aunque supongo que eso ya lo tenías activo, siendo tu máquina un router.

Saludos
Julián J. M.

Comment by julianjm — 25 September 2007 @ 16:37
El firewall lo tenia bien, el problema estaba en ip_forward = 0, lo puse a 1 y sin problemas.

Comment by Manolo — 26 September 2007 @ 8:26
Tengo una duda.
Segun la explicacion, toda la configuracion se hace en los /etc de los servidores linux, ya que hablas de redirigir los puertos 655 tcp/udp.
Pero luego hablas de bajar tinc para OpenWRT en formato ipkg.
O sea que hay una segunda opcion de instalar tinc en los routers y no en los servidores?
O lo instalas en los routers y en los servidores??
Yo tengo dd-wrt 2.4 beta en mi WRT54GL. Sabes si el ipkg vale tambien para dd-wrt?? Creo que tengo activada una pequeña particion jffs, igual se puede instalar ahi??

Comment by ramoncio — 6 December 2007 @ 11:29
Ramoncio, si lo haces en servidores que están detrás de NAT, entonces tienes que hacer la redirección del puerto 655.

Ahora bien, si tienes un router con firmware openWRT, puedes utilizarlo como servidor de VPN. De esta forma no necesitas redirigir nada (si el router tiene la IP pública).

Es cuestión de gustos. Pero o una cosa o la otra. En mi caso utilicé routers Linksys WRT54G para unir 5 oficinas.

Respecto a si dd-wrt soporte ipkg, una rápida búsqueda en google me dice que sí:
http://www.dd-wrt.com/wiki/index.php/Ipkg

Comment by julianjm — 6 December 2007 @ 20:54
Muchas gracias por tu pronta respuesta.
Voy a ver si este fin de semana tengo tiempo y pruebo el tinc en mi red. Como maximo puedo poner 3 nodos: 1 wrt54gl con dd-wrt y dos servidores asterisk detras de nat. Si tengo problemas con el dd-wrt igual pongo en los 3 sitios nat+asterisk.
Pero primero he de resolver unos problemas que tengo con los canales zap en el servidor asterisk de mi casa. Es algo muy raro. Cuando llamo fuera usando una troncal zap, la llamada se corta a los 5 min 30 seg exactamente.

Gracias por tu fabuloso blog, lo sigo con mucho interes.
Un saludo

Comment by ramoncio — 7 December 2007 @ 17:51
No consigo que funcione…

Donde tengo que poner las keys, publica y privada?
En el articulo no lo veo en nigun sitio…

Comment by ramoncio — 2 January 2008 @ 18:46
Ramoncio, la claves te las genera el comando “tincd -K”. Te guardará la clave privada en /etc/tinc/rsa_key.priv.
La pública te la guardará en un fichero dentro de /etc/tinc/hosts/. El nombre de fichero es el nombre que hayas dado a tu nodo en el tinc.conf. En el ejemplo SedeA.

En ese fichero van los parámetros del nodo, seguidos de la clave pública que generó “tincd -K”:

/etc/tinc/hosts/SedeA:
Subnet = 192.168.1.0/24 Address = 1.2.3.4 -----BEGIN RSA PUBLIC KEY----- MIGJAoGBANitWKeu5PF3f5tw...... ...... ...... -----END RSA PUBLIC KEY-----

Comment by julianjm — 3 January 2008 @ 8:09
Ya me funciona!!
Las keys las he tenido que poner manualmente, pero ahora funciona!
Pero la vpn solo se establece entre los servidores linux, esto es normal? No puedo acceder a otros equipos de las subredes?

Comment by ramoncio — 3 January 2008 @ 10:47
Tienes que habilitar el “forwarding” en la máquina con tinc. Comentario #14

Si el gateway de la red no es la máquina con tinc, tendrás que configurar el gateway, y añadirle una ruta estática, de forma que cuando un equipo de la red intente conectar con una IP de la vpn, ésta pase por la máquina con tinc.

Comment by julianjm — 4 January 2008 @ 13:31
No tengo muy claro como hacerlo.
El servidor asterisk de mi casa tiene la ip 192.168.160.222 y el router la 192.168.160.222. En la otra punta de la VPN el servidor tiene la ip 192.168.111.222 y el router la 192.168.111.200.
He intentado añadir la ruta el la otra punta usando webmin:
He añadido una ruta estática, con la interface eth0 (no me ha dejado seleccionar la interface de la vpn, no se porqué), la ruta 192.168.111.0 mascara 255.255.255.0 y la gateway 192.168.111.222. Cuando he aplicado cambios me he quedado sin acceso por ssh.
Me ha tocado ir y borrar la ruta a mano. Que burro. La próxima prueba la hago con el de mi casa y así lo tengo más cerca en el caso de que tenga que deshacer el entuerto.
Voy a leer un poco a ver como tengo que hacerlo.

Muy bueno este tinc. Combinado con Dundi puede ser muy interesante para instalaciones en varias sedes.
Pero parece que OpenVPN se ha llegado el gato al agua. El desarrollo de tinc y su uso parece poco extendido.
En el canal de #tinc de freenode me he matido 2 o 3 veces y solo hay una persona.
Es una pena.

Muchas gracias de nuevo por tu ayuda y por tu gran aporte al mundo de la VoIP en los paises de habla hispana.

Comment by ramoncio — 6 January 2008 @ 17:18
Creo que tengo algo mal en la ruta del script tinc-up. En tu ejemplo no ponías nada de crear la ruta, se supone que la crea automáticamente, pero a mi no me funcionaba así.
Para empezar, cuando compilé tinc, se instaló en /usr/local y los ficheros de configuracion los buscaba en /usr/local/etc
Por eso estuve leyendo el manual de tinc y algunas webs que trataban el tema.
Basé la mayoría de lo que hice en ésta página:
http://mia.ece.uic.edu/~papers/volans/tincd.html

[root@pbx ~]# cat /usr/local/etc/tinc/casitasolid/tinc-up
#!/bin/sh
# Set hardware ethernet address, needed on Linux when in router mode
ifconfig $INTERFACE hw ether fe:fd:0:0:0:0
# Give it the right ip and netmask. Remember, the subnet of the
# tap device must be larger than that of the individual Subnets
# as defined in the host configuration file!
ifconfig $INTERFACE 192.168.160.222 netmask 255.255.255.0
# Disable ARP, needed on Linux when in router mode
ifconfig $INTERFACE -arp
#Add a route to the other network
route add -net 192.168.111.0 netmask 255.255.255.0 dev $INTERFACE

[root@pbx ~]# ip route show
192.168.160.0/24 dev eth1 proto kernel scope link src 192.168.160.222
192.168.160.0/24 dev casitasolid proto kernel scope link src 192.168.160.222 (SOBRA??)
192.168.111.0/24 dev casitasolid scope link (FALTA ALGO??)
169.254.0.0/16 dev eth1 scope link
default via 192.168.160.200 dev eth1

Cuando se establece la vpn sólo puedo acceder a los servidores tinc. De cada uno puedo hacer ping al otro sin problemas. En los 2 nodos tengo jazztel 20mb con dyndns y parece que la vpn va perfectamente. Cuando cambia la ip pública, se vuelve a establecer el tunel en segundos.

Segun mi tinc.conf el dispositivo de la vpn es /dev/net/tun:

[root@pbx ~]# cat /usr/local/etc/tinc/casitasolid/tinc.conf
Name = casita
Device = /dev/net/tun
ConnectTo = solidpc
#PrivateKeyFile = /usr/local/etc/tinc/casitasolid/rsa_key.priv

Pero mira de lo que me he dado cuenta:

[root@pbx ~]# ifconfig /dev/net/tun
/dev/net/tun: error fetching interface information: Device not found

[root@pbx ~]# cat /dev/net/tun
cat: /dev/net/tun: File descriptor in bad state

[root@pbx ~]# ls -la /dev/net/tun
crw——- 1 root root 10, 200 Jan 6 05:16 /dev/net/tun

Igual están mal los permisos de /dev/net/tun ???

Voy a ver si aprendo algo más de las rutas de paso…

Comment by ramoncio — 6 January 2008 @ 18:55
Por fin funciona todo perfectamente.
He releido tus instrucciones y me he dado cuenta que me faltaba añadir las rutas en los routers.

192.168.0.0 netmask 255.255.0.0 gw 192.168.160.222
y
192.168.0.0 netmask 255.255.0.0 gw 192.168.111.222

Muchas gracias!!!

Comment by ramoncio — 7 January 2008 @ 0:18
Ramoncio, me alegro que ya lo tengas funcionando. De cualquier modo, unas aclaraciones:

En el fichero tinc-up que pongo como ejemplo, fíjate que se da de alta el interfaz tun0 con la IP del interfaz eth0, _pero_ con una máscara de subred 255.255.0.0.

Esto simplifica las cosas, porque si un paquete va dirigido a nuestra subred (de clase C), se resuelve por ARP, pero si va a otra subred, se enruta por el interfaz tun0.

# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0

Nota: He omitido el resto de rutas (salida a internet).
br0 es el interfaz de red local (Como es un WRT54G, es el bridge entre el interfaz de red cableada y la inalámbrica).

Comment by julianjm — 7 January 2008 @ 12:04
Una pregunta, como podria unir 2 redes que posean las misma subred???

Ej: LAN1-server-router-router-server-LAN2

LAN1 y LAN2 : 192.168.100/24

espero help…

Comment by sky — 11 November 2008 @ 1:52
Poderse sí se puede… pero pierdes control sobre lo que pasa entre redes.

http://www.tinc-vpn.org/examples/bridging

Además, estarás reenviando por internet todos los paquetes de broadcast, y si tienes muchos equipos, puede ser un ancho de banda considerable…

Julián

Comment by julianjm — 11 November 2008 @ 9:36
Correcto, pues serian en total 20 PC, 10 por cada server… ahora tengo creo un inconveniente los server utilizan interfaces virtuales (eth0 y eth0:0)… crees que funcione igual el bridge? yo antes usaba vpn entre 2 subredes diferentes y todo ok, pero hace un tiempo llego una orientacion pues las subredes son iguales solo cambian los ip wan…creo que en esta situacion no podre lograrlo…

eth0 Link encap:Ethernet HWaddr 00:30:4F:4C:50:97
inet addr:x.x.x.x Bcast:x.x.x.x Mask:255.255.255.252

eth0:0 Link encap:Ethernet HWaddr 00:30:4F:4C:50:97
inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0

Comment by sky — 11 November 2008 @ 22:10
El bridge lo hace a nivel de interface, así que el bridge sería de eth0 completo (alias incluidos)… Como el bridge funciona a nivel de MACs, cuando el tincA no encuentre la MAC en una red, hará el broadcast a la otra.

En principio no deberías tener problemas. El único problema que podrías tener es que al intentar acceder a la otra red a través de su IP pública, seguramente pase por la VPN, aunque habría que probar y ver cómo se comporta.

De cualquier modo, es extraño cómo tienes montado los servidores. Entiendo que en el mismo segmento de red tienes conectado el router ADSL en monopuesto y la red local. Yo pondría una tarjeta de red adicional y que el equipo hiciese de router entre la red local e internet.

Julian.

Comment by julianjm — 20 November 2008 @ 11:06
felicitaciones y gracias por el articulo, justo me cae del cielo por que estoy por implementar una red grande con varias sedes y estaba quebrandome el cebrero de como podia hacerlo con openvpn. bueno ya les comentare mas adelante como me fue.

Comment by Cesar — 1 February 2009 @ 5:55
Julián, buenas tardes,

Hace tiempo comentaste algo sobre Tinc en la lista de Asterisk y ahora estoy viendo la posibilidad de implantar una VPN full-mesh.

Bien, he estado leyendo el articulo y sus comentarios, pero parece que hace bastante tiempo que no se mueve y me surgen algunas dudas en si usarlo o no…

¿Sigues recomendando y usando TINC frente a otras soluciones como OpenVPN o …?

Saludos,

Ramses

Comment by Ramses — 18 October 2009 @ 15:40
Julián, buenas tardes,

Hace tiempo comentaste algo sobre Tinc en la lista de Asterisk y ahora estoy viendo la posibilidad de implantar una VPN full-mesh.

Bien, he estado leyendo el articulo y sus comentarios, pero parece que hace bastante tiempo que no se mueve y me surgen algunas dudas en si usarlo o no…

¿Sigues recomendando y usando TINC frente a otras soluciones como OpenVPN o …?

Saludos,

Ramses

Comment by Ramses — 18 October 2009 @ 15:42
Hola Ramses,

Yo sigo con la instalación por la que hice el post, y de momento sin queja.

Es una VPN de 6 nodos, 4 de ellos en routers WRT54 con OpenWRT… Alguna vez he tenido problema de memoria (tienen muy poca estos cacharros), pero parece ser que ya está solucionado en la última versión.

Si no es un problema que todo el tráfico pase por el servidor (a modo de estrella), yo tiraría por openVPN. Si esto es inviable, Tinc.

Julián.

Comment by julianjm — 19 October 2009 @ 11:50
Julián, muy buenas,

Pero pongamos por ejemplo que tienes un Asterisk en cada una de las sedes.

Para hablar o transferirse llamadas entre ellas, si tenemos un VPN Server único, tendrían que bajar la llamadas hasta ese y a continuación ir al Asterisk que corresponda. ¿No ves mejor opción la de Tinc que planteabas?.

Parece que el proyecto se esta volviendo a mover…

Saludos y gracias,

Ramses

Comment by Ramses — 19 October 2009 @ 12:08
Hola Ramses…

Si trabajamos con IP’s locales, con un servidor VPN centralizado (tipo openvpn), efectivamente, el stream RTP pasaría sí o sí por el servidor VPN/asterisk, da igual cómo esté configurados los parámetros “canreinvite” y “nat”.
Si son pocas oficinas, siempre puedes poner enlaces punto a punto con openvpn entre cada par de sedes… aunque cada una que añadas, se incrementará exponencialmente la complejidad

Con tinc, si asterisk está bien configurado, el RTP se enrutará directamente de sede a sede, sin pasar por el servidor central.
Por supuesto, no puedes grabar las llamadas, ni utilizar ninguna opción que necesite acceder al stream de RTP… ni siquiera escuchar DTMF (salvo que uses sIP INFO).

Julian.

Comment by julianjm — 22 October 2009 @ 8:06
Julián, gracias por responder.

Creo que lo que me has contestado es teniendo en cuenta que hubiese un único Asterisk, ¿no?.

Pero yo te planteaba que en cada sede hay un Asterisk y con sus trunks IAX2 pertinentes a los otros.

¿Tirarías con Tinc?

Saludos y gracias,

Ramses

Comment by Ramses — 22 October 2009 @ 8:45
Si tienes 3 oficinas, con un asterisk en cada una, unidos por iax2, creo que activando transfer=yes, la trama IAX irá entre las dos centralitas implicadas. Habría que comprobarlo, y no se si funcionaría también con iax trunking. Pregunta en asterisk-es a ver

La VPN solo te haría falta para encriptar las comunicaciones, y podría añadirse posteriormente.

Julian.

Comment by julianjm — 22 October 2009 @ 8:59
Julián, buenas de nuevo,

Si montado está, el tema es que está a “guevo” por Internet y lo que quiero es meterlo sobre una VPN, por eso lo de TINC, ¿entiendes?.

Claro, si monto un centro de estrella, te he puesto un ejemplo con los Asterisk, las comunicaciones del centro tendrían que ser bastante más gordas si se accede a recursos distribuidos que si solo se accediera a recursos que se encuentren en el punto central…

Ahora son 3, pero en un futuro próximo se parecerá mucho a lo que tú montaste.

La duda es más, como el artículo es de bastante atrás, si ahora volverías a usar Tinc para montar esa historia o habías cambiado tu confianza a otro producto.

Saludos y gracis,

Ramses

Comment by Ramses — 22 October 2009 @ 10:40
Sí, lo volvería a montar igual, principalmente porque no me ha dado ningún problema (salvo algún cuelgue puntual, causado por un bug corregido y la escasa memoria de los wrt54g).

Y más aún si hay previsión de que puedan añadir más nodos a la red

No he investigado sobre el tema desde que hice este post, así que no se si hay nuevos productos que soporten conexiones directas entre nodos

Julián.

Comment by julianjm — 22 October 2009 @ 10:47
Ok, muchas gracias.

Ramses

Comment by Ramses — 22 October 2009 @ 11:02
Julian, buenas tardes,

Una duda:

- En la creación del interface tun pones máscara 16 en vez de 24, ¿se te ha ido la mano o es así por algún motivo?

Saludos y gracias,

Ramses

Comment by Ramses — 22 October 2009 @ 19:05
Julián, otra duda,

¿Con los ficheros de claves publicas y privadas no hay que hacer nada con ellos?, ¿no hay que cruzarlos entre las sedes?, ¿en algún directorio?.

P. D.: Je, je, te prometo que cuando acabe te paso todas las anotaciones/joutu de la instalación con la versión que estoy montando…

Saludos y gracias,

Ramses

Comment by Ramses — 22 October 2009 @ 20:13
Respecto a la red… La VPN en gneral será una red /16, es decir 192.168.*.*.

Cada sede será una red de clase C: p.ej. 192.168.5.*

Del enrutamiento se encarga el demonio tinc… ya que cada nodo sabe qué subredes controlan el resto.

Y respecto a los ficheros de claves, la clave privada (rsa_key.priv) se queda en el nodo donde se generó. Y la pública es la que va en hosts/NODOX, junto con su configuración. Es ese fichero, hosts/NODOX, el que luego replicas al resto de nodos, para que se conozcan entre sí.

Julián.

Comment by julianjm — 22 October 2009 @ 20:57
Julián, muy buenas,

¿Habría alguna forma de conseguir la última versión de Tinc 1.0.10 en formato ipkg para probarlo en los routers?

Lo digo por probar las últimas versiones…

P.D.: Ya cumplí con lo que te prometí…

Saludos,

Ramses

Comment by Ramses — 6 November 2009 @ 20:01
Sorry, es la Tinc v.1.0.11

Saludos de nuevo,

Ramses

Comment by Ramses — 6 November 2009 @ 20:02
Hola Ramses..

Perdona el retraso

He visto el documento, y tiene muy buena pinta.. Si quiere lo cuelgo o lo enlazo en este post.

Julián.

Comment by julianjm — 6 November 2009 @ 23:05
Ok, Julián, si crees que puede ayudar a alguien, por mi no hay inconveniente, además, como vamos a medias en la info que va dentro del documento…

Además, si quieres, cuando pruebe la versión nueva del Tinc en los routers, si podemos tener, también se puede meter en el documento y lo acabamos de completar.

Saludos y gracias,

Ramses

Comment by Ramses — 8 November 2009 @ 10:46