Desde siempre, un servidor Linux bien configurado necesita de un servidor de correos configurado de una forma muy particular para conseguir que las notificaciones de los servicios que corren, puedan enviarnos avisos y notificaciones. Un ejemplo de ello ha sido el uso del VoiceMail de Asterisk que nos envía un email cuando alguien nos deja un mensaje en el buzón de voz.
Hace ya algunos años explicamos en Sinologic cómo configurar el envío de email para que Asterisk nos pueda enviar mensajes y para ello utilizábamos uno de los MTA (Mail Transport Agent) más utilizados llamado Exim. No obstante, tanto si utilizas Exim, como Postfix, como SendMail, estás configurando un servidor íntegro de envío de emails, el mismo servidor que podría utilizar una empresa para todos sus empleados o para sus usuarios. Claro que nuestro servidor no necesita configurar permisos, cuentas de usuario, sistemas de antispam, antivirus, direcciones IP de reenvío de emails, etc, ya que lo único que queremos es que utilice una cuenta de otro servidor de email para enviar las notificaciones.
SSMTP, una aplicación para simplificar el envío de emails
Para eso justamente existe un servicio desde hace bastante tiempo llamado SSMTP (https://github.com/badoo/ssmtp) instalable desde paquetes propios de la distribución…
Así, en Debian/Ubuntu instalaríamos el paquete ssmtp con el siguiente comando:
sudo apt-get install ssmtp mailutils
La configuración de esta forma de configurar el envío de email es 1000 veces más sencilla que utilizando Exim, Sendmail, Postfix o similares… tremendamente sencilla y permite configurar una cuenta de email para que todas las notificaciones que envíe nuestro sistema Linux, se envíen utilizando dicha cuenta.
Qué necesitamos para enviar emails
Para configurar el envío de email en nuestro servidor Linux, debemos tener una cuenta de email válida y que funcione para envío de mensajes:
Servidor SMTP: smtp.miservidor.com
Puerto SMTP: 587
Usuario: superchuloemail@miservidor.com
Contraseña: $uperContraseña999
Una vez tengamos estos datos y hayamos comprobado que podemos enviar emails desde un cliente normal y corriente de envío de email, tan solo nos queda configurar la aplicación:
Cómo configurar el envío de email con SSMTP
La aplicación SSMTP tiene dos archivos de configuración muy sencillos:
El archivo revaliases nos sirve para definir qué cuenta debemos usar si un usuario del sistema envía un email. Generalmente los servicios suelen enviar email como ‘root‘, así que el archivo sería algo así:
# sSMTP aliases
#
# Format: local_account:outgoing_address:mailhub
#
# Example: root:your_login@your.domain:mailhub.your.domain[:port]
# where [:port] is an optional port number that defaults to 25.
root:superchuloemail@miservidor.com:smtp.miservidor.com:587
Y otro archivo ssmtp.conf que nos permitirá configurar los datos del servidor que queremos utilizar para enviar los mensajes de email:
#
# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=superchuloemail@miservidor.com# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named mail.domain.com
mailhub=smtp.miservidor.com# Where will the mail seem to come from?
#rewriteDomain=
# The full hostname
hostname=mi.servidor.com
# Are users allowed to set their own From: address?
# YES - Allow the user to specify their own From: address
# NO - Use the system generated From: address
FromLineOverride=YES
AuthUser=superchuloemail@miservidor.com
AuthPass=$uperContraseña999
UseTLS=YES
UseSTARTTLS=YES
Con estos dos archivos, ya podemos hacer una prueba de envío de email con un comando básico de consola:
Comprobar que podemos enviar email desde el servidor
echo "Mensaje" | mail -s "Asunto" micorreopersonal@midominio.com
Durante muchos años un error que aparecía pocas veces pero que trae bastante cola aparece de forma misteriosa y por más que buscamos a qué se debe, no hay forma de eliminarlo. Este mensaje además aparece cuando el sistema tiene un número considerablemente alto de llamadas lo que provoca que se rechacen paquetes UDP que, viniendo de un sistema Asterisk, tiene bastantes posibilidades que sean SIP o UDP, así que lo notaremos tanto por que hay llamadas que no finalizan y el error de FRACK! aparece con bastante frecuencia, entonces también afecta al audio provocando cortes bastante importantes y un gran dolor de cabeza.
Este error se produce en Asterisk y generalmente indica un problema con la integridad de la memoria en tiempo de ejecución. La frase «bad magic number» se refiere a un valor esperado en la memoria que no coincide con el valor real, lo que sugiere que algo ha cambiado la memoria de manera inesperada. En cambio, el mensaje «FRACK!» es una convención de código en Asterisk para indicar un fallo en tiempo de ejecución.
Por más que buscamos en los foros y documentación el origen de este error, parece que se trata de algún problema con alguna versión de Asterisk que parece que se soluciona actualizando la versión de Asterisk, pero llega un momento que actualizas la versión y sigue apareciendo, y como únicamente aparece cuando hay bastante carga, es difícil de detectar y de comprobar si funciona o no la solución.
El error que aparece en el /var/log/asterisk/messages es como este:
El error aparece tanto en chan_SIP como en PJSIP y con otros módulos, pero es un error tan crítico que provoca cortes y grandes problemas de todo tipo.
Descartando un error hardware
Lo primero que tenemos que hacer para solucionar el error FRACK!, Failed assertion bad magic number, es comprobar que el hardware es correcto. El hecho de utilizar un sistema virtualizado no está exento de algún problema físico con la memoria RAM. Para ello, lo suyo es comprobar mediante un test de memoria (memtest86 o similar) que la memoria RAM está bien.
El error FRACK! se soluciona actualizando
En los foros de todo tipo (y he leído foros hasta en ruso o en japonés) hablan de que se soluciona actualizando, por lo que en un primer momento pensé que que el error FRACK!, Failed assertion bad magic number, era un fallo de esa versión en particular y que actualizando a la versión que decía, también se solucionaría.
Error… el FRACK! no se soluciona actualizando a una versión en particular… toca seguir buscando.
No obstante y como vamos a ver ahora, llega un momento en que actualización tras actualización llega un momento en que se soluciona. pero ¿y eso por qué?
Este error ha aparecido desde tiempos inmemorables y como decía antes, siempre en el peor momento: cuando más llamabas había en un Asterisk. Las soluciones, incluso con acceso directo a Digium para intentar solucionarlo siempre se basaban en el mismo sistema: 1) enviar traza, 2) enviar gdb con el error, 3) actualizar la versión de Asterisk, 4) si no se soluciona: Goto(1).
El error FRACK! se debe a la diferencia de versiones entre el sistema operativo y Asterisk
Hay que entender que cada versión de Asterisk se desarrolla en una fecha y en esa fecha existen librerías con versiones más o menos similares.
Puedes instalar Asterisk 20 en una Debian 7, y no dará fallos, pero Asterisk hace uso de funciones en librerías libc, glibc, libssl, etc. estándar de Linux y esperan respuestas que funcionen, pero cuando hablamos de gestión de memoria, las librerías evolucionan y cambian su forma de trabajar y las nuevas versiones de Asterisk esperan una respuesta compatible que en algún momento deja de serlo y entonces se encuentra que una información que debería estar en una posición de memoria, no se encuentra ahí y de ahí el error.
Normalmente con una versión determinada de la distribución que utilices, le acompañan varias versiones de Asterisk, pero si intentas instalar un Asterisk demasiado nuevo o demasiado antiguo, a la hora de compilarlo fallará y no te permitirá hacerlo hasta que no actualices mínimamente.
Si tienes una versión de Linux muy nueva y utilizas una versión de Asterisk antigua, posiblemente te deje instalarlo, pero entonces ocurren los errores de FRACK!, Failed assertion bad magic number… lo mismo si instalas una versión de Linux antigua y Asterisk muy nueva, aunque en este caso, los errores son diferentes (Segmentation Fault, reinicios del Asterisk sin explicación, etc.) por eso es importante que si instalas una versión de tu distribución favorita y esa versión es muy nueva, tendrás que instalar una versión de Asterisk también bastante nueva o tendrás problemas de FRACK!.
De ahí que el error de FRACK! se solucione actualizando la versión de Asterisk.
Cada versión de Asterisk está pensada para una época determinada
En función de la versión de la distribución de Linux, deberás utilizar una versión de Asterisk de ese momento. Todo tiene su momento y aunque siempre se programa para lograr la máxima compatibilidad con todo, haciendo uso de las librerías más modernas pero también las más antiguas, son tantos los factores que intervienen en una aplicación de software, que no queda otra que actualizarse o morir.
Durante muchos años he encontrado de todo, desde versiones de CentOS 5 con Asterisk 1.4 hasta Debian 11 con Debian 1.8., y funcionan… lo que marca la diferencia es cuando realmente pasamos a tener cierto volumen de llamadas y toca hacer un uso intenso de ciertas librerías que manejan software de sistema operativo en capas bajas (reserva de memoria, almacenamiento de datos, procesamiento de números…)
Desde Sinologic siempre hemos defendido que hay que estar constantemente actualizando para evitar fallos de seguridad y recibir las ventajas y mejoras de las actualizaciones que van surgiendo, pero hoy más que nunca, esta recomendación se hace evidente y es que el error FRACK! es para muchos, un gran dolor de cabeza y al menos por mi parte, parece que tiene una solución que, si bien no es fácil, al menos sí es posible y pasa por actualizar Asterisk a una versión «más compatible» con la versión de la distribución de Linux que estemos utilizando.
Entonces la única solución si aparece el error de FRACK! , Failed assertion bad magic number es, o bien reinstalar con una versión de Linux más antigua, o actualizar la versión de Asterisk a una versión compatible con tu distribución, aunque eso implique modificar la configuración para adaptarla a la nueva versión de Asterisk.
La VoIP y la telefonía discurren por mundos paralelos. En telefonía, todo se reduce a llamar desde un número y hacia otro número. Cada número de teléfono tiene un propietario y las llamadas entran mediante un sistema que ya puede ser una centralita, un operador o una línea conectada a un router de fibra óptica a la que está enganchado un teléfono analógico. En el siguiente artículo vamos a explicar cómo funcionan los prefijos telefónicos y vamos a ver algunos ejemplos que seguro que a más de uno le sorprenderá si no los conoce.
Para uno de esos proyectos que se comienzan, se abandonan, se retoman y se vuelven a abandonar hasta que al final salen, empecé a hacer una investigación que se basaba en detectar cuándo un número era válido o no y a dónde querían llamar. Algo que en principio podía parecer algo sencillo, incluso hay librerías que ya lo hacen validando los prefijos simplemente comprobando si los números son válidos y la longitud de estos (https://github.com/google/libphonenumber), y en principio podría servir, pero requería algo más en profundidad… quería saber exactamente a dónde llamaban, podía parecer una tarea sencilla si nos basáramos únicamente los números telefónicos de un país como España que tiene los números delimitados por prefijos por provincias pero cuando ampliamos el rango a cualquier número internacional, la cosa se complica y no imagináis de qué manera.
Lo primero que hice fue ir a la documentación de la ITU y leer que existe un «estándar» por el cual un número de teléfono internacional se rige por el formato E.164
¿Qué es el E.164?
El E.164 es un formato de número internacional que consiste en un prefijo del país, seguido del número de teléfono de destino al que queremos llamar: codigo de país + número de teléfono. (fácil ¿verdad?). Básicamente el E.164 consiste en un número (de 15 dígitos como máximo) que utiliza un código de país tal y como se indica en la siguiente imagen:
Mapa ampliable con todos los prefijos de todos los países (si sabes localizar dónde está geográficamente al que quieres llamar)
Hasta ahí todo bien, ya podría saber si me llega un número a qué país quiere llamar y en función de este, es tan sencillo como localizar la localidad y el tipo de teléfono a que quieren llamar. Si bien el E.164 es un estándar, los planes de numeración nacionales lo son dentro cada país, por lo que cada país tiene su propio plan de numeración. Revisamos en la ITU los planes de marcación y ahí es cuando comienza el verdadero dolor de cabeza.
Plan de numeración de todos los países
No todos los países tienen la misma cantidad de dígitos (algo evidente considerando que hay países con más teléfonos que personas y otros países con algunos menos), pero tampoco están distribuidos por tipo de teléfono, ni por zonas, provincias, localidades, etc. En muchos países, los prefijos dependen de zonas especiales, comarcas, barrios, provincias del tamaño de Andalucía, hay planes que no distinguen si un número es fijo o móvil, o si lo distingue, uno puede pedir la portabilidad de uno a otro y está todo mezclado, etc.
Con mucha suerte, en el enlace de la ITU con la recopilación de los planes de marcado de cada país, la mayoría tienen un PDF descargable donde se define cómo funciona su numeración (números de emergencia, números a dispositivos móviles, a fijos, numeración especial, numeración corta, SMS, etc.) en otros (como el caso de España, Suecia, etc.) tienes un enlace al Plan Nacional de Numeración Telefónica donde toca pelearte con los enlaces y extraer la información a mano.
Hay países donde el mismo número de destino se marca diferente…
Si llamas desde la misma localidad.
Si llamadas desde otra localidad.
Si llamas desde el extranjero.
Si llamas a un teléfono de una compañía X.
Si llamas a un teléfono de tu misma compañía X.
etc.
No hay más que preguntarle a algún colega de Argentina y veréis lo que os digo.
Prefijo para hacer llamadas internacionales
Cada país para hacer llamadas internacionales no se hacen con el famoso 00 + PAIS + TELEFONO, si no que hay muchos otros prefijos que, según donde estemos, hay que marcar para poder hacer la llamada internacional: el ’00’ es ‘011’, ’11’, ’01’, ‘01100″, etc.
PAIS DONDE LLAMAMOS:
PREFIJO PARA LLAMAR A ESPAÑA:
Alemania
0034
Argentina
0034
Australia
001134
Austria
0034
Bélgica
0034
Bosnia-Herzeg.
0034
Brasil
0034
Bulgaria
0034
Canadá Montreal, Quebec y Toronto Vancouver
01134
Checa, Rep.
0034
China, Rep. Pop.
0034
Croacia
0034
Dinamarca
0034
Eslovaquia, Rep.
0034
Eslovenia
0034
Estados Unidos Nueva York, Miami, Boston Washington y Filadelfia Chicago, Dallas, Fort Worth y Houston San Francisco, Oakland y Los Angeles
01134
Finlandia
0034
Francia
0034
Grecia
0034
Hong Kong
00134
Hungria
0034
India
90034
Irlanda
0034
Islandia
0034
Israel
0034
Italia
0034
Japón
00134
Luxemburgo
0034
Macedonia
0034
Marruecos
0034
México
9834
Noruega
0034
Paises Bajos
0034
Polonia
0034
Portugal
0034
Puerto Rico
01134
Reino Unido
0034
Rusia
81034
Suecia
0034
Suiza
0034
Taiwan
00234
Túnez
0034
Turquía
0034
Yugoslavia (Serbia y Montenegro)
9934
Es decir… si viajas a la India y quieres llamar a tu casa desde un teléfono ¿qué número tendrías que marcar? Suponiendo que tu teléfono fuera el 910123456 de España (34), desde la India deberás marcar el número de teléfono: 90034910123456
Los prefijos en España son curiosos
Los prefijos en España funcionan geográficamente, de manera que cada Provincia tiene un prefijo propio, así un teléfono fijo de Madrid comienza SIEMPRE por 91 y un teléfono fijo de Málaga comienza SIEMPRE por 952. No obstante, a medida que la población crece y el número de teléfonos aumenta, los números de teléfonos fijos geográficos, que deben tener 9 dígitos, se agotan, por lo que en lugar de comenzar por 9, algunas provincias empiezan también a tener prefijos que comienzan por 8. Este es el caso de Málaga que tiene, además de los prefijos 952xxxxxx y el 951xxxxxx, los prefijos 852xxxxxx y el 851xxxxxx.
Los números móviles también tienen su propio prefijo y son aquellos números de 9 dígitos que comienzan por 6: 6xxxxxxxx. No obstante, el volumen de números móviles ha crecido tanto que ha sido necesario crear un nuevo prefijo para la red móvil: el 7: 7xxxxxxxx.
No obstante, no todos los 7xxxxxxxx son números móviles, existe un prefijo dentro de la numeración 7xxxxxxxx que se sale de este rango: 704xxxxxx es un prefijo especial creado para «redirecciones personales» lo que viene siendo un número que tiene una programación que permite apuntar a un número y, en caso de que no funcione, llamar a otro número diferente de forma automática.
Para aquellos usuarios de telefonía VoIP crearon otro tipo de prefijo (los números nómadas): 51xxxxxxx, un número similar al geográfico fijo, pero con la posibilidad de no está atado geográficamente a una provincia. Una idea fantástica para dejar atrás los fijos geográficos. La idea en sí es buena, de hecho sería ideal dejar de utilizar los prefijos de números fijos que comienzan por 9xxxxxxxx y por 8xxxxxxxx y utilizar de forma general numeración no asociada a una provincia concreta. (así evitaríamos la sobresaturación de números de ciertas provincias para aparentar «oficialidad» o «seguridad»)
Por desgracia, a alguien se le ocurrió la maravillosa idea de sacar de las tarifas planas los números con prefijo 704 y los números nómadas con prefijo 51, de manera que nadie quiere utilizar un 51xxxxxxx, y los prefijos 704 también tienen un coste especial con establecimiento por lo que, a medida que lo sacaron, prácticamente nadie los quiere por su coste de cara a recibir llamadas y prefieren utilizar numeración fija geográfica (en lugar de la numeración nómada) o bien numeración de red inteligente (en lugar de la numeración de redirección).
NOTA MUY IMPORTANTE: Si tienes programado en tu centralita un plan de marcado (dialplan), y has configurado la posibilidad de llamar a números móviles marcando un prefijo 6xxxxxxxx y un 7xxxxxxxx, recuerda que si alguien llama al 704xxxxxx y descuelga, esa llamada no suele venir incluido en la tarifa plana y además tiene un precio bastante más alto que el de una llamada a la red móvil habitual.
Los números de Red Inteligente, se consideran aquellos que comienzan por los prefijos 90xxxxxxx y 80xxxxxxx, quedando los 900 y 800 como números «que paga quien recibe la llamada«, los 901 y 801 como números «de coste compartido» cuyo coste paga tanto quien llama como quien recibe la llamada y los 902 como números cuya llamada es pagada «por el usuario«
Los prefijos 903, 905, 906 fueron reemplazados por los prefijos 803, 805, 806, quedan con tarificación extra-plus-premium que pasan a costar bastante dinero y por eso generalmente están bloqueadas salvo que llames expresamente para desbloquearla.
Prefijo
Paga el usuario
Paga el destinatario
Utilidad general
900xxxxxx
NO
SI
Atención al cliente, ayuda, información, etc.
800xxxxxx
NO
SI
Atención al cliente, ayuda, información, etc.
901xxxxxx
SI
SI
Atención al cliente, acceso a redes informáticas, etc.
801xxxxxx
SI
SI
Atención al cliente, acceso a redes informáticas, etc.
902xxxxxx
SI
NO
Llamada a empresa general (prohibido para atención a cliente)
Los números con prefijo de Red Inteligente son números en sí.
Aunque muchas empresas asocian un número de red inteligente a un número geográfico, realmente no es obligatorio y una empresa puede tener un número de red inteligente sin necesidad de tener un número fijo o móvil asociado. Lo recibe en su centralita sin más y no tiene número geográfico asociado (eso que a muchos nos interesaría conocer para ahorrarnos llamar a un 902).
No obstante, hay muchas empresas que lo que suelen hacer es utilizar ese número con prefijo de red inteligente como un redireccionamiento a un número geográfico fijo o a un número móvil. En este caso sí es posible llamar indistintamente al número con prefijo de red inteligente o al número fijo. Según el operador que le configure esa redirección, la empresa podrá saber si la persona a llamado a uno u otro número y bloquear aquellos que llamen al número fijo y permitir únicamente aquellos con prefijo de red inteligente.
Resumiendo el tema de los prefijos telefónicos…
En fin, después de todo este artículo, espero que haya quedado más claro cómo funcionan los prefijos telefónicos y veáis las curiosidades que hay detrás de los prefijos de algunos países como Argentina, que los 704 que permite tu centralita cuestan bastante más que una llamada a móvil, y que si acabas en Rusia o en Taiwan y quieres llamar a casa, más te vale preparar bien el número que debes marcar en la cabina.
El mercado de la VoIP está aprovechando el tirón antes del invierno para darle un cambio de imagen general y cambiar los terminales por algunos nuevos. Los fabricantes han sacado modelos nuevos y eso ha hecho que algunos modelos más antiguos tengan unos precios realmente bajos como los modelos más antiguos de Granstream o Snom.
No obstante, lo realmente interesante si no queremos aprovechar las ofertas y descuentos de los modelos más económicos, es intentar arreglar aquella pieza que se ha roto e intentar darle una segunda vida a nuestro teléfono o a nuestro auricular gracias a conseguir la pieza que está rota y que hace que el teléfono no funcione como debería.
Este periodo de tiempo se aplica a partir de la fecha de retirada del producto y también entra en vigor en 2022. Es decir, si el dispositivo deja de fabricarse a partir de 2022, entonces las piezas deberán guardarse por 10 años.
Aún así, si la pieza es fácil de reparar igual podemos evitarnos el lío de contactar con el fabricante para solicitarla, envíos, transportes, y costes varios y (atención a esto) imprimirla nosotros mismos.
Y es que en la página por excelencia de modelos para imprimir en 3D (Thingiverse) podemos encontrar una recopilación bastante interesante de piezas típicas que se rompen siempre y nadie te dice cómo poder solucionarla… pues aquí tenemos una recopilación muy interesante:
Ejemplo de pie del teléfono Yealink que es uno de los que más rápidos se rompen y que ahora podemos arreglar imprimiendo esta pieza.
Otra de las ventajas de poder imprimir en 3D es aprovechar algunos soportes nuevos para poder colocar un gateway en la pared, una pata nueva de un teléfono, o para colgar un teléfono en la pared y evitar que ocupe espacio en la mesa, un soporte de auricular, una antena Wifi o un altavoz.
Aquí podéis ver la lista de modelos que podemos imprimir en 3Dy darle una nueva vida a nuestros dispositivos VoIP.
Vamos a ver 4 herramientas básicas que todo administrador de sistema seguramente ya conoce, pero que nunca están de más repasarlas y si da la casualidad que no conoces alguna de ellas, pues mejor que las vayas conociendo.
Todas las herramientas suelen venir con tu distribución Linux, pero en algún caso es mejor incluso descargar el código fuente e instalarla a mano compilando para aprovechar las novedades de las últimas versiones.
iotop
iotop nos muestra el uso del disco duro de cada proceso del sistema.
IOTOP es una herramienta que nos permitirá saber en tiempo real y en modo texto, qué procesos del sistema leen y escriben del disco duro, así como el ancho de banda que utilizan (cuandos bytes/segundo escriben en el disco duro) y de esta manera, saber si un proceso está haciendo un uso demasiado alto que igual podríamos reducir con un ramdisk o algo similar.
Nethogs nos muestra el uso del ancho de banda de cada uno de los procesos del sistema.
NETHOGS es otra de las herramientas ultrabásicas que nos permite saber en tiempo real y en modo texto qué procesos del sistema están enviando o recibiendo datos de la red, a qué velocidad y de esta manera tener una estimación de los recursos que necesitan. Esta herramienta es verdaderamente útil cuando queremos saber cuanto ancho de banda necesitamos en nuestro Asterisk cuando lleva una cantidad determinada de llamadas, ya que podemos ver exactamente el ancho de banda del proceso Asterisk y no el de todo el sistema.
Nota importante: aunque las distribuciones suelen traer esta herramienta, si queremos monitorizar el tráfico UDP, es necesario descargarnos el código fuente y compilar. Son dos archivos, por lo que la compilación es muy sencilla, pero esta última actualización es vital para los que trabajamos en VoIP.
perf nos mostrará un ‘top’ con el proceso pero de las funciones internas de cada proceso.
PERF es otro de los grandes descubrimientos en herramientas básicas (No confundir con ‘iperf‘ que es para monitorizar ancho de banda), ya que si bien herramientas como ‘top’, ‘htop’, y otras de este tipo, muestran la utilización del procesador y memoria de los procesos del sistema, ‘perf’ profundiza un poco más y muestra el uso de procesador y memoria de las funciones internas de cada proceso (incluido los del kernel de Linux) por lo que es especialmente útil si alguna aplicación está consumiendo demasiado procesador, podremos ver el nombre de las funciones internas que realmente están consumiendo esa cantidad de procesador y así investigar más al investigar qué hace dicha función
perf también permite capturar el consumo de procesador y memoria y guardarlo en un archivo para posteriormente utilizarlo para sacar gráficas de rendimiento, muy útil cuando estamos programando algo y queremos hacer una refactorización de partes del código.
sngrep nos mostrará todo el tráfico SIP de una forma fácil y eficiente para entender qué ocurre.
SNGREP es la última de las herramientas de las que hablaremos hoy, aunque es una gran conocida por los lectores de Sinologic, marcó un antes y un después en todo lo que significa monitorizar el flujo de tráfico SIP de un sistema de comunicaciones. Antes, si bien utilizábamos herramientas como ngrep o tcpdump o un simple «sip set debug on«, también había quien usaba Wireshark… pero desde la aparición de sngrep, monitorizar el tráfico SIP ha pasado a ser algo muchísimo más atractivo, eficiente y práctico.
Hace unas semanas, estaba haciendo pruebas con varias tarjetas SIM nuevas recién-estrenadas (es decir, que no han tenido dueño ni nada por el estilo) y mientras hacía pruebas con un móvil empiezo a recibir llamadas procedentes de varios números móviles.
El primer pensamiento que viene a mi mente en este momento es que alguien se ha podido equivocar al marcar y ha dado casualmente con el número móvil de esa tarjeta que jamás había sido dada de alta en ningún sitio, por lo que no descuelgo, no bloqueo, nada… simplemente dejo que suene y que se canse para que verifique el número para la próxima vez. Al día siguiente, a la misma hora vuelve a llamar el mismo número pero con otra terminación. Ummm. sospechoso… esta vez sí descuelgo y hablo con la persona que me llama. Rápidamente me respondió un comercial de una compañía eléctrica…
-«Hola buenas tardes! ¿podría hablar con el titular de esta línea?»
¿cómo han conseguido este número? No ha sido dada de alta en ningún momento, tiene numeración nueva, por lo que no es posible que un anterior dueño la hubiera dado de alta en alguna empresa. Hablo con el agente y le explico que este número por casualidad no pertenece a nadie, que es un número interno de pruebas y que por favor, dejen de llamar ya que esta línea no tiene dueño.
Muy amablemente terminamos la conversación y aún así, estuve más de dos semanas recibiendo llamadas todos los días desde prácticamente el mismo número (con diferente terminación) para venderme servicios de diferentes compañías: eléctricas, telefónicas, seguros,… vamos, alguna empresa de telemarketing había hecho un barrido de todos los números de teléfono y se había puesto a llamar a todos y cada uno de los números que no fuese rechazado.
Desconozco de leyes lo suficiente como para no estar seguro de hasta qué punto eso es ilegal en España, aunque estoy seguro que la práctica de algunas empresas de llamar a todos los números y hacer una lista de qué números responden y qué números no, no debe ser muy legal, no obstante, lo que sí tengo es el sentido común para saber que la ética de esa empresa después de indicar que ese número no pertenecía a nadie y seguir llamando, les permitiría ser capaces de venderte a su mismísima abuela moribunda si con ello ganaban un contrato.
La AEPD (Agencia Española de Protección de Datos) publica en su página web los expedientes y sanciones a las empresas que realizan prácticas ilegales tanto por publicidad indebida como por uso de datos no autorizados para la realización de campañas de marketing y es una manera como otra cualquiera de ganar entre 2000 y 2500€ por sanción ganada de media cada vez que te llama una empresa en la que no te has dado de alta.
La Lista Robinson es un listado de números, cuentas de email, direcciones físicas, gestionado por Adigital (La Asociación Española de la Economía Digital) que se encarga de recoger gratuitamente los datos de las personas que no quieren recibir información comercial. Por lo que si un usuario no quiere recibir publicidad en su teléfono, tan solo tiene que darse de alta en la Lista Robinson y en un plazo de 3 meses desde el momento del alta, debería dejar de recibir esas molestas llamadas o se arriesgan a una demanda por contravenir la Ley de Protección de Datos Personales y garantía de los derechos digitales.
Las empresas de publicidad y marketing deberán a su vez comprar, consultar y eliminar de sus bases de datos todos los números que figuran en la lista Robinson. Tras los tres meses desde su alta, cualquiera que reciba una llamada comercial puede ir a la AEPD y denunciar al número de teléfono que le llame, tras lo cual se abrirá una investigación y se procederá a una sanción si se comprueba que el usuario ha recibido llamadas comerciales tras su negativa.
No obstante, en otros países la legislación no protege de igual forma, en el continente americano se permiten incluso las «robocalls«, llamadas automatizadas con grabaciones (ya vimos en Sinologic que las llamadas automáticas con locuciones en España están prohibidas) y entonces, a falta de una legislación en este sentido, toca tirar de imaginación y evitar esas llamadas de otras formas menos contundentes.
Para ello, Asterisk cuenta con una herramienta tan antigua como práctica. En España no es muy común, aunque también funcionaría y es el conocido «Zapateller«:
Zapateller es una aplicación del dialplan de Asterisk que genera un tri-tono (tono SIT )… un tipo de tono telefónico que debe sonar cuando alguien llama a un número de teléfono que no está en funcionamiento.
Ejemplo de tri-tono (SIT tone)
En el caso en que un marcador predictivo llame a un número y suene este «tri-tono», lo más probable es que entienda que el número de teléfono no sea correcto y lo elimine de la lista para evitar perder el tiempo con él.
Esta aplicación se suele utilizar cuando se recibe una llamada con un número oculto o con algún número conocido como «comercial». En España no tiene sentido ya que, aunque no sea legal, muchas empresas utilizan números móviles para hacer esas llamadas comerciales, pero en el continente americano sí es bastante frecuente recibir llamadas comerciales de números anónimos, por lo que es una buena forma de, no sólo evitar la llamada comercial, si no de que te quiten de su lista de clientes a los que molestar.
TIR-SHAKEN es lo último para combatir la suplantación de identidades en redes telefónicas. Es un protocolo que impide hacer llamadas utilizando un teléfono que no se corresponde con el tuyo. De esta manera se comprueba que quien te llama es el verdadero dueño del número y no que hayan utilizado un número al azar para hacer la llamada (algo también ilegal pero que técnicamente sí se puede hacer). En España, esta práctica (hacer llamadas con números de otras personas o empresas) no sólo está prohibida, si no también perseguida y, gracias a la buena estructura y comunicación entre los principales operadores de España, no es difícil identificar a la empresa que realiza estas prácticas y pararle los pies rápidamente y exigirle responsabilidades legales.
Pese a que ya se empiezan a realizar algunos eventos profesionales muy concretos y muy puntuales, guardando las distancias, con medidas y todas las precauciones del mundo para evitar contagios y brotes por seguridad y responsabilidad, llevamos más de un año celebrando eventos virtuales.
También acabamos de recibir la invitación para finales de octubre de un evento híbrido: la ClueCon 2021, que se celebrará del 25 al 29 de octubre, simultáneamente en el InterContinental Hotel Chicago y On-Line y que ya está todo disponible para registrarse.
A falta de eventos, nuestros amigos de InstantByte han decidido dedicar el mes de Abril al tema de la videovigilancia bajo el lema: En abril, ojos mil. con charlas, webinars, talleres y ofertas semanales para ayudar a implantar este tipo de soluciones.
El calendario de los talleres y sus webinars son:
9 de Abril a las 10:00 : Primeros pasos para un proyecto de videovigilancia Webinar sobre cómo afrontar desde 0 un proyecto de videovigilancia. (registro)
15 de Abril a las 10:00 : Webinar sobre como debería ser servicio de videovigilancia para particulares y comercios que incluye la cámara y los planes de almacenamiento. (registro)
16 de Abril a las 10:00 : Configuración de las distintas soluciones de videovigilancia Webinar/taller sobre cómo configurar las cámaras: Hikvision, Dahua, Unividew y Hilook (registro)
23 de Abril a las 10:00 : Funciones de Inteligencia Artificial en los sistemas de videovigilancia. En este webinar veremos diferentes soluciones de videovigilancia con sistemas de Inteligencia Artificial: Reconocimiento facial, Lector de matrículas, Imágenes térmicas y Detección de movimiento. (registro)
29 de Abril a las 10:00 : Soluciones de Videovigilancia para un hogar inteligente de Ezviz Webinar, impartido por María Simón, donde se verán qué soluciones de videovigilancia se pueden introducir en un hogar inteligente de la marca Ezviz, desde cámaras WiFi con audio bidireccional, hasta purificadores de aire, pasando por mirillas inteligentes y videoporteros. (registro)
30 de Abril a las 10:00 : Control de Acceso y Presencia: Puesta en marcha y configuración Cómo poner en marcha diferentes dispositivos de control de acceso y presencia, además de la configuración de los mismos en base a los requerimientos de cada empresa: Hikvision y Dahua (registro)
De la mano de su creador, Daniel Constantin Mierla (aka @miconda)acaba de impartir en la ClueCon TGI2021 un taller súper-completo sobre Kamailio donde explica con todo lujo de detalles muchos de los conceptos básicos sobre qué es Kamailio, para qué sirve, para qué NO sirve y cómo configurarlo.
Este video-taller de 1 hora de duración es un excelente recurso para todos aquellos que quieren empezar a aprender Kamailio.
Presentación
Qué es Kamailio
Introducción al Routing SIP
Arquitectura de Kamailio
Gestión de memoria
Cómo Kamailio procesa los paquetes SIP
Archivo de configuración de Kamailio
Tipos de bloques de routing
Enrutamiento SIP
Lógica de enrutamiento
El archivo de configuración
Sintaxis, variables y expresiones en la configuración
Intérpretes en otros lenguajes (KEMI)
Modificación de parámetros SIP
El momento de la entrega del paquete SIP
Módulos básicos y especiales
Para todos aquellos que penséis que el inglés puede ser un problema, Daniel es un fantástico speaker donde su acento permite seguirlo con bastante facilidad.
Siempre he sido de la opinión que no hay que ser un paranoico de la seguridad, simplemente intentar que todo lo que se hace debe ser lo más seguro posible: «La seguridad no es un lema, es una forma de vida» y por esta razón, cuando vi el siguiente gráfico de tiempos que tardaría una máquina en conseguir una contraseña, me entró la curiosidad sobre qué se puede hacer normalmente para evitarlo.
Visto lo visto, con las GPUs que hay hoy día y la potencia de cálculo que tienen los sistemas cloud comerciales, crear una contraseña de menos de 12 caracteres es básicamente instalar una bomba de relojería a la espera de que venga un bot con algo de tiempo y acceda a nuestros sistemas.
Uno puede pensar en contraseñas largas y complejas con más de 15 caracteres, mayúsculas, números, símbolos, alguna coma, un signo dólar y alguna Ñ, pero a la vista de la cantidad de contraseñas que hay que escribir, al final lo mejor y más cómo para evitar repetir la misma contraseña, es utilizar una herramienta que sirva como «llavero» y que contenga las contraseñas que utilizamos, tan grande y complejas como queramos, de manera que no haya que recordarlas.
Herramientas llavero
Suelo utilizar la herramienta KeePass que permite crear varias bases de datos cifradas con las contraseñas que uso para diferentes motivos (empresa, servidores, personal, clientes, loqueseteocurra, etc.) y tras una contraseña maestra para cada base de datos, poder acceder a toda la lista de accesos con total seguridad. Esas bases de datos están en archivos cifrados dentro del sistema de ficheros local, por lo que la seguridad es mucho mejor que tenerlo en un Post-it en el monitor, en una libreta de papel o en una hoja Excel (ya que ésta última no suele ir cifrada).
El problema de este tipo de herramientas es que, cada vez que hace falta acceder a un sitio, hay que abrir la aplicación, meter la contraseña, buscar el acceso que necesitas y gracias al «copy+paste«, poder pegar la contraseña y así, autentificarte de forma segura. No es la fórmula más práctica. (aunque luego explicaré cómo soluciono esto).
2 contraseñas: la segunda, varía con el tiempo
Yubikey con las llaves de casa
No obstante, investigando un poco cómo lo harán en las grandes empresas de seguridad, recuerdo el caso de un amigo que trabaja en Google y que, cuando entró, en el pack de bienvenida, le entregaron además de un montón de merchandising, un portátil y algunas cosas más, una Yubikey: una mochila USB que sirve como sistema de dos pasos automático.
Introduces el login, la contraseña y cuando se comprueba que es correcto, además te pide un código que, en lugar de enviarte un código al móvil, sólo tienes que «tocar» la Yubikey y ésta rellena la parte del código de segundo paso. Si alguien te roba la contraseña no podrá hacer nada, ya que no tendrá tu móvil o la mochila USB para saltarse el segundo paso, y la Yubikey suele ir como una llave más del llavero, por lo que siempre la llevas contigo, igual que tus llaves de casa.
El sistema de autentificación de dos pasos siempre me ha parecido muy interesante desde que hace muchos años (hace más de 13 años) un amigo belga me enseñaba cómo utilizaba la autentificación en dos pasos para sacar dinero de su banco. Un aparato especial le generaba un código que tenía que meter como «segundo pin de seguridad«.
Ahora se ha visto que el hecho de enviar un SMS al móvil no es lo más seguro, ya que hay quien incluso te clona la tarjeta SIM para poder recibir el mensaje y hacerte verdaderos desfalcos (lo que significa que ya tienen tu usuario y contraseña y sólo les para esa doble autentificación), así que me puse a mirar el sistema de Google para el tema de generar el código necesario.
A falta de tener una Yubikey de esas para hacer pruebas, tengo un móvil con el que generar los códigos de segunda autentificación, y una lista interesante de servidores personales y máquinas a las que accedo normalmente por SSH, voy a ver cómo dotarla de algo más de seguridad.
Autentificación de dos pasos para acceder por SSH al servidor
Para ello, se me ocurrió usar la doble autentificación (o autenticación, que es lo mismo) en el acceso SSH, lo único que, en lugar de enviar un SMS, voy a utilizar una aplicación en el móvil que genere un código de seguridad válido gracias a un token.
Para esto existen dos aplicaciones comunes: GoogleAuthentication y FreeOTP(las dos funcionan igual, aunque utilizaré FreeOTP por ser software libre y darme algo más de confianza).
Lo que vamos a hacer será configurar el sistema de acceso por SSH, de manera que una vez introduzca la contraseña, se añada una verificación extra (de ahí lo de «los dos pasos») que me solicite un número variable que sólo tendré yo gracias a la aplicación FreeOTP.
1. Instalación de los paquetes necesarios
Para configurar esto en una Debian, lo primero es instalar un paquete básico:
Este «libpam-google-authenticator» es uno de los módulos del sistema PAM (Pluggable Authentication Modules) de manera que se ejecute después de la autentificación estándar para poder permitir el acceso.
2. Configuración del SSH y del PAM
Acto seguido, vamos a editar el archivo de configuración del demonio SSH /etc/ssh/sshd_config para decirle que queremos utilizar el sistema de módulos PAM. Para ello, nos aseguramos que tenemos estas opciones habilitadas:
UsePAM yes ChallengeResponseAuthentication yes
Nada más asegurarnos de esto, editamos el archivo: /etc/pam.d/common-auth donde añadiremos las siguientes líneas:
# Autentificacion OTP mediante Google Authenticator auth required pam_google_authenticator.so
3. Instalar la aplicación FreeOTP o GoogleAuthenticate.
En mi caso, utilizo FreeOTP que es software libre y se encuentra tanto en Google Play como en la App Store.
Una vez instalado, y ejecutado, hay que dar permisos para utilizar la cámara, ya que tendremos que escanear un código QR que nos saldrá por pantalla con el «token» del servidor al que nos vamos a conectar y que se utilizará para generar las contraseñas en función del tiempo.
Ahora bien, nos logueamos por SSH con el usuario que queramos y ejecutamos el comando:
~$ google-authenticator Do you want authentication tokens to be time-based (y/n) y
Tras esto, nos saldrá por pantalla un código QR que tendremos que escanear desde nuestra aplicación.
Le decimos que «yes» a todo… y guardamos bajo llave los códigos de «emergencia» por si no tenemos nuestro móvil a mano para generar la clave. (Estos códigos sólo se pueden utilizar una vez cada uno, por lo que hay que guardarlos muy bieno volver a generar el token)
4. Reiniciar el servidor para aplicar cambios
Vale, nuestro usuario ya tiene habilitado el token de seguridad, ahora lo último que tenemos que hacer es reiniciar el servidor SSH para que utilice el sistema PAM con el módulo que hemos añadido.
~$systemctl ssh restart
5. Comprobamos el acceso
Ahora que ya está todo funcionando, volvemos a acceder con el mismo usuario que hemos activado el token y veremos que una vez introducida la contraseña, nos pedirá un código.
En este momento, habrá que buscar el código en la aplicación.
Captura del FreeOTP
Tendremos 30 segundos para introducir el código tras lo cual, tendremos acceso al sistema.
En resumen
Vale, lo primero… muy intuitivo no es, y rápido tampoco, pero si es más seguro que un acceso normal.
El hecho de tener que acceder a una aplicación del móvil para poder acceder a nuestra cuenta, no es algo que sea muy práctico si nos pasamos el día accediendo a ella, de ahí la utilidad de la Yubikey. Para este tipo de cosas está la autorización de llave pública y de esta manera evitamos tener que meter contraseñas (incluso utilizando la autentificación que hemos visto) y accedemos rápidamente al sistema que queramos validando directamente la clave de nuestro ordenador con el servidor.
Por lo que, para sistemas en los que necesitemos un extra de seguridad, seguramente sea una buena fórmula.
Si aplicamos este sistema (OTP – One-Time-Password) a otros servicios, posiblemente aumentaremos bastante la seguridad. Como decía al principio, la idea no es ser un paranoico de la seguridad, si no aprender a ser seguros en todo lo que hagamos.
Hace tiempo que quería escribir un artículo como este, pero ahora que el Coronavirus está empezando a obligar a muchas empresas a buscar mecanismos para que la gente pueda seguir trabajando desde sus casas, creo que es un fantástico momento para explicar cómo montar un servidor VPN para unas pocas personas y que puedan acceder desde cualquier lugar a la red interna como si estuvieran físicamente ahí.
Nota importante: Hay que aclarar que esto abre una puerta (aunque sea cifrada) a que las personas del exterior puedan acceder a la red interna de nuestra oficina, que desde Sinologic no nos hacemos responsables de ningún problema de seguridad que pueda ocurrir por culpa de este tutorial y que, aunque para poder acceder es necesario disponer de un certificado creado específicamente para cada sistema, no se recomienda esto para grandes oficinas, si no para pequeñas oficinas de no más de 5 empleados que necesiten trabajar en remoto de vez en cuando. Si quieres un sistema VPN serio instala en condiciones un servidor IPSEC o un OpenVPN en un servidor de verdad con una conexión en condiciones y aplicando las medidas de seguridad necesarias y contramedidas para evitar ataques.
El objetivo es muy sencillo de entender. Consiste en montar un pequeño servidor VPN dentro de la red interna, utilizando una Raspberry PI como servidor y así evitamos que el coste de un servidor sea un impedimento a los presupuestos organizados de la empresa. Esa VPN hará que podamos conectarnos desde cualquier lugar de Internet al sistema Raspberry y una vez conectado, tener acceso a todos los dispositivos (ordenadores, impresoras, servidores, etc.) de la red interna, así como salir nuevamente por el router de la empresa (por lo que podremos acceder a los sistemas que tengamos filtrados por IP y que únicamente se puedan acceder desde nuestra conexión).
Qué es necesario
Necesitaremos:
Nuestra oficina deberá disponer de una conexión a Internet con ancho de banda suficiente y dirección IP fija que tendremos que configurar para poder conectarnos a ella cuando queramos acceder.
Acceso al router de la oficina para mapear el puerto del OpenVPN y poder acceder desde el exterior.
Una Raspberry PI 3 (aunque mejor 4 ya que tiene más potencia, una tarjeta de red Gigabit).
Es importante que, tanto la IP interna de la oficina (192.168.1.X) como la IP interna de nuestro lugar remoto (10.10.0.25), sean subredes diferentes, ya que si son iguales puede haber problemas de enrutado y nuestro ordenador no podrá distinguir qué es «local» y qué es «remoto».
Una vez conectado a la VPN, nuestro ordenador tendrá una IP interna (10.10.0.25) y una IP VPN interna (10.8.0.4) pero tendrá acceso a los ordenadores y servidores de la red interna (192.168.1.X) porque la Raspberry hará de puente.
Si estamos conectados y queremos acceder a una página web, lo haremos con la conexión de la oficina (el router introducirá nuestros paquetes, lo enviará a la Raspberry y volverá a salir por el router manteniendo la IP de la oficina).
Instalación del sistema Raspbian
En la Raspberry PI tendremos que instalar Raspbian, esto es algo básico y sencillo, así como configurarle una IP fija dentro de la red interna, por ejemplo: 192.168.1.248
Para ello lo mejor es acceder al router y buscar la opción para asignar una IP fija a la dirección MAC de la raspberry PI. De esta manera, aunque la raspberry PI pida una nueva IP, el router siempre le dará la misma.
Instalar OpenVPN en la Raspberry PI
Una vez instalada la distribución Raspbian y configurada la IP interna fija en el router, usaremos PiVPN para instalar OpenVPN, por lo que ejecutaremos en la Raspberry PI el siguiente comando:
curl -L https://install.pivpn.io | bash
Este comando instalará OpenVPN y hará varias comprobaciones, además de:
Pedirnos confirmación de que tenemos una IP interna y fija.
El usuario de la raspberry PI que utilizaremos para ejecutar todos esos comandos (por defecto: ‘pi‘)
El puerto del router que utilizaremos para conectarnos desde el exterior. (Por defecto, el puerto de OpenVPN es el 1194/UDP aunque es recomendable poner cualquier otro entre 30000 y 60000).
También nos preguntará el nivel de cifrado que deseamos tener entre el ordenador remoto y el servidor
Los servidores DNS que queremos utilizar dentro de nuestra conexión.
Una vez hecho esto, ya tendremos un servidor VPN corriendo en nuestra flamante Raspberry PI. Ahora tendremos que crear las «llaves» para que los usuarios puedan acceder al servidor VPN.
Crear los certificados para los usuarios
Para crear las llaves (o los certificados) tendremos que, con el usuario por defecto ‘pi’ ejecutar el siguiente comando:
sudo pivpn add
Con este comando generaremos en el directorio /home/pi/ovpns un archivo llave (certificado) ARCHIVO.ovpn con todos los parámetros y certificados necesarios de OpenVPN para que alguien pueda conectarse.
Cada certificado solo puede ser utilizado por una conexión simultanea, por lo que si quieres poder conectarte desde varios sistemas, necesitarás generar dos certificados distintos.
Todos los clientes, una vez conectados tendrán, por defecto, una dirección IP interna del rango: 10.8.0.X (diferente al del resto de la red interna) pero todos los usuarios conectados podrán verse entre sí.
Mapear el puerto seleccionado en el router
Ahora tenemos que acceder al router y mapear el puerto que hayamos configurado en la raspberry para el servidor OpenVPN, de manera que cuando alguien acceda a dicho puerto, se reenvíe a la Raspberry PI. (es necesario que el puerto del router y el que hemos configurado sean el mismo).
Configurar el cliente
Cliente para Windows
Una vez tenemos el archivo certificado con extensión .ovpn, es el momento de instalar un cliente en nuestro sistema operativo y cargarle dicho certificado para que pueda conectarse.
Para Mac, yo recomiendo TunnelBlick. Se instala, se selecciona el archivo ARCHIVO.ovpn que se desea utilizar y listo!
Para Linux, tan solo hay que instalar el paquete ‘openvpn’ y ejecutarlo tal que así:
openvpn –config ARCHIVO.ovpn
Extras importantes e interesantes
Si en lugar de utilizar el puerto 1194/UDP, utilizásemos uno del tipo 80/TCP, podríamos usar esta conexión en aquellas redes que sólo permiten navegar a una web (como algunos hoteles, convenciones, etc.). De esta manera, este sistema nos ayudará a saltar a la red interna y poder navegar con total seguridad aunque la red en la que estemos no permita otro tipo de accesos.
Es importante saber que los archivos generados con los certificados de clientes van asociados a la dirección IP y puerto externo a la que nos vamos a conectar, de manera que si la oficina cambia de dirección IP habría que rehacer los certificados o modificarlos manualmente con un editor (ya que es un archivo de texto plano)
Si utilizas VPN para cifrar la VoIP (UDP), si para la VPN usas un protocolo TCP, entonces estarás encapsulando todo el tráfico en paquetes TCP, por lo que en VoIP pueden aparecer micro-cortes en el audio en redes de baja y media calidad, además de que para evitar contagiar de Coronavirus, es mejor no hacer handshaking y seguir usando paquetes UDP siempre. 😉
Este sistema es el que utilizo para conectarme a la red interna de mi casa desde hace varios años, por lo que puedo garantizar que no sólo funciona estupendamente si no que además es una de las mejores formas de acceder remotamente a la red interna.
Hay muchísimas opciones dentro del servidor OpenVPN, pero desde este artículo intentamos explicar brevemente cómo configurarlo para una oficina pequeña y un comportamiento estándar útil que nos facilite el trabajo en remoto ahora que desde el gobierno se está recomendando a las empresas que opten por el teletrabajo para evitar contagios.
