Flickr de Sharky
Muchas veces, cuando pedimos soporte para un producto que no funciona como hubiéramos deseado o que tiene un comportamiento especial, siempre aparece un requerimiento que a más de uno le da cierto reparo, y este es «enviar una traza» con la información de red. Una traza es una captura de todo el tráfico de red que se envía y se recibe entre dos o más puntos de la red (un teléfono, un ordenador, un router, etc.) de forma que se pueda ver qué se envía y se recibe, lo que nos ayuda a ver el contexto en el que se encuentra el dispositivo que estamos estudiando.
Hay muchos tipos de trazas: trazas de red (donde se ven todos los protocolos, todos los datos, todo de todo), una traza SIP donde se filtra todo el tráfico y se obtienen únicamente los paquetes SIP, o de cualquier otro protocolo. Sea como sea, una traza nos permite ver el pasado, pudiendo ver qué se ha enviado y qué se ha recibido, por lo que suele ayudar a entender el comportamiento.
Un ejemplo puede ser un teléfono que se bloquea sin más y de forma aleatoria. Tras sacar una traza de todo el tráfico de red que entra y sale de ese teléfono, podemos ver que la existencia de un paquete que no debía ser enviado y que en esa versión de firmware del teléfono la llegada de ese paquete provoca ese bloqueo.
Switches, el enemigo de las capturas
Antiguamente, cuando se utilizaban «hubs», obtener una traza era algo bastante sencillo, ya que cualquier ordenador conectado a un hub recibía el tráfico que pasaba por otros puertos. De esa manera, si queríamos ver lo que se enviaba entre dos ordenadores, basta con abrir un programa de captura de paquetes y recibiríamos también el trafico de otros puertos.
Actualmente, con el uso de switches, el tráfico entre dos sistemas conectados a un switch (por ejemplo, un teléfono y una PBX) únicamente es visible/capturable entre esos puertos, por lo que un ordenador conectado a otro puerto no debería recibir ningún paquete de la comunicación entre los dos sistemas implicados. Para ello, hay switches que permiten configurar un puerto como «mirror», reenviando todo el tráfico del switch a ese puerto y permitiendo que nuestro sistema conectado a ese puerto pueda recibir el tráfico y capturarlo.
También hay otros medios menos «oficiales» de capturar tráfico, es el conocido como sistema MITM (Man In The Middle) que consiste en que nuestro sistema le dice al switch que son ambos equipos, por lo que cuando el teléfono le envía un paquete a la PBX, el switch también se lo envía a nuestro ordenador, por lo que es como si nuestro sistema se pusiera «en medio» recibiendo todo el tráfico entre el teléfono y la PBX.
En el momento idóneo
Pero no solo es importante obtener una traza, también lo es obtener la traza del momento idóneo. De poco nos sirve una traza de 24 horas de tráfico si no sabemos cuando ocurrió lo que estamos buscando. Una traza suele ocupar bastante, (es el tráfico de red, por lo que se almacena toda la información que se transmite) así que una traza de 24 horas puede llegar a ocupar varios Gigas. Es importante tener la traza exclusivamente del momento en que se hacen las pruebas.
El tráfico importante
Una traza de TODO el tráfico de red tampoco es algo viable, es importante filtrar la información a lo que realmente nos interesa. En un teléfono SIP, un gateway SIP o un operador SIP, lo que nos interesa es únicamente el tráfico SIP. Incluso, puede que también el tráfico RTP, aunque no es lo habitual.
Herramientas para obtener trazas
WIRESHARK (antiguo Etherreal), una de las mejores herramientas en modo gráfico que existen, de las más completas y por lo tanto, de las más complejas de manejar. Las trazas obtenidas con esta aplicación suelen tener un formato bastante común PCAP, por ser el utilizado por otra aplicación llamada TCPDUMP (de hecho, PCAP viene de Packet Capture, una librería bastante común utilizada para capturar tráfico).
TCPDUMP es otra de las herramientas más conocidas para hacer capturas de tráfico, en modo texto y también software libre, nos permite capturar todo el tráfico entre el
No obstante, existen otras menos conocidas pero bastante útiles y rápidas ya que, para evitar tener que configurar un puerto en modo mirror o utilizar un sistema de ataque MITM, siempre podemos utilizar uno de los sistemas implicados para hacer la captura, por lo que necesitaremos herramientas ligeras, en modo texto y que nos permitan capturar el tráfico que nos interesa:
NGREP es una herramienta bastante conocida que con una serie de parámetros nos permite capturar el tráfico SIP: ngrep -d any -P ‘ ‘ -W byline -T port 5060
*Actualización*
HOMER es otra de las grandes en cuanto a captura de paquetes SIP, quizá una de las mejores y más utilizadas.
Gracias a @badcrc por recordárnoslo.
TSHARK es la versión «consola» del famoso Wireshark.
Gracias a Guillermo Henríquez por recordárnoslo.
Asterisk también incorpora un sistema que nos permite obtener el tráfico SIP, para ello, debemos escribir dos posibilidades: sip set debug peer USUARIOSIP o bien sip set debug ip DIRECCIONIPSIP
A partir de ahí, Asterisk empezará a mostrar por pantalla todos los paquetes SIP que envía y recibe de ese usuario o esa dirección IP. El problema en este caso es ¿cómo almacenar esa información en un archivo de texto? Para esto, podemos hacer caso de la potente consola de Linux y la aplicación ‘tee‘:
asterisk -rx ‘sip set debug peer DIRECCIONIP‘
asterisk -rvvvvvvvvdddddddddd |tee traza.txt
De esta manera, en la primera linea, habilitamos el debug y en la segunda, nos conectamos a Asterisk y guardamos en el archivo ‘traza.txt’ cualquier cosa que Asterisk nos devuelva. Para finalizar la traza, solo tenemos que salir de Asterisk.
Las trazas son necesarias, no son fáciles de leer, no son rápidas de leer, tampoco se iluminan ante los fallos y mucho menos dicen dónde está el problema, pero por lo menos, ayudan a conocer un poco el contexto y ver qué se envía y recibe cuando ocurre el problema.