OpenVPN y el codec g729

Para los que trabajamos con telefonía IP es bien conocido que el codec g729 es uno de los más populares debido principalmente a que comprime el audio a 8 kbps lo cual permite un uso eficiente del ancho de banda disponible.  Aunque existen otros que realizan la misma función y al mismo tiempo son gratis (ej. Speex), con mucha frecuencia la única opción es g729 ya que es el más soportado por los proveedores y es el que viene incluído en la gran mayoría de los equipos de hardware usados en voz sobre IP.

Pues bien, hace unos días le compré a Digium una licencia de g729 para Asterisk, la cual brinda un máximo de dos registros posibles.  La instalación fluyó perfectamente, hice las pruebas pertinentes y efectivamente pude usar el codec satisfactoriamente.  Luego dejé a un lado el asterisk y le apliqué una actualización al sistema CentOS y más adelante comencé a hacer pruebas de enrutamiento con OpenVPN instalado en el mismo servidor, lo cual condujo a varios reinicios del servicio OpenVPN y del propio servidor.  Finalmente, todas las rutas funcionaban como se esperaba, pero … las llamadas ya no funcionaban.

Al revisar las trazas noté un par de aspectos relevantes: primero, la interfaz de red eth0, aparecia renombrada como eth1; segundo, la traza de las llamadas mostraba error de codec y el comando “g729 show licenses” en el CLI de Asterisk informaba que no encontró licencias válidas en el sistema ya que la existente tenía “incorrect host-id”.  Me las agencié para resolver el primer problema de lograr que volviera a nombrar la interfaz como eth0, pero aún así continuó el error.  Luego de contactar al soporte técnico de Digium, me informaron que el host-id de la licencia se calcula basado en:

  • Las direcciones MAC y los nombres de todas las interfaces de red presentes en el sistema (incluídas las virtuales de OpenVPN).

Como ya tenía las interfaces con sus nombres originales, entonces solo quedaba por revisar las MAC, la interfaz física no podía cambiar la suya, asi que solo quedaba la tap0 correspondiente a la VPN.  Luego de repetir un par de veces “service openvpn restart”  e  “ifconfig”  me di cuenta que openvpn asigna una nueva dirección MAC aleatoria a la interfaz virtual cada vez que se levanta el servicio, así que la solución consistía en lograr que siempre asigne la misma MAC.

Revisando un poco la documentación encontré que existe una forma de lograr esto y consiste en incluir en server.conf, client.conf o como se haya nombrado el archivo de configuración la siguiente directiva:

lladdr 56:37:67:A0:47:BC

donde el parámetro es por supuesto la MAC que se desee asignar.  Lo mejor es copiarlo de la última configuración válida generada disponible a través de “ifconfig” (hwaddr).

Aquí se los dejo y creo que pudiera aplicarse en otros casos más generales de servicios dependientes de la dirección MAC donde al mismo tiempo esté involucrada OpenVPN. Importante: según la documentación, este parámetro solo funciona en Linux, pero supongo que en Windows existan otros métodos de fijar la MAC de una interfaz virtual.

OpenVPN en Centos

Durante los últimos dos meses me he encontrado repentinamente al menos en cuatro ocasiones ante la necesidad de instalar OpenVPN en Centos. Siempre ha sido un requerimiento de alguna tarea más grande o más “importante”, algo como para no perder el tiempo en ello. Sin embargo, el repositorio oficial de Centos no incluye el paquete de OpenVPN, lo cual nos obliga a ejecutar una serie de pasos adicionales. Aqui les dejo una guia de estos pasos que se les ahorrará tiempo a muchos y a mi mismo como referencia futura pues según las probabilidades pronto me tocará otra instalación de OpenVPN en Centos.

– Agregar estas líneas a /etc/yum.conf  para utilizar el repositorio Dag

[dag]
name=Repositorio Dag para Red Hat Enterprise Linux, Centos, Fedora
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1

– Instalar las llaves GPG para el repositorio Dag, de otra forma mostrará un error cuando se intente instalar un paquete.

