Cluster para Novatos Parte I : Keepalived + Asterisk / Kamailio

16 Jul

En los siguientes artículos  voy a abordar diferentes aspectos para clusterizar o mejorar el comportamiento en alta disponibilidad con Asterisk y Kamailio.

Tradicionalmente para disponer de una ip de servicio que balancea automáticamente entre dos máquinas, una activa y otra pasiva , o activo-activo, se ha usado pacemaker y corosync, incluso en algunos casos ucarp. Estos proyectos cierto es que han sido empleados mucho en el pasado pero hoy en día , keepalived es un proyecto que está creciendo bastante y merece la pena  empezar a usarlo en estas arquitecturas. Usa el protocolo VRRP empleado en alta disponibilidad en red como routers, mikrotik y similares.

En debian simplemente tenemos que instalar los paquetes con apt-get

apt-get install keepalived

También nos hará falta instalar sipsak que luego veremos para que nos servirá.

apt-get install sipsak

Para el buen funcionamiento deberemos cambiar algunos parámetros de sysctl , algunos relacionados con ARP para que cuando haya un salto se encaminen las peticiones lo antes posible a la máquina activa y otros para permitir bindear Asterisk a ips que no tiene (la activa).

Editaremos /etc/sysctl.conf

net.ipv4.ip_nonlocal_bind = 1

net.ipv4.conf.all.arp_ignore = 3
net.ipv4.conf.all.arp_announce = 2

y aplicaremos los cambios con:

sysctl -p

Una vez hecho esto ya configuraremos el keepalived /etc/keepalived/keepalived.conf de cada uno de los nodos:

vrrp_instance cluster{

state MASTER

interface eth0

virtual_router_id 01

priority 100

nopreempt

advert_int 1

virtual_ipaddress { IP.SER.VI.CIO/24 dev eth0   label eth0:1 }

track_script { comprobar_sip }

notify_master “/etc/keepalived/estado.sh MAESTRO “

notify_backup “/etc/keepalived/estado.sh BACKUP “

}

Para provocar el salto cuando Asterisk o Kamailio no responda usaremos un script comprobar_sip, que empleará el sipsak como antes comentábamos.

vrrp_script comprobar_sip {

script “/etc/keepalived/comprobar_sip.sh”

interval 10 # se comprueba cada 10 segundos

fall 3 # Si falla 3 veces consideramos caído

rise 5 #Exigimos 5 veces para OK

}

El script en cuestión comprobará si responde Asterisk. En el caso de Kamailio hay que tener cuidado y que responda a los OPTIONS y en Asterisk que el contexto entrante por defecto tenga la extensión en cuestión (s)

[entrantes]

exten => s,1,Noop

Para que no tengamos problemas.

Crearemos el script comprobar_sip.sh como sigue:

#!/bin/bash

sipsak -s sip:s@IP_SERVICIO:5060

if [$? -ne 0 ] ; then

exit

else

exit 0

fi

Y crearemos el script estado.sh

#!/bin/bash

STATE=$1

case $STATE in

“MAESTRO”)

service kamailio start || service kamailio restart

exit 0

;;

“BACKUP”)

service kamailio stop

exit 0

;;

esac

En el otro nodo haremos lo mismo pero intercambiando las IPS en el script comprobar_sip.sh y

….

state BACKUP

virtual_router_id 01

priority 99

….

en la configuración de keepalived.conf

International SIP Conference 2009

2 Feb

Victor Pascual ívila estuvo en el pasado International SIP Conference. He aquí­ su resumen del evento:

“Los pasados 20-23 de enero tuvo lugar la décima edición de la
International SIP conference de Parí­s. Podéis encontrar el programa en
http://www.upperside.fr/sip2009/sip2009intro.htm

Con un sorprendente descenso en el número de participantes (muy lejos
quedan las sesiones multitudinarias con más de un centenar de
participantes) las principales temáticas fueron la integración de SIP
con la Web2.0 (a la que algunos llaman RIA), P2PSIP y casos de uso de
SIP más allá de la VoIP.

A destacar… las excelentes presentaciones de Henning (emergency
services), Henry (RIAs) y Gonzalo (IMS) :-)”

Gracias Victor por el Update!

Ono VoIP

11 Nov

He recibido una filtración de que ONO podrí­a lanzar VoIP a finales de año o principios de 2008.

La verdad es que es hora de que los operadores de Cable ofrezcan VoIP, que es la tecnologí­a natural para ellos.

Como le pongan filtros como a sus lí­neas… 🙂

Problema de seguridad en SIP

5 Nov

Me lo recordaba Iñaki, pero lo habí­a visto en voipsa ayer.

Según comentan , existe un potencial problema de seguridad en la autenticación de SIP.

Todos los dispositivos son vulnerables en un escenario usando reinvites.

El escenario es el siguiente:

El atacante realiza una llamada a la ví­ctima (directa), la ví­ctima le responde . El cómplice llama a la ví­ctima y la ví­ctima decide poner al atacante en espera. Al ponerle en espera le enví­a un re-invite al atacante. Mientras tanto el atacante llama al número al que quiere llamar gratis, el atacante le pide a la ví­ctima que autentique el re-invite , el atacante usa el mismo “Digest Access Authentication” que ha recibido del proveedor para mandarle la respuesta al INVITE de la llamada que quiere cursar gratis, y al enviar el atacante los datos al proxy , el sistema del billing del proveedor, se la carga a la ví­ctima.

Atacante, Ví­ctima están registrados en el proveedor.

Soluciones: No permitir reinvites, sólo permitir tráfico del proxy.

PD: Suena a trabalengí¼as, pero tiene toda la lógica del mundo. Eso si hace falta saber un poquillo de SIP.

OpenXCAP

2 Sep

EL Protocolo XCAP permite a un cliente, leer, escribir y modificar configuraciones de dispositivos almacenadas en formato XML en un servidor (similar al provisioning de Linksys). XCAP clasifica documentos XML en urls HTTP, tal que estos componentes pueden ser accedidos de forma sencilla mediante protocolo HTTP. Un servidor XCAP es usado por clientes XCAP para almacenar información como la polí­tica de presencia que en combinación con un Proxy SIP que soporte los métodos PUBLISH/SUBSCRIBE/NOTIFY ofrezcan una solución SIP SIMPLE completa.

Más información en la página del proyecto.

Ví­a voip-info