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. |
Comments (48)Tags:
full mesh,
tinc,
VPN
En asterisk, el parámetro “canreinvite=yes” en sip.conf a la hora de definir un dispositivo SIP, indica la disponibilidad de dicho dispositivo a aceptar tráfico RTP directamente desde el otro dispositivo involucrado en la llamada, sin que asterisk tenga que estar en medio de la comunicación, reenviando la información de uno a otro.
En una red local, no hay gran problema… cualquier red que se precie usa cable CAT5 y switches 10/100… más que de sobra como para que afecte ese extra de paquetes circulando. Sin embargo, cuando tenemos un asterisk en una sede, y varios teléfonos SIP en otra sede distinta (conectados mediante ADSL, por ejemplo), la cosa cambia.
El ancho de banda de una ADSL es asimétrico, y aunque tengamos 3 “megas” de bajada, la subida no suele pasar de unos míseros 320kbs (bits, no bytes). De ahi que sea un recurso muy valioso, como para malgastarlo cuando no es realmente necesario. Con este ancho de banda, podemos mantener unas 10 conversaciones con el códec G729, y unas 3 con G711. (Usando esta calculadora de ancho de banda)
Un caso típico
Imaginemos el siguiente escenario:
- Un servidor asterisk en la sede central
- Teléfonos SIP en la sede A (A1,A2,A3..An). Todos ellos configurados con nat=yes.
- Otros tantos en la sede B (B1..Bn).También con nat=yes.
- En ninguna de las dos sedes se abren puertos hacia los diferentes teléfonos.
Si impedimos el tráfico de paquetes de voz (RTP) directo entre teléfonos (canreinvite=no), al hacer una llamada interna, desde A1 a A2, habría dos flujos de paquetes:
- Desde A1 hasta el servidor asterisk, y desde aquí de vuelta a A2
- Justo el camino contrario, ya que la comunicación es full-duplex.
Fíjemonos que para una simple conversación entre extensiones, estamos utilizando nuestra conexión ADSL por partida doble. Estamos utilizando 2 de las llamadas simultáneas disponibles con nuestra humilde conexión a internet.
En una llamada desde A1 a B1 pasaría lo mismo, salvo que en este caso es lo que esperamos. A1 y B1 están en sedes distintas, y no hay forma de que se pueda establecer una comunicación directa entre ambos dispositivos. Lo que queremos es que asterisk haga de enlace entre ambos. Cada sede estará gastando un canal de los que tenga disponible.
Queremos evitar este consumo innecesario de ancho de banda cuando los dos teléfonos pueden establecer una comunicación RTP directa. Para ello, activaremos “canreinvite=yes” en la configuración de todos los dispositivos. Repetimos el experimento.
Llamamos desde A1 a A2. Asterisk, que hace de intermediario, indica a A1 que envíe su tráfico RTP a la dirección de A2, y hace lo propio con A2. Las direcciones IP utilizadas son las IP’s locales de cada teléfono (192.168.0.x, por ejemplo), y no la IP pública de la ADSL de la sede.
El beneficio es palpable, mientras asterisk se encarga de la señalización (indicando cuando un teléfono cuelga, cuando se hace una transferencia, etc), el tráfico RTP de voz va directamente de un teléfono a otro, sin salir a Internet en ningún momento, y sin gastar ningún canal.
Pero todo tiene un “pero”. Al hacer una llamada desde A1 a B1, asterisk también indicará a los dispositivos que se envíen el tráfico RTP directamente entre ellos. El problema está en que, al utilizar las IP’s privadas y ser dos redes distintas, separadas, que podrían incluso compartir la misma dirección de red, la llamada se establecerá pero no habrá audio en ningún sentido. Mal asunto.
¿Por qué? En la actualidad, cuando ambos dispositivos están configurados con “canreinvite=yes”, asterisk obedece y siempre que puede intenta que se envíen el tráfico RTP entre ellos directamente. Lamentablemente, cuando están en redes distintas, es imposible. La solución estaría en comprobar, cuando los dispositivos están detrás de routers haciendo NAT, si la dirección IP pública de ambos coincide. Si fuese el caso, podremos estar seguros de que están en la misma red, y podrán encontrarse. Si la IP pública es diferente, asterisk simplemente debe quedarse en medio.
Las llamadas dentro de cada sede funcionarán bien, sin malgastar ancho de banda de la ADSL, mientras que las llamadas entre sedes pasaran a través de asterisk.
Una solución
Y después de esta soberana paliza (que no se cuántos habréis aguantado), os dejo aquí el parche para la revisión r79171 del svn de asterisk/branches/1.4.
Descargar asterisk_nat_rtp_recv_patch_v3.diff
Para aplicar
$ cd /usr/src/asterisk
$ patch -p0 < /ruta/a/asterisk_nat_rtp_recv_patch_v3.diff
$ make
$ make install
Añadimos natonlyreinvitesameip=yes a la sección [general] de nuestro sip.conf.
No he podido testear a fondo este parche, así que si alguien puede reproducir este escenario, agradecería comentarios sobre si funciona o si es una soberana estupidez
Es fundamental en los call centers, que cuando suena el teléfono del agente, se le abra un popup con la información del cliente que está llamando en ese instante. Hay varias formas de lograrlo, pero una de las más interesantes por su sencillez es utilizar el FOP (Flash Operator Panel), de Nicolás Gudiño.
De hecho, en la versión 0.27, ha incluido un nuevo control flash (comunicator.swf), que elimina la parte gráfica, y se convierte en un simple interfaz entre nuestro asterisk y el código javascript de nuestra página. Este control es ideal para integrar en aplicaciones CRM (Customer Relationship Management), como puede ser SugarCRM.
Lo que voy a mostrar en este post son los requisitos mínimos para que esto funcione. Voy a eliminar todo lo superfluo, de modo que sea más fácil de integrar con cualquier aplicación ya existente, que es lo que de verdad nos dará la utilidad a este sistema.
Instalar/Actualizar FOP a la versión 0.27
La última versión de FreePBX ya incorpora esta versión. Si no está instalada, tendremos que descargarnosla de http://www.asternic.org/, y reemplazar los siguientes ficheros:
- op_server.pl
- operator_panel.swf
- op_lang*
Tendremos que añadir unas líneas a op_buttons.cfg:
[AUTO/SIP/.*]
Context =${CONTEXT}
Extension=${CHANNEL}
Label =${CHANNEL}
Icon =1
Starting_Position=1
Server=1
Panel_Context=popup
Con esto crearemos un nuevo contexto (popup) para nuestro monitor de extensiones.
También añadiremos las siguientes líneas a op_server.cfg
[popup]
flash_dir=/var/www/html/popuptest/
De forma que nos guarde en ese directorio un fichero (variablesPOPUP.txt) con la información sobre nuestras extensiones.
Instalar los scripts
Creamos el directorio /var/www/html/popuptest y descomprimimos en él el siguiente fichero: popup-sample-v1.tgz
mkdir /var/www/html/popuptest
cd /var/www/html/popuptest
tar -zxvf /ruta/al/fichero/popup-sample-v1.tgz
Abrimos el navegador, y nos vamos a http://1.2.3.4/popuptest (sustituir 1.2.3.4 por la IP de vuestra máquina). Nos pide la extensión a monitorizar. En la siguiente página, si hacemos o recibimos llamadas en esa extensión, debería actualizarse en tiempo real su estado.
Si, además, queremos que en las llamadas entrantes se nos abra un popup a otra página, que nos haga por ejemplo una búsqueda en una base de datos, editamos el fichero monitor.php y definimos la variable popupurl:
var popupurl=null; //Si esta null, no haremos popup
popupurl="http://192.168.0.1/buscarnumero/find.php?q=";
Recargamos la página, y probamos a recibir una llamada. Si todo ha ido bien, y el navegador permite el popup, debería abrirnos la dirección http://192.168.0.1/buscarnumero/find.php?q=XXXXX, siendo XXXXX el número de teléfono que nos llama.
Conclusion
He intentado reducir el ejemplo a su mínima expresión, para que sea más sencillo adaptarlo a una aplicación real. La versión completa está en los fuentes del FOP. Revisad el fichero js/operator.js, porque ahí está el meollo de la cuestión
Saludos
Julián J. Menéndez
Como muchos habéis comprobado, cuando hacemos un reload desde la consola de asterisk, perdemos los parámetros answeronpolarityswitch, hanguponpolarityswitch y polarityonanswerdelay. Es decir, volvían a sus valores por defecto y ya no detectabamos los cuelgues remotos. Había además un problema con las llamadas entrantes en las que si nos colgaban rápidamente (antes de haber detectado completamente el callerid), asterisk ignoraba esa inversión y nos dejaba el canal activo (Gracias a SuD por el parche).
En un intento de no despistar a los que vienen desde los buscadores (que sois unos cuantos), el parche actualizado estará disponible en el post anterior, Nuevo parche polaridad para Asterisk 1.4
Actualización final (19-dic-2007): A punto para las navidades, han incluido finalmente el parche tanto en la rama 1.4 como el el trunk. La versión 1.4.16 ya lo trae incluido. Gracias a fidojones por el aviso en los comentarios ;)
Volvemos a la carga. Desde que actualizar a la 1.4.x he notado que en ocasiones las llamadas entrantes que colgaban mientras estaban en cola, llegaban a sonar en los teléfonos. Pasaba pocas veces, quizás recibo pocas llamadas ;), pero después de recibir correos apuntando en la misma dirección, me dispuse a revisar el amado y odiado chan_zap.c. (Por cierto, en openpbx^H^H^H^H^H callweaver lo están reescribiendo desde 0)Resulta que se revirtieron algunos cambios necesarios para que funcione bien en las líneas de Telefónica de España. Las llamadas entrantes, una vez que se descuelgan con Answer(), no detectan el cuelgue remoto. No ocurría lo mismo con las llamadas que no se han contestado aún.
En cualquier caso, aquí os dejo el parche. Si va bien, lo intentaremos meter de nuevo en el svn ;)Parche chan_zap.c rama 1.4 version4
Descargar chan_zap.c-1.4-polarity-v5.diff
Para aplicarlo:
$ cd /usr/src/asterisk$ patch -p0 < /ruta/al/chan_zap.c-1.4-polarity-v5.diff
A continuación, recompilar, reinstalar y reiniciar asterisk, probar si funciona, y dejar un comentario
Versiones anteriores:
Actualizado (5 horas después de la publicación) 
: Como casi siempre, las primeras versiones nunca fueron buenas… Al corregir este fallo, introduje otro con las llamadas salientes… Corregido en la versión 2 del parche.
Actualización (12 de mayo): Según confirme Jose L. Villalon en los comentarios, el parche también funciona con asterisk 1.2.18. Habrá que ver a partir de qué versión de asterisk es necesario parchear.
Actualización (25 de junio): Gracias a SuD, que nos comenta acerca de un parámetro, polarityonanswerdelay, que tiene un valor por defecto demasiado alto, y que podría traer problemas al ignorarse ciertos cambios de polaridad. Para resultados óptimos, añadir polarityonanswerdelay=1 a vuestro zapata.conf (antes de la línea channel=> correspondiente).
Actualización (29 de junio): Adaptado a asterisk svn r72609. No se pierden los valores de answeronpolarityswitch, hanguponpolarityswitch ni polarityonanswerdelay al hacer un reload. Se contenmpla la detección de colgado dentro de la rutina de detección de callerid, según parche proporcionado por SuD.
Actualización (19 de julio): Adaptado a asterisk svn r75893.
Actualización (20 de julio): He abierto el bug #10238 en bugs.digium.com, para intentar que incluyan este parche en el código de asterisk y no tener que parchear cada nueva versión. Si estás interesado, deja allí tu experiencia con el parche.
Sé que este post se sale un poco de la temática de este blog, pero me cabrea ver como intentan timar a la gente, y más si el timado soy yo.
Hace ya mucho tiempo que soy un escéptico en cuestiones de telefonía, y siempre desconfío… siempre hay trampa. Ayer “escuchando” la tele, oigo que movistar saca un nuevo plan de datos, al estilo Yoigo, en el que solo pagas 1€ al día, y sólo si te conectas. La verdad es que en el momento me hizo ilusión, poder tener una conexión de banda ancha cuando estoy fuera de casa (Yoigo es solo GPRS en Fuerteventura). Así que me dispongo a llamar a atención al cliente, y después de sonsacar a la operadora, que parece que no quería darme cifras concretas, me dice que la tarifa es 1€ por cada 10Mb, con un máximo de 10€ diarios.
Coño, de 1€ a 10€ diarios, hay una diferencia importante… tanta como que pasamos de 30€ a 300€ mensuales, si le damos un uso importante.
Y sí, en la web de movistar, después de profundizar un poco, te dan las condiciones reales, pero viendo esto, ¿qué pensaríais? Por si quitan ese anuncio, esto es lo que dice, literalmente:
Nueva tarifa diaria Internet Móvil
Conéctate donde quieras por 1€ al día.
Y si no te conectas, no pagas.
Vodafone, Orange, Yoigo… no sé cuál, pero la portabilidad está cerca.
Actualizacion 5 de junio de 2007: Parece que no soy el único que piensa igual
Escrito por
julianjm el 22/04/2007. |
Comments (4)
Lo que en principio iba a ser una simple puntualización en la lista de correo asterisk-es, se me convirtió en una parrafada inmensa, que paso a publicar en este humilde blog X-D
Una llamada en RDSI es una comunicación de datos 64kbps full duplex, es decir, 8Kb/s en cada sentido, e independientes, utilizando el codec G711a. O funciona, o no funciona, pero no produce eco por que se mezcle el canal de ida con el de vuelta. Así que realmente da lo mismo qué tarjeta RDSI utilices, si funcionan las llamadas de voz, tendrás exactamente el mismo tipo de eco, tengas una HFC de 1 puerto, o una OctoBRI. Ojo, que no hablo de tarjetas activas, con su DSP y demás florituras, sino de Billions y AVM Fritz! y similares. Continúa:
Leer más…
Escrito por
julianjm el 10/04/2007. |
Comments (2)Tags:
Eco,
RDSI
Cuando me cambié de piso, allá por noviembre, empecé a tener problemas de eco en las llamadas a través de la TDM. Nada había cambiado de puertas para adentro, así que supuse que este cambio se debía a que estaba a una distancia mayor de la central, o que el par de cobre no estaba en el mejor estado.
De cualquier modo, no era una situación sostenible, ya que era bastante molesto. Buscando un poquillo en google y voip-info.org (para variar), me encontré con esta página sobre fxotune http://www.voip-info.org/wiki/view/Asterisk+fxotune. Copio y pego:
fxotune optimizes the line characteristics of a TDM device to minimize the *source* of echo. This is generally referred to as ‘balancing the hybrid’ and is quite important in echo cancellation. Once the hybrid is properly balanced, software echo cancellers will work very nicely.
No soy teleco, pero ese balanceo del híbrido, viene a ser ajustar la impedancia (resistencia) del puerto FXO, para que coincida con la de la línea, y evitar que se refleje lo menor posible la señal enviada o recibida. Si estoy metiendo la pata hasta el fondo, hacédmelo saber jeje. También ajusta los coeficientes de eco, aunque aquí sí que estoy totalmente perdido.
Por cierto, las clónicas vienen configuradas con una impedancia fija (no configurable) de 600 ohmnios, que está bien para las líneas americanas, no así para las españolas y gran parte de Europa. Si tienes una clónica, no te molestes.
Leer más…
Muchas veces necesitamos “ver” el tráfico entre dos dispositivos SIP. Con un HUB es muy sencillo, ya que solo hay que usar que poner la tarjeta de red en modo promiscuo, pero cuando estamos conectados a un switch, se complica (pero no mucho).
Escenario:
Si estos 3 dispositivos estuviesen conectados a un HUB, solo tendríamos que ejecutar:
tshark -i eth0 -w captura.log ip host 192.168.0.201
Luego, ya con calma y desde otra máquina incluso, analizaríamos ese fichero de captura.
En cambio, si estamos en un switch, el tráfico entre el teléfono SIP y el router no “llega” a la máquina línux. En estos casos, una buena solución es el Arp Spoofing (en español), que consiste en engañar a ambos dispositivos, haciendoles creer que somos el otro, y luego reenviando los paquetes.
Es muy sencillo de implementar, con Ettercap. Ejecutamos el siguiente comando en un terminal:
echo 1 > /proc/sys/net/ipv4/ip_forward
ettercap -o -T -P repoison_arp -M arp:remote /192.168.0.254/ /192.168.0.201/
Es importante activar el ip_forward, ya que de otro modo, los paquetes no se reenviarían a su destino original. Mientras se ejecutar el ettercap, todo el tráfico que exista entre esos dos dispositivos, pasará por nuestra máquina, y podremos capturarlo y analizarlo, con el comando que vimos antes (tshark -i eth0….)
Actualización 11-enero-2007: Hay que activar el ip_forward en nuestra máquina, para que nuestro equipo reenvíe los paquetes a su destinatario real.
Una pasarela email a fax (mail2fax) permite enviar faxes a través del correo electrónico. Por ejemplo, envías un email a 92800000@fax.tudominio.com, con un adjunto en formato PDF. La pasarela leerá ese PDF, y te lo enviará al número de fax 9280000. También te llegará por email la notificación de estado (enviado, reintentando, etc).
Algunas pasarelas mail2fax:
Requisitos
- Un subdominio (fax.dominio.com)
- Un servidor Postfix (Se agradecerán las instrucciones para sendmail)
- Hylafax ya instalado y funcionando. Podéis echar un vistazo a esta página para integrarlo con Asterisk
- Paciencia
Leer más…