cd /var/tmp
wget [archivo-correspondiente-a-mi-instalacion]
rpm -Uhv [archivo-correspondiente-a-mi-instalacion]
cat /etc/redhat-release

En mi caso particular, el último de los sistemas instalados fue CentOS release 5.5 (Final), luego el comando quedó asi:

cd /var/tmp
wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm
rpm -Uhv rpmforge-release-0.5.2-2.el5.rf.i386.rpm

Instalar las bibliotecas requeridas para OpenVPN:

yum install lzo lzo-devel zlib zlib-devel

– Y al final instalar OpenVPN:

yum install openvpn

Copiar para /etc/openvpn los archivos de configuración de muestra:

cp -r /usr/share/doc/openvpn-2.1.4/easy-rsa/ /etc/openvpn/
cp /usr/share/doc/openvpn-2.1.4/sample-config-files/server.conf /etc/openvpn/
cp -r /usr/share/doc/openvpn-2.1.4/easy-rsa/2.0/openssl /etc/openvpn

– Configurar como servidor o cliente: el programa es el mismo para ambas, la función es determinada por el contenido del archivo de configuración. Al final de los pasos anteriores OpenVPN se instaló como servicio, o sea, tiene ya un script en /etc/init.d  y en Centos se puede manipular asi:

service openvpn [start | stop | restart ]

Para arrancar el servicio cuando reinicie el servidor:

chkconfig openvpn on

El servicio lee cualquier archivo en /etc/openvpn con extensión .cnf e inicia el servicio basado en este.

– El próximo paso es crear los certificados y las llaves (en caso de ser servidor) y los archivos de configuración, lo cual no repetiré aquí pues está muy bien documentado en el sitio de openvpn .  Garantizar primero permiso de ejecución a los scripts en el directorio easy-rsa:

cd /etc/openvpn/easy-rsa/2.0
chmod +x clean-all
chmod +x build*
chmod +x vars
chmod +x whichopensslcnf
chmod +x pkitool

 

Configurar el servidor como un router a través de la VPN

– Primero activar el reenvio de paquetes: editar /etc/sysctl.conf y adicionar la linea:

net.ipv4.ip_forward = 1

El siguiente comando lo activa de forma inmediata pero no sobrevive a un reinicio:

 echo 1 > /proc/sys/net/ipv4/ip_forward
 

– Activar las reglas de NAT de iptables.  El siguiente ejemplo debe ajustarlo a su configuración específica, aqui se asume el siguiente escenario:

Subred OpenVPN:  10.8.1.1/24
IP local del servidor: 192.168.0.2
Subred local (LAN):  192.168.0.0/24
Gateway de la LAN: 192.168.0.1
DNS: 192.168.0.1

Desde el shell ejecutar:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -j SNAT --to 192.168.0.2
iptables -A FORWARD -d 10.8.1.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.8.1.0/24 -j ACCEPT

Guardar las reglas:

service iptables save

y asegurar que el servicio iptables se arranque automático al iniciar el servidor:

chkconfig iptables on

Listo!

Asterisk: integración con mysql

Una de las características más emocionantes de Asterisk es la posibilidad de integrarse con bases de datos externas (ej. mysql, postgreSQL, LDAP).  Los administradores de redes conocemos bien el valor de mantener la independencia entre el almacenamiento de los usuarios y el servicio en si mismo.

La instalación predeterminada de Asterisk no viene con la integración con mysql, sin embargo es muy fácil añadirla. Basta con descargar desde http://www.asterisk.org/downloads los complementos (addons) para la versión de Asterisk que estemos usando.  Para instalarlos:

#tar xzvf  asterisk-addons-1.6.2.2.tar.gz
# ./configure
#make menuselect
#make
#make install

La opción “menuselect” permite seleccionar los componentes de mysql necesarios para la integración con Asterisk. Para completar es necesario adicionar o modificar las siguientes lineas en dos archivos de configuración en /etc/asterisk:

extconfig.conf
——————
sipusers => mysql,general,cc_sip_buddies
sippeers => mysql,general,cc_sip_buddies

res_mysql.conf  (a partir de la version 1.8 de Asterisk este archivo se nombre res_config_mysql.conf)
——————-
[general]
dbhost = 192.168.0.10
dbname = dba2billing
dbuser = a2billinguser
dbpass = a2billinguser_password
dbport = 3306

Algunas aclaraciones:

  • Estas configuraciones son totalmente flexibles, tanto que en ocasiones tienden a confundir dada su generalidad o tienden a ser aplicadas de forma totalmente mecánica.
  • sipusers y sippeers representan las definiciones de las cuentas de asterisk (extensiones), las que de otra forma tendrian que ser definidas en un archivo texto en /etc/asterisk/sip.conf.
  • El primer parámetro (mysql) indica precisamente que estas cuentas se encuentran en una base de datos mysql.
  • El segundo parámetro “general” puede ser cualquier nombre definido por el administrador, la única condición es que debe ser el mismo que da nombre al contexto definido en res_mysql.conf  (  [general]  Es el enlace entre ambos archivos.
  • El tercer parámetro (cc_sip_buddies)  es el nombre de la tabla que contiene las cuentas dentro de la base de datos mysql especificada. Este nombre puede ser también cualquiera que decida el diseñador de la base de datos.  El requisito de esta tabla es que los nombres de los campos deben coincidir con los nombres de los parámetros de configuración de los sip users en sip.conf, mas información en http://www.voip-info.org/wiki/view/Asterisk+RealTime+Sip.
  • La explicación anterior es válida igualmente con las modificaciones obvias para definir clientes IAX.

Listo!  De esta forma tenemos independencia absoluta entre la gestión de telefonía que desempeña Asterisk y la administración de usuarios.  Por ejemplo, el servidor de Asterisk se puede encontrar en mantenimiento y los agentes pueden continuar con sus tareas rutinarias de actualización, facturación, etc.  Siguiendo la línea del mantenimiento, es muy fácil conectar al sistema un Asterisk de respaldo o emergencia sin siquiera tener que hacer una restauración de la base de datos.  Esta separación permite al mismo tiempo el desarrollo en paralelo de un sistema de facturación y contabilidad totalmente independiente de Asterisk con administradores (probablemente diferentes de los de Asterisk), agentes de ventas, etc:  fallas en este sistema de gestión no afectan el funcionamiento de la actividad teléfonica normal, excepto quizás … uhmmm fallas de seguridad … pero eso es tema para otro post o grupo de posts, la vulnerabilidad/seguridad de los sistemas VoIP es uno de los más candentes en la actualidad.

Por último, si no cuenta con el tiempo, los recursos o los conocimientos para desarrollar un sistema de facturación para Asterisk, en la web se encuentran varios muy buenos y gratis.  El nombre “a2billing” usado en el ejemplo no es casual, http://www.asterisk2billing.org es uno de los más maduros, corre sobre plataforma LAMP e instrumenta un sistema de tarjetas telefónicas, permite las modalidades prepago y postpago.   Trae un conjunto de tablas predefinidas en mysql que permiten la integración explicada anteriormente liberándonos al mismo tiempo de tener que crear un diseño nuevo de la base de datos.

En teoría usando Asterisk y a2billing es posible instrumentar cualquier solución imaginable de telefonía. Al ser una plataforma de código abierto, si aparece un requerimiento nuevo no implementado, siempre es posible adicionarlo.  La instalación es relativamente simple para alguien con cierta experiencia con Linux y sus amigos (apache, mysql, etc) … no es una instalación “apunta y click”.  Los autores de a2biling se dedican al mismo tiempo a ofrecer consultoría, asesoramiento e instalación del soft y estoy de acuerdo con el consejo que dan a los clientes: si Ud. va a contratar a alguien para que le instale una solución de telefonía IP, investigue primero, asegúrese que tenga la experiencia necesaria, o de lo contrario serán mayores las pérdidas que el ahorro que va a tener por usar esta novedosa tecnología.

Actualización: lo anterior es válido también para IAX friends, basta adicionar las siguientes líneas a extconfig.conf:

iaxusers => mysql,general,cc_iax_buddies
iaxpeers => mysql,general,cc_iax_buddies