Debian & Comunicacion

Concentrador VPN Site-to-Site: Infraestructura PKI y Configuración del servidor

2016-06-07T00:56:00.001+02:00

Tal y como dicta el título, en esta entrada vamos a configurar un concentrador VPN utilizando OpenVPN (2.2.1) para el servicio en sí y Debian Wheezy (7.10) como Sistema Operativo. Podriamos optar por soluciones comerciales de renombrados fabricantes y gastarnos los cuartos en aparatitos bonitos con interfaces de gestión mejoradas que facilitan la vida de los administradores. Pero no.... A mi me gusta el riesgo de las licencias GPL y del software sin garantía del desarrollador pero con la garantía y el compromiso de la comunidad.

Como su nombre indica, un concentrador VPN no es mas que un equipo que se encarga de aglutinar todas las conexiones VPN de nuestros clientes, ya bien sea de nuestros puestos de trabajo como de sedes remotas conectadas a través de Internet de una forma segura. En nuestro caso vamos a realizar una configuración Site-to-Site que normalmente se utiliza para conectar dos o más sedes remotas y enrutar el direccionamiento LAN entre los distintos clientes.

Lo primero que debemos hacer es instalar el software del servidor. Por manias o costumbres que tiene cada uno, además de instalar el paquete openvpn siempre me gusta instalar las utilidades User Mode Linux (uml-utilities) que no son necesarias pero yo lo hago. Una vez hecho esto, debemos crear nuestra infraestructura de clave pública (PKI) que utilizaremos a la hora de conectar nuestros equipos.

Para la creación de todos los certificados utilizaremos easy-rsa y como ya comenté en entradas anteriores, en la versión Wheezy de Debian viene integrado en la documentación del paquete. Concretamente, en la ruta /usr/share/doc/openvpn/examples/easy-rsa/2.0/ que es donde está alojada la última versión de los scripts. Lo primero que haremos será editar el fichero de configuración vars para adecuarlo a nuestra infraestructura.

Una vez guardados los cambios del fichero, que no son más que variables como su nombre indica, deberemos aplicarlo en el sistema. Para ello ejecutamos la comando source vars ó . vars desde el directorio raíz de easy-rsa y obligatoriamente tendremos que ejecutar el script clean-all si es la primera vez que lo utilizamos. Mención especial a que dicho script nos borra el directorio donde se generan los certificados por lo que mucho cuidado de ejecutarlo si no tenemos un backup de los mismos.

Una vez tenemos realizada la configuración para nuestra infraestructura, lo primero que hay que hacer es crear nuestra Certificate Authority y lo realizaremos utilizando el script build-ca. De la siguiente captura, reseñar que el campo Country Name (variable KEY_COUNTRY) utiliza alguna nomenclatura estandar y no puede contener más de dos caracteres por lo que no nos dejará utilizar "Pais" como valor de dicha variable.

Una vez generada nuestra propia CA, lo siguiente que generaremos será la clave con los parámetros Diffie-Hellman y lo creamos utilizando el script build-dh.

Ahora toca el turno de crear el certificado para el servidor VPN, para ello ejecutamos el script build-key-server pasándole como argumento el Common Name con el que queremos que se genere dicho certificado. Será necesario aceptar o modificar las variables globales anteriormente definidas en el fichero vars así como introducir nuevos datos según nos valla pidiendo el script.

A continuación nos muestra la información que va estar visible en el certificado y nos pregunta si queremos firmarlo. La respuesta obvia es si y con ello se genera el Certificate signing request que deberemos confirmar para la creación del certificado.

De igual manera crearemos los certificados de los clientes utilizando el script build-key pasándole nuevamente el CN con el que queremos que se genere el certificado. Aceptaremos y añadiremos los datos que nos vaya pidiendo el script.

Tras ello firmaremos el certificado para generar el CSR y lo confirmamos para creación del mismo al igual que hicimos a la hora de crear el certificado del servidor.

Crearemos tantos certificados clientes como sean necesarios. En el caso que nos ocupa sólo son dos y están almacenados junto con el resto de certificados en un directorio llamado keys dentro de la raiz de easy-rsa.

Copiaremos el certificado de la CA, los parametros DH y del servidor tanto el certificado como la clave privada a la raiz del directorio de configuración. En el caso que queramos almacenar los certificados en otro directorio deberemos especificar la ruta correcta (absoluta o relativa) de los mismos en el fichero de configuración.

No esta de mas decir la importancia que tienen estos ficheros y con mayor relevancia la clave privada de nuestra CA, ca.key. Dentro de la documentación de OpenVPN hay un apartado en el que explica con más detalle toda la creación de la infraestructura PKI y en la que encontramos una tabla (subapartado Key Files) con información de quién necesita cada fichero, por qué y si es necesario mantenerlo a buen recaudo.

Bien, en este punto tenemos toda la configuración de nuestra infraestructura de clave pública preparada para empezar a desplegar el servicio. Dentro de la documentación incluida en el paquete, /usr/share/doc/openvpn, también tenemos a nuestra disposición ficheros de configuración de ejemplo en los que basar nuestras configuraciones tanto para los servidores como los clientes.

Ahora realizamos la configuración del servidor donde modificaremos la directiva local para establecer la IP donde escuchará el servicio, así como las directivas ca, cert, key y dh con los valores del certificado de la CA, certificado del servidor, la clave privada del servidor y el fichero con los parámetros DH respectivamente.

Siguiendo el fichero de configuración, adecuaremos el direccionamiento que vayamos a utiliza con la directiva server y en mi caso me gusta habilitar la directiva client-to-client para que los clientes se puedan ver entre sí pero eso es otro tema. Recomendablemente, activaremos la autenticación TLS con la directiva tls-auth y cambiaremos el algoritmo de cifrado a AES-128-CBC en la opción cipher.

Como última recomendación, para sistemas Linux podemos reducir los privilegios del proceso tras la inicialización del servicio con las directivas user y group. En la siguiente captura se recogen todos los parámetros de configuración con los que podríamos levantar perfectamente el servicio y conectar nuestros clientes de forma satisfactoria.

Antes de ello deberemos generar la clave para la autenticación TLS activada anteriormente. El comando que debemos ejecutar es openvpn --genkey --secret <Name>.key y colocaremos la clave resultante en la raiz del directorio de configuración de OpenVPN o el la ruta que hayamos especificado en la directiva tls-auth.

Pero nuestra idea es montar un concentrador Site-to-Site, actualmente tenemos la parte del concentrador pero no la del Site-to-Site. Para ello será necesario agregar las algunas directivas al fichero de configuración.

Empezaré comentando topology porque hasta hace poco no lo conocía y me parece un parámetro de configuración muy llamativo, del que no comprendo por qué no está ya implementado por defecto ni siquiera en la rama actual del desarrollo por motivos de retrocompatibilidad.Tal y como dicen en la documentación de la directiva:

"The only real reason to use the net30 topology is when requiring support for Windows clients before 2.0.9, or when any Windows clients must be supported and non-Windows clients must be supported that cannot set IP+netmask on the tun adapter. These conditions are rare, and the 2.0.9 client is around 7 years out of date as of 2014."

El valor por defecto es net30 pero si establecemos el valor a subnet, conseguimos entregar todo el direccionamiento de la red que hayamos especificado en la directiva server entregando una IP por cliente y no utilizar cuatro direcciones por cada uno de ellos. He de reconocer que la versión actual de Wheezy no está compilada a la última versión (OpenVPN 2.2.1 [...] built on Dec 1 2014) pero me parece que 7 años de retrocompatibilidad más otros dos a la fecha actual de una versión obsoleta por unas condiciones muy específicas es un poco exagerado.

Siguiendo con las directivas, la siguiente será client-config-dir en la que especificar, como su propio nombre indica, el directorio que contendrá las opciones de configuración particulares para cada cliente. En dicho directorio, crearemos un fichero de configuración con el CN que hayamos asignado a cada cliente y en cada uno especificaremos la dirección IP que van a recibir con la directiva ifconfig-push, la ruta LAN interna de cada cliente utilizando la directiva iroute así como le publicaremos la ruta del resto de clientes con la opción push junto con la ruta correspondiente.

Ya para ir acabando con todo el tema de la configuración del servidor, queda comentar la directiva route que sirve para anunciarle al mismo las redes por las que se espera recibir o enviar paquetes. Tras todos esos cambios, levantamos el servicio y encontramos una serie de mensajes nuevos en el log del servidor.

"[...]
OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
OpenVPN ROUTE: failed to parse/resolve route for host/network: <Network IP>
[...]"

Según se lee en el mensaje, nos dice algo de que OpenVPN necesita un gateway para la opción route y no hay valores por defecto en la configuración. Nos está diciendo la directiva que está fallando y tras una pequeña búsqueda, encontramos una solución (seguro que hay más) que es añadirle la IP que utilizará como gateway el servidor VPN para las rutas de los clientes.

Tras reiniciar el servicio, todo funciona correctamente y el log está limpio de errores o advertencias.

Como la entrada empieza a hacerse un poco larga voy a dividirla en dos, en esta quedaría cubierta toda la parte de la creación de nuestra infraestructura PKI y la configuración del servidor OpenVPN. En la siguiente entrada, realizaré la configuración de un par de clientes basados en pfSense en su última versión así como algunas comprobaciones para corroborar que el sistema funciona correctamente.

Un saludo, Brixton Cat.

OpenVPN: Conectando pfSense con Endian UTM

2016-05-04T01:56:00.001+02:00

Últimamente el tema va de firewalls y conexiones VPN, en cuanto al blog se refiere, y en este caso se trata de conectar una máquina pfSense contra un Endian UTM utilizando OpenVPN ya que ambas distribuciones lo incorporan por defecto. En mi caso, pfSense es una distribución que conozco hace más tiempo pero Endian hasta hace poco no he tenido el gusto de conocerlo y no me ha decepcionado.

Endian es un proyecto Open Source que nació en el año 2003 por un grupo de profesionales y entusiastas de las telecomunicaciones y Linux que tenían una idea fija: "Desarrollar un Gestor Unificado de Amenazas (UTM) Open Source que fuese el más poderoso del mundo y fácil de usar" (Traducción libre de lo que aparece en la historia de la compañia).

En nuestro caso se trata de montar un servidor OpenVPN en un Endian y para ello utilizaré la versión 3.0.5-beta1 pero el proceso es el mismo para la anterior release (3.0.0), ambas disponibles desde la página de descarga de la Comunidad. El cliente de pruebas será pfSense pero a diferencia de la entrada anterior, utilizaré la versión 2.3 que ha sido publicada a principios de mes pasado.

En esta nueva RC de pfSense hay un cambio generacional que incorpora muchas novedades como la actualización de la GUI a una interfaz Bootstrap dinámica con AJAX mucho más moderna, la gestión de paquetes ahora es controlada completamente por pkg favoreciendo la actualización por partes del software, NGINX como servidor Web, PHP 5.6, y otros tantos cambios como la eliminación del servidor VPN PPTP, el cifrado WEP para los AP, TLS 1.0 para el servidor Web, cifrado DES para conexiones IPsec, etc. Todos los detalles en el changelog. A lo que venimos...

En el menú superior del Endian, vamos a la parte de VPN y tras habilitar el servidor seleccionamos como método de autenticación Certificado X.509 y para el certificado dejamos la opción Usar certificado seleccionado. Al ser de una máquina de pruebas utilizaré tanto la CA como el certificado por defecto para las configuraciones, en un entorno real habría que crear nuestra propia CA y el certificado asociado a la misma.

Tras guardar y aplicar cambios, especificamos la IP en la que escuchará el servicio y el puerto, que por defecto es el 1194, asi como el tipo de interfaz: TUN o TAP y el protocolo. En mi caso son interfaces tipo TUN y sólamente hay que especificar la red para la VPN: 10.8.0.0/24.

Incluso tenemos opciones avanzadas con las que configurar rutas, DNS, nombre de dominio así como otras opciones para nuestros clientes.

Tras hacer todas las configuraciones y volver a guardar y aplicar cambios (lo pongo en negrita porque son apartados de configuración independientes), tenemos nuestro servidor OpenVPN listo y funcional.

Ahora pasaremos a crear el certificado para el cliente y para ello en el menú de la izquierda accedemos al apartado Certificados. Como comentaba antes, por defecto nos crea una CA y un certificado que es usado para el servidor HTTPS y es el mismo que voy a utilizar para el servidor OpenVPN. En este punto, cabe destacar que por defecto también nos crea una Lista de Revocación de Certificados (CRL) por si se da el caso que necesitemos dar de baja algún certificado.

Pulsando en Añadir nuevo certificado pasamos a un formulario en el que escribiremos los datos del propietario del mismo, nuestro cliente pfSense, siendo imprescindibles los campos: Nombre común y la contraseña que protege la lectura del certificado en formato PKCS12.

Una vez creado el certificado, en la lista de los mismos tenemos una serie de herramientas en la columna Acciones. De izquierda a derecha: La primera de ellas nos muestra información del certificado, la segunda nos descarga solamente el certificado en formato PEM, la tercera en formato PKCS12 que es la que nos interesa ya que también incluye el certificado de la CA y la clave privada, con la cuarta eliminamos la clave privada y con la última revocamos el certificado.

Tras haber generado el certificado para nuestro cliente tenemos que prepararlo para poder utilizarlo en nuestro pfSense. Como había comentado, nos descargaremos el certificado en formato PKCS12 y extraeremos de él los datos de la CA, el certificado y la clave privada en formato PEM con el comando:

openssl pkcs12 -in pfSense.home.labcert.p12 -out pfSense.home.labcert.pem -nodes

Después de extraer los datos del certificado descargado del servidor, pasamos a realizar la configuración en el cliente. Para ello accedemos a System > Cert. Manager y lo primero que tenemos que hacer, como ya hicimos en la entrada anterior, es crear la CA de nuestro Endian en el pfSense.

Pulsamos en Add y entramos en el formulario para importar un certificado ya creado: Import an existing Certificate Authority. Damos un nombre descriptivo al certificado y en el campo Certificate data pegamos los datos del certificado de la CA.

En mi caso, el certificado PEM que hemos extraido del Endian me lo ha estructurado de la siguiente manera: Cert. cliente, Cert. CA, Key cliente. Con una serie de campos antes de los bloques BEGIN/END con los datos del certificado o de la clave privada según sea el caso.

Clave privada solo hay una asi que con esa no hay problemas y para los certificados solo tenemos que fijarnos en el campo subject que indica el propietario del mismo ya que el issuer siempre va a ser igual, la CA de nuestro Endian.

Una vez guardados cambios, podemos pasar a importar el certificado y la clave privada para el cliente OpenVPN. Para ello desde el mismo administrador de certificados, pulsamos en la pestaña Certificates y en Add para crearlo dándole un nombre descriptivo y copiando los datos del certificado y de la clave privada del mismo.

Tras guardar cambios, ya podemos pasar a configurar el cliente desde el menú superior accediendo a VPN > OpenVPN y después en la pestaña Clients. El modo de servidor es SSL/TLS, el protocolo UDP, tipo TUN para la interfaz vitual y la WAN como la interfaz física que queremos utilizar del firewall. Además de ello, tendremos que especificar la dirección IP y el puerto donde tratará de conectarse el cliente.

Le damos un nombre descriptivo a la configuración del cliente y pasamos a la parte de autenticación.

Como en nuestro caso se realiza a través de certificados, obviamos los campos Username y Password y nos centramos en la parte de Cryptographic Settings. Tenemos que deshabilitar la autenticación TLS dado que no está configurada en el servidor, el certificado de la CA es el del Endian que es el único que tenemos y el certificado del cliente es el que acabamos de crear.

Haciendo un poco de memoria de la entrada anterior, OpenVPN por defecto utiliza el cifrado Blowfish por lo que también deberemos cambiarlo en la configuración del cliente.

Ya por último cambiar el tipo de compresión a Enabled with Adaptive Compression.

Una vez guardados los cambios se establece la conexión entre los peers y si todo ha salido correctamente deberíamos verlo en Estado > Conexiones VPN de nuestro Endian.

Bien, una vez he tenemos conexión entre las máquinas vamos a pasar a ver los logs para corregir errores o alertas. Revisando el log del servidor vemos como se inicializa el servicio y nos encontramos la primera advertencia:

WARNING: file "/var/efw/vpn/ca/certs/192.168.173.243key.pem" is group or others accessible.

Nos conectamos por SSH al Endian y nos dirigimos a la ruta en cuestión, /var/efw/vpn/ca/certs, y comprobamos que efectivamente la clave privada tiene permisos de lectura y escritura para el propietario, root, pero también de lectura para el grupo y el resto.

El servicio se ejecuta con el usuario openvpn y si tratamos de cambiarlo a nobody se ejectuta pero da unos errores a la hora de borrar archivos temporales. Como el usuario openvpn tiene las mismas limitaciones que nobody, he cambiado el propietario y el grupo y le he quitado el permiso de lectura al grupo y al resto.

Tras reiniciar el servicio con el comando jobcontrol restart openvpnjob, el servicio se ejectuta correctamente sin dicha advertencia pero salta la notificación de la ejecución de scripts personalizados y por defecto está en 3 al igual que pasaba en pfSense.

Cambiando dicho valor a 2 en el archivo de plantilla /etc/openvpn/openvpn.conf.tmpl sigue apareciendo el mensaje pero no permitiremos el pase de contraseñas como variables de entorno.

En el log del pfsense nos aparece una advertencia ya conocida de la entrada anterior:

WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.

Para quitar dicha advertencia deberemos añadir en la configuración avanzada de nuestro cliente la opción: ns-cert-type server.

Ya para ir acabando, en ambos equipos aparecen mensajes de alerta informando que no hay concordancia entre el tamaño máximo de paquetes (MTU) tanto de la interfaz virtual, tun_mtu, como del total del enlace, link_mtu. La advertencia en cuestion en el lado del clientes es:

WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1574'
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'.

Se trata de una advertencia que comentan en la documentación oficial (Al final del todo) de Endian, pero que me queda con la mosca detrás de la oreja... En ella dicen que utilizan la directiva mssfix de OpenVPN para anunciar a los clientes tamaño máximo de MTU que deben utilizar, que por defecto y por compatibilidad se establece en 1500 bytes.

"The Endian UTM Appliance sets a limit of 1450 bytes to the size of the VPN’s MTU, to prevent problems with the common MTU value used by the ISP, which is 1500."

Pero revisando el archivo de plantilla que utiliza Endian para generar el fichero de configuración, /etc/openvpn/openvpn.conf.tmpl, nos encontramos la directiva tun-mtu-extra con valor 32.

Para solucionar dicha alerta, en el lado del servidor podemos comentar simplemente la línea dentro del fichero de configuración que amplia el tamaño de los paquetes.

O en el lado del cliente podremos utilizar las directivas tun-mtu y tun-mtu-extra para que haya concordancia entre el tamaño que espera el servidor y el que tiene configurado el cliente.

En cualquier caso, tanto si modificamos la configuración del servidor como del cliente deberíamos de tener conexión entre las máquinas y sin ningún error o advertencia en los logs.

Un saludo, Brixton Cat.

pfSense como cliente OpenVPN

2016-01-07T23:59:00.001+01:00

Empiezo esta entrada mientras se termina de instalar una máquina virtual con Debian Jessie, 8.2, que utilizaré como servidor OpenVPN y con la que comentaré el procedimiento para conectar el cliente incluido por defecto en pfSense. En una "próxima" entrada (entrecomillo eso de próxima) me gustaría comentar la instalación de un servidor OpenVPN y las distintas opciones de configuración.

Para el que dudo no haya leído, conozca o haya tocado en alguna ocasión pfSense, comentar someramente que es una distribución basada en FreeBSD orientada al mundo de las redes y más especificamente a routers y firewalls. Cuenta con infinidad de opciones de configuración y servicios que vienen instalados por defecto, además de bastantes aplicaciones de terceros que podemos instalar para añadir más servicios a nuestro equipo.

Pero vamos al trabajo... Partiendo de una instalación básica de un servidor OpenVPN como la que se muestra en la siguiente captura del fichero de configuración, comentaré los pasos realizados para la conexión de pfSense revisando el log del servidor para la resolución de problemas que surjan en el proceso.

Una vez realizada la configuración, revisamos el fichero /var/log/syslog para ver los mensajes que envia el demonio tras un incio del servicio. La información que arroja va desde las versiones del software, el usuario con el que se ejecuta el servicio e información sobre la red como el gateway por defecto o los comandos para levantar la IP virutal que establecerá el tunel cifrado de los clientes.

Una vez tengamos nuestra máquina de pfSense instalada y realizada la configuración inicial, deberemos importar el certificado de nuestra Certificate Authority que habremos generado a la hora de configurar nuestro servidor VPN. Todos los certificados han sido creados con la herramienta easy-rsa. Para ello desde el menú System > Cert Manager, en la pestaña CAs agregaremos el certificado de nuestra CA de pruebas.

Del mismo modo en la pestaña Certificates, es necesario añadir el certificado y la clave privada generados para este cliente.

Ahora es el momento de definir las opciones de configuración del cliente OpenVPN. Para ello accedemos a la pestaña Client desde el menú VPN > OpenVPN:

Siendo necesario rellenar los siguientes parametros de la configuración:

- Server host or address: Dirección del servidor OpenVPN.
- Description: Nombre descriptivo para la conexión.
- Peer Certificate Authority: El certificado de la CA añadida anteriormente.
- Client Certificate: El certificado del cliente VPN añadido anteriormente.
- IPv4 Tunnel Network: La dirección de red junto con la máscara de red de la VPN.

Con estos parametros podemos empezar a jugar y a observar los distintos mensajes del servidor. En primer lugar nos arroja el siguiente error:

TLS Error: reading acknowledgement record from packet
[...]
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, client-instance restarting

Dicho error es debido a la autenticación TLS que se utiliza para establecer el túnel ya que no hay concordancia entre lo que envía el cliente, recibe y responde el servidor. Por defecto pfSense habilita dicha opción (TLS Authentication) y genera una nueva clave para la conexión:

En el fichero de configuración del servidor OpenVPN, lo encontramos como una recomendación de seguridad añadida y nos informa del comando a ejecutar para generar dicha clave: openvpn --genkey --secret ta.key.

Podemos simplemente deshabilitar dicha opción o como medida de protección y un extra en seguridad, acostumbrarnos a utilizarlo en nuestras instalaciones. Para ello deberemos copiar la clave generada con el comando anterior a la configuración del cliente OpenVPN de nuestro pfSense.

Una vez guardados cambios, el cliente vuelve a intentar conectar con el servidor y se observa como la verificación del certificado del cliente es correcta y prosigue el intento de conexión:

Hay algunos warnings y como veremos, el causante del siguiente error se trata de este:

El log del servidor se inunda del siguiente mensaje que informa que ha fallado el descifrado y ha expirado el tiempo de inactividad del cliente por lo que es rechazado por el sistema:

Authenticate/Decrypt packet error: cipher final failed
[...]
[fw.home.lab] Inactivity timeout (--ping-restart), restarting
SIGUSR1[soft,ping-restart] received, client-instance restarting

¿Cómo solucionar este error? pfSense utiliza el método de cifrado AES-128-CBC mientras que OpenVPN por defecto utiliza BF-CBC como se muestra en la siguiente captura:

Podemos utilizar tanto el cifrado AES como el Blowfish, ambos de 128 bits dado que ambas plataformas lo soportan.

En mi caso, opto por el cifrado AES. Una vez guardados cambios y reiniciado el servicio, volvemos a revisar los mensajes del servidor en busca de más errores en la configuración. Siguen apareciendo algunos warnings pero en este caso podemos ver que se inicializa el cifrado AES-128-CBC correctamente:

La conexión de nuestro cliente pfSense contra el servidor se realiza como podemos observar en la siguiente captura:

Pero en el log del servidor no dejan de aparecer los siguientes mensajes:

Bad LZO decompression header byte: 42
[...]
[fw.home.lab] Inactivity timeout (--ping-restart), restarting
SIGUSR1[soft,ping-restart] received, client-instance restarting

Hasta que el cliente supera el tiempo de inactividad y se resetea la conexión del mismo.

Si nos fijamos en la advertencia en cuestión:

WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'

Vemos claramente que nos indica que el servidor está utilizando el parámetro de configuración comp-lzo mientras que en el cliente no aparece. Dicha opción hace que el servidor comprima el tráfico a través del algoritmo LZO y también debe ser habilitada en el cliente.

Para ello, dentro de la configuración de nuestro cliente OpenVPN en pfSense, buscamos la opción Compression y en la lista desplegable seleccionamos la opción Enabled with Adaptative Compression como se muestra en la siguiente imagen.

Una vez guardados los cambios, podemos ver el log del servidor sin ningún tipo de errores o advertencias a la hora de establecerse la conexión de nuestro cliente VPN:

No debemos olvidar que pfSense es una distribución orientada al mundo de firewalls por lo que hasta que no permitamos el tráfico por la VPN no vamos a tener mucho éxito en nuestras pruebas. Para ello, deberemos acceder desde el menú Firewall > Rules a la pestaña OpenVPN para agregar una nueva regla a nuestra máquina.

En este caso como se trata de máquinas de laboratorio, sólo voy a permitir el tráfico ICMP sobre IPv4 para comprobar que hay conexión en la red VPN.

Pudiendo apreciar que la regla aplicada al firewall funciona correctamente así como la conexión de nuestro cliente al servidor OpenVPN.

Una vez hecho esto y comprobado que todo funciona como debe, ahora toca revisar el log de nuestro querido pfSense del que de momento no hemos hablado siquiera. Para ello desde el menú Status entramos en el apartado System Logs y accedemos a la pestaña OpenVPN para ver los mensajes del cliente:

Podemos observar algunos warnings y el más preocupante se trata del siguiente:

WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.

Como podemos leer en la página que el mismo mensaje nos ofrece, se trata de añadir una capa más de seguridad para evitar en la medida de lo posible ataques MitM sobre la conexión SSL/TLS con la que se establece el tunel.

Para ello, a partir de la version 2.1, si hemos utilizado el script build-key-server incluido en la suite easy-rsa para crear el certificado del servidor, simplemente añadiremos la directiva: remote-cert-tls server en las opciones avanzadas de la configuración:

En este punto solamente comentar que en Debian Jessie, easy-rsa es un paquete independiente que es sugerido a la hora de instalar OpenVPN, a diferencia de la versión en Debian Wheezy que estaba incluida en la documentación del mismo.

La siguiente advertencia dice lo siguiente:

WARNING: using --pull/--client and --ifconfig together is probably not what you want

Buscando por Internet no he encontrado nada relacionado con el mensaje por lo que he tirado del fichero de configuración que está almacenado en el directorio /vat/etc/openvpn.

Se puede observar que está incluida la directiva ifconfig que se utiliza para especificar el direccionamiento del cliente dentro del tunel VPN. Como no encontraba mucha información me puse a revisar los scripts que generan los archivos de configuración del cliente.

La interfaz gráfica de pfSense está escrita en PHP y los ficheros de configuración se generan tras guardar cambios en los parámetros de configuración de cada servicio. Las funciones PHP que la interfaz gráfica utiliza están almacenadas en el directorio /etc/inc y en el caso de OpenVPN, se llama openvpn_reconfigure y se encuentra en el fichero openvpn.inc:

El parámetro ifconfig del fichero de configuración se crea en el condicional que muestra la siguiente captura de pantalla, donde si la opción IPv4 Tunnel Network está habilitada se utilizará para asignar la IP local y la máscara de red en el caso de interfaces TAP y la IP local y la del servidor en el caso de interfaces tipo TUN.

Por lo que quitando dicho valor en la configuración del cliente OpenVPN desaparece dicha advertencia y todos contentos.

Ya para ir acabando, queda comentar una notificación que aparece en el log del cliente informando que la directiva script-security está habilitada y permite ejecutar scripts definidos por el usuario:

NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

OpenVPN permite ejecutar scripts personalizados de inicio y cierre de conexión que se definen con las directivas up y down respectivamente. Para poder ejecutar dichos scripts, es necesario habilitar la directiva script-security comentada anteriormente y asociarle un valor igual o mayor que 2 como se puede leer en el man del programa.

pfSense habilita dicha opción con el valor 3 que no se recomienda por ser inseguro ya que permite almacenar contraseñas como variables de entorno. Si cambiamos el valor a 2 sigue apareciendo la notificación anterior pero ganaremos algo en seguridad.

De igual manera si descomentamos las directivas user y group de la función openvpn_reconfigure, el servicio se ejecutará con el usuario y el grupo nobody y aseguraremos aun más la configuración de nuestro cliente.

Un saludo, Brixton Cat.

Compilacion e instalación de FreeRADIUS 3 a la manera Debian

2015-05-06T01:52:00.000+02:00

En esta entrada explicaré el procedimiento para la compilación e instalación del servidor FreeRADIUS en su última release estable, versión 3.0.8, pero a la manera de Debian. Además, no hace apenas ni un mes ha sido publicada la nueva versión estable de Debian y no podía dejar pasar la oportunidad de probarla en esta entrada.

Cabe decir que el proyecto de FreeRADIUS nació en el año 1.999 y con el tiempo se ha convertido en uno de los protocolos AAA más utilizado en empresas, universidades e ISPs repartidos por todo el globo. Millones de usuarios lo utilizan diariamente para conectarse a Internet y para acceder a sus equipos y aplicaciones dada la modularidad y flexibilidad del software que incluye un pseudolenguaje de programación propio denominado unlang.

Los pasos descritos en esta entrada han sido recopilados de instalaciones en equipos de 64 bits tanto en máquinas físicas como en entornos virtuales y es posible que algun paquete sea innecesario en algún caso pero eso es harina de otro costal... Partiendo de una máquina recien instalada con Debian 8.0, aka Jessie, es necesario instalar los siguientes paquetes:

fakeroot dpkg-dev libssl-dev quilt libcurl4-openssl-dev libjson0 libjson0-dev libreadline-dev libsqlite3-dev libtalloc-dev libyubikey-dev ssl-cert libcap-dev libwbclient-dev

Y comprobamos e instalamos el resto de dependencias para el paquete freeradius con el comando:

apt-get build-dep freeradius

En el caso de que este comando falle porque es necesario instalar algún otro paquete, deberemos instalarlo y en el caso contrario tendremos un sistema operativo Debian preparado para compilar e instalar el servidor FreeRADIUS.

Para continuar nos descargamos el código fuente desde la página de descarga del desarrollador y lo descomprimimos. Dentro del paquete, existe un directorio llamado debian donde se encuentra el fichero rules así como los demás ficheros necesarios para generar los paquetes .deb tales como los scripts de pre/post instalación y desinstalación de los mismos.

FreeRADIUS tiene soporte para una gran variedad de plataformas, pudiendo encontrar los binarios en los repositorios oficiales de nuestra distribución o compilarlos para nuestro propio equipo como es nuestro caso.

Ejecutando el siguiente comando, y si todo está correcto, empezará la compilación del código fuente finalizando con la creación de los paquetes .deb que instalaremos posteriormente.

fakeroot dpkg-buildpackage -b -uc

En función del servicio que vaya a brindar o de las opciones de configuración de esa máquina, se deberían instalar unos paquetes, u otros o incluso todos si la situación lo requiriese... En este caso, como se trata de un entorno de pruebas instalaré todos los paquetes con el comando:

dpkg -i ../*.deb

Hasta aquí la instalación de la versión estable de FreeRADIUS, publicada a día de hoy, pero compilando el código fuente a la manera Debian para la recien estrenada versión Jessie que ire introduciendo tanto en mis máquinas de pruebas como en producción a ver que tal se comporta. Ya os iré contando.

Referencias:

- http://wiki.freeradius.org/building/Build#Building-Debian-packages
- Prueba y error

Un saludo, Brixton Cat.

Instalación de OwnCloud sobre Debian Wheezy

2015-01-08T02:16:00.000+01:00

Para empezar bien el año voy a ver si escribo unas líneas para el blog, hace tiempo que lo tengo abandobado y es proposito de año nuevo escribir más a menudo siempre y cuando el tiempo me lo permita. Como dicta el titular de la entrada, voy a describir los pasos que he seguido para instalar un servidor OwnCloud con un backend MySQL en un sistema Debian Wheezy actualizado a la última versión.

Si os preguntáis de que trata ese servidor OwnCloud, qué es lo que hace o deja de hacer... Os recomiendo una pasadita por la página de la documentación oficial, por el manual de administración y de usuarios que son de fácil lectura y os podeis hacer una idea del potencial de este software. Mejor que ellos, yo no lo podría definir asi que manos a la obra.

Inicialmente es necesario añadir el repositorio propio de OwnCloud. En el caso de un sistema operativo Debian Wheezy es necesario agregar el siguiente:

deb http://download.opensuse.org/repositories/isv:/ownCloud:/community/Debian_7.0/ /

Tras ello añadiremos la clave pública con la que verificar el paquete:

wget http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/Release.key

apt-key add - < Release.key

Actualizamos el listado de paquetes con nuestro gestor de paquetes favorito, apt-get o aptitude, e instalamos el paquete owncloud junto con el resto de dependencias.

OwnCloud por defecto utiliza una base de datos SQLite, pero en entornos en producción y con un mayor número de usuarios recomiendan usar otros sistemas de bases de datos relacionales. Entre las distintas opciones de sistemas de bases de datos encontramos: MySQL/MariaDB, SQLite, PostgreSQL y Oracle.

En la instalación de OwnCloud, como dependencia se ha instalado el paquete mysql-server que es el servidor de bases de datos recomendado por los desarrolladores[1]. Nos conectamos al servidor, creamos la base de datos y el usuario SQL para la configuración de OwnCloud.

mysql> CREATE DATABASE owncloud;

mysql> GRANT ALL ON owncloud.* TO 'owncloud'@'localhost' IDENTIFIED BY 'owncloud';

mysql> FLUSH PRIVILEGES;

Estos datos serán los que utilicemos posteriormente en la configuración de la base de datos de nuestro servidor, siendo necesario también introducir un nombre y una contraseña para el usuario administrador.

Durante la instalación de OwnCloud se genera el archivo de configuración principal[2], situado en /var/www/owncloud/config.php y en el mismo directorio también se encuentra un archivo llamado config.sample.php con la documentación de todas las opciones que el servidor permite en tiempo real.

En dicho archivo podemos encontrar desde las claves e Ids únicas del servidor, la versión del programa, la configuración de la base de datos y algunas otras opciones que también describire.

Hay que decir que la configuración de la base de datos se puede hacer desde el archivo config.php, pero es más sencillo y más cómodo realizarlo desde la interfaz gráfica. Por contra, también es necesario conocer dónde modificar los valores en el caso de que sea necesario.

Para garantizar, en la medida de lo posible, la seguridad en la conexión de los clientes a nuestra nube particular configuraremos el servicio HTTPS del servidor Apache.

openssl req -new -x509 -days 365 -nodes -out /etc/ssl/localcerts/apache.pem -keyout /etc/ssl/localcerts/apache.key

chmod 600 /etc/ssl/localcerts/apache*

En mi caso se trata de un entorno de pruebas en el que no cuento con más páginas Web a servir en la misma máquina. Por ello utilizo los archivos de configuración por defecto que el paquete de apache2 proporciona: default y default-ssl; ambos disponibles en la ruta /etc/apache2/sites-availables.

/etc/apache2/sites-availables/default

/etc/apache2/sites-availables/default-ssl

Es necesario habilitar los módulos ssl y rewrite de Apache así como habilitar el archivo por defecto del servidor Web seguro:

a2enmod ssl

a2enmod rewrite

a2ensite default-ssl

Reiniciamos el servicio para que se apliquen los cambios realizados:

/etc/init.d/apache2 restart

Podemos comprobar que la configuración realizada es correcta conectándonos a través de un navegador a la dirección IP del servidor utilizando indistintamente protocolo seguro e inseguro.

Existen varias maneras de realizar las tareas programadas que el servidor necesita, por defecto se utiliza AJAX para ejecutarlas cuando las distintas páginas Web son cargadas. Como recomiendan en la guia de administración[3], configuraremos Cron para la realización de las mismas.

Creamos una nueva tarea programada para el usuario www-data con el comando:

crontab -u www-data -e

E incluimos la siguiente línea para que se ejecute cada 15 minutos el script /var/www/owncloud/cron.php durante todos los días del año:

*/15 * * * * php -f /var/www/owncloud/cron.php > /dev/null 2>&1

En el caso de acceder a la aplicación desde un directorio que no es la raiz del servidor Web será necesario sobreescribirla añadiendo la siguiente directiva en el archivo de configuración /var/www/owncloud/config/config.php:

'overwritewebroot' => '/owncloud',

En nuestro caso no será necesario incluir dicha opción dado que hemos modificado las directivas de Apache definiendo DocumentRoot como el directorio por defecto de OwnCloud, /var/www/owncloud.

Una vez hecho esto, a través de la interfaz Web accedemos a la zona de administración y modificamos el valor por defecto para la realización de las tareas programadas a Cron como se muestra en la siguiente captura.

Actualmente tenemos un servidor OwnCloud funcional pero con todas las opciones por defecto tras la instalación. Ahora toca modificar algunos aspectos para customizarla a nuestro gusto y en este caso lo realizaré a través del archivo de configuración comentado anteriormente.

Una de las directivas básicas que el servidor necesita es el directorio donde se almacena la información de los usuarios, por defecto en /var/www/owncloud/data. Dicha opción podremos modificarla tanto a través de la interfaz Web durante la configuración inicial del servidor o a través de la siguiente opción en el archivo de configuración:

'datadirectory' => '/var/www/owncloud/data',

Otra de las directivas importantes es la que determina desde que nombres domínios o direcciones IP se puede acceder al servidor.

'trusted_domains' =>

array (

0 => '192.168.173.103',

1 => 'domain.name',

),

En nuestro caso como hemos modificado la directiva DocumentRoot de Apache, será recomendable modificar la siguiente opción del fichero de configuración que sobreescribe la url en el navegador del cliente:

'overwrite.cli.url' => 'https://192.168.173.103/',

El idioma por defecto es el Inglés, pero podemos modificarlo utilizando la siguiente opción junto con el código correspondiente a nuestro lenguaje según el archivo /var/www/owncloud/settings/languageCodes.php:

'default_language' => 'es',

Una vez que hemos configurado el servicio HTTPS de Apache, la siguiente directiva fuerza el uso del protocolo seguro para acceder al servidor:

'forcessl' => true,

Podemos quitar el enlace de ayuda del menu de usuario situado en la esquina superior derecha utilizando la siguiente opción en el archivo de configuración:

'knowledgebaseenabled' => false,

A la hora de eliminiar los datos de los usuarios, éstos se envían a una papelera que el servidor incorpora por defecto y de la que podremos modificar el comportamiento con las siguientes opciones:

'trashbin_auto_expire' => true,

Con esta directiva activamos la eliminación automática de los archivos que hayan sido enviados a la papelera una vez hayan superado el tiempo de espera definido en la siguiente directiva:

'trashbin_retention_obligation' => 30,

Está opción fuerza que los archivos almacenados en la papelera sean guardados el número de días que se definan como valor de la misma, en este caso 30 días.

Por defecto, OwnCloud crea un avatar personalizado en función de la primera letra del nombre para el usuario. A través de la siguiente directiva podremos desactivar el uso de los mismos:

'enable_avatars' => false,

Otra opción que puede ser interesante en diferentes entornos en producción es denegar a los usuarios cambiar dichos nombres que serán únicamente generados por los administradores del servidor.

'allow_user_to_change_display_name' => false,

Hay muchas otras opciónes que están documentadas en el archivo config.sample.php así como en la documentación oficial comentada anteriormente.

OwnCloud viene por defecto con un montón de aplicaciones preinstaladas, muchas de ellas imprescindibles, algunas interesantes y otras de ellas a voluntad del administrador en función del tipo de servicio que se requiera dar. Algunas aplicaciones por defecto instaladas son: Calendario, Contactos, Actividad, visores de documentos, imágenes, vídeos, Editor de texto, etc...

Una aplicación interesante a tener en cuenta es la de cifrar los archivos de los usuarios que por defecto viene deshabilitada. En la documentación oficial podreis encontrar información sobre la misma así como algunas limitaciones y como asegurar los documentos de los usuarios en caso de olvido de la contraseña.

También podemos instalar la aplicación Antivirus para los archivos de nuestros usuarios, para lo que será necesario instalar una aplicación de terceros que podemos encontrar en la página oficial de OwnCloud. Nos descargamos el paquete y lo descomprimimos en el directorio /var/www/owncloud/apps. Tras ello, nos diriguimos al gestor de aplicaciones y veremos la nueva aplicación Antivirus para poder habilitarla.

Es necesario instalar el software de ClamAV para que actué en modo demonio en el servidor:

aptitude install clamav clamav-daemon

Como el error anterior indica, no tenemos firmas de antivirus disponibles por lo que primero actualizaremos las bases de firmas y después arrancaremos el demonio ClamAV con los comandos:

freshclam

/etc/init.d/clamav-daemon start

Una vez hecho esto y una vez habilitada la aplicación Antivirus, nos diriguimos al apartado de administración donde encontramos nuevas opciones de configuración de la nueva aplicación que acabamos de instalar.

Configuraremos el modo Demonio y será necesario introducir el fichero utilizado por el servicio como socket de conexión, por defecto viene correctamente configurado para la ruta /var/run/clamav/clamd.ctl.

Con esto termina la instalación, configuración y customización de nuestro propio servidor cloud de una manera fácil y sencilla. El servidor tiene muchas funcionalidades que en esta entrada no han sido descritas pero de las que podeis encontrar mucha información en la documentación oficial.

Referencias

1 - Administrator Manual. 4.9 Database Configuration - Página 62:

The MySQL or MariaDB databases are the recommended database engines. However, because it is a file based database with the least administrative overhead, SQLite is chosen by default.

Note: Because SQLite has some difficulties handling multiple users, we recommend that it be used only for single user ownCloud installations.

2 - Administrator Manual. 4.7.1 Default Parameters - Página 48:

These parameters are configured by the ownCloud installer, and are required for your ownCloud server to operate.

3 - Administrator Manual. 4.3.2 Cron Jobs - Página 45:

You can schedule cron jobs in three ways – using AJAX, Webcron, or cron. The default method is to use AJAX. However, the recommended method is to use cron.

Un saludo, Brixton Cat.

Xen y Virt-Manager: Problemas de conexión

2014-02-15T12:09:00.000+01:00

El otro día me comentaron la posibilidad de instalar un servidor de virtualización y por las condiciones de las máquinas virtuales a alojar, la mejor solución es correr Xen como anfitrión. Una de las condiciones principales es poder virtualizar una PBX basada en Asterisk con hardware para conectar a la red PSTN o a la red RDSI. Mirando los resultados de la siguiente presentación está claro que Xen se asemeja bastante, y mucho, a los resultados recibidos en el sistema sin virtualizar.

Para la instalación del servidor Xen no voy a entrar en detalles. Recomendaré la guía para principiantes de la página oficial que explica paso a paso la instalación sobre un sistema Debian stable y old-stable.

Hasta aquí todo muy bien, fácil y sencillo. Pero ¿cómo administrar nuestro servidor de virtualización y las máquinas virtuales desde un entorno más amigable?

Virt-manager es una herramienta bastante completa y sencilla, lease liviana también, con la que administrar nuestros servidores Xen, KVM y contenedores LXC de manera gráfica tanto local como remotamente a través de SSH, certificados digitales u otros...

Pues bien, después de este pequeña introducción vienen los problemas que he tenido a la hora de conectar virt-manager con un servidor Xen y cómo poder solucionarlos.

SSH: Intercambio de clave

Si no tenemos configurado el intercambio de claves entre nuestro equipo y el servidor nos mostrará el siguiente error:

Detalles:

Unable to connect to libvirt.

You need to install openssh-askpass or similar
to connect to this host.

Libvirt URI is: xen+ssh://root@192.168.173.150/

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 1185, in _open_thread
self.vmm = self._try_open()
File "/usr/share/virt-manager/virtManager/connection.py", line 1167, in _try_open
flags)
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 102, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Cannot recv data: ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied, please try again.
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied, please try again.
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied (publickey,password).
: Conexión reinicializada por la máquina remota

Aparte de la opción que el propio mensaje nos aporta, yo prefiero copiar la clave pública de mi usuario en el servidor remoto ya sea a la antigua usanza* o a través de opciones más modernas.

* cat ~/.ssh/id_rsa.pub | ssh user@address 'cat - >> ~/.ssh/authorized_keys'

Netcat version OpenBSD

Es posible encontrarse con el siguiente error

Detalles:

Unable to connect to libvirt.

The remote host requires a version of netcat/nc
which supports the -U option.

Libvirt URI is: xen+ssh://root@192.168.173.150/

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 1185, in _open_thread
self.vmm = self._try_open()
File "/usr/share/virt-manager/virtManager/connection.py", line 1167, in _try_open
flags)
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 102, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: End of file while reading data: nc: invalid option -- 'U'
nc -h for help: Error de entrada/salida

Para solucionarlo es necesario instalar la versión OpenBSD del paquete Netcat que utiliza la opción -U para la conexión por sockets Unix.

Demonio libvirtd

Si el demonio libvirtd no está instalado y en ejecución recibiremos el siguiente error

Detalles

Unable to connect to libvirt.

End of file while reading data: nc: unix connect failed: No such file or directory: Error de entrada/salida

Verify that the 'libvirtd' daemon is running
on the remote host.

Libvirt URI is: xen+ssh://root@192.168.173.150/

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 1185, in _open_thread
self.vmm = self._try_open()
File "/usr/share/virt-manager/virtManager/connection.py", line 1167, in _try_open
flags)
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 102, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: End of file while reading data: nc: unix connect failed: No such file or directory: Error de entrada/salida

Para solucionarlo, es necesario instalar el paquete libvirt-bin en el servidor.

Xen: Servidor HTTP

El siguiente error, a diferencia de los anteriores, no se soluciona instalando ningún paquete

Detalles

Unable to connect to libvirt.

unable to connect to 'localhost:8000': Conexión rehusada

Verify that the 'libvirtd' daemon is running
on the remote host.

Libvirt URI is: xen+ssh://root@192.168.173.150/

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 1185, in _open_thread
self.vmm = self._try_open()
File "/usr/share/virt-manager/virtManager/connection.py", line 1167, in _try_open
flags)
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 102, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: unable to connect to 'localhost:8000': Conexión rehusada

Para solucionarlo basta con editar el fichero de configuración /etc/xen/xend-config.sxp, añadir la siguiente línea (xend-http-server yes) y reiniciar el servicio con /etc/init.d/xen restart.

Listo, ya está conectado virt-manager a nuestro servidor Xen. He realizado varias instalaciones con el mismo comportamiento, todas ellas realizadas en máquina virtual sobre VirtualBox con Debian Wheeze versión 7.4 como sistema base.

Un saludo, Brixton Cat.

AsteriskNOW: Mas configuraciones SIP e IAX2

2013-12-31T14:44:00.000+01:00

En la anterior entrada de la serie AsteriskNOW realicé la configuración de un par de extensiones con los protocolos SIP e IAX2, registré las extensiones contra la centralita y realiće algunas pruebas de llamadas. En esta entrada comentaré más parámetros de configuración de ambos protocolos así como la instalación de algunos módulos que serán necesarios.

Como comenté en la entrada anterior, a la hora de crear las extensiones aparecen muy pocas opciones de configuración en el campo Device Options, una en el caso de IAX2, pero al editarlas tenemos acceso a bastantes mas parámetros de los que describiré algunos.

Extensión SIP

El parámetro canreinvite se utiliza para permitir que los peers envien peticiones INVITE entre ellos una vez se ha establecido la llamada con el servidor Asterisk. Por defecto está en No pero es recomendable consultar la documentación para adecuar este parámetro a nuestro escenario.

Los contextos (context) son un concepto imprescindible en Asterisk con el organizamos nuestro dialplan en secciones independientes entre sí, el dialplan está compuesto por extensiones, troncales, aplicaciones como IVRs, VoiceMail, Conferences...

La opción host sirve para especificar una dirección IP o un nombre de host específico para la extensión o en caso de ser dynamic permitir que se registre cualquier teléfono con esa extensión.

El type por defecto es friend que es la opción más común a la hora de crear extensiones, este parámetro está relacionado con la manera en la que se manejarán las llamadas entrantes y salientes en la extensión.

Podemos elegir también el protocolo de transporte (transport) que utilizará la extensión: UDP (por defecto), TCP, TLS, WS o combinaciones de estos.

También podemos cifrar las llamadas utilizando el protocolo SRTP en lugar de RTP estableciendo el parámetro encryption en Yes.

Extensión IAX2

Algunos de los parámetros antes descritos también son válidos para clientes IAX2 dado que están relacionados con el comportamiento de Asterisk como context, host o type. Otros como transport o encryption están relacionados con el propio protocolo SIP por lo que en este caso no aparecerán.

Con el parámetro transfer podemos controlar las transferencias de llamadas de la extensión.

El parámetro qualify sirve para enviar al peer una petición de tipo OPTIONS para comprobar el estado de vida del dispositivo. Este parámetro también está disponible en el protocolo SIP en el que además podemos especificar el tiempo de refresco, por defecto 60 segundos.

Con disallow y allow podemos denegar y permitir respectivamente el uso de los codecs de audio que el dispositivo podrá utilizar. Funciona a modo de ACL, en disallow rechazamos todo con all y en el campo allow especificaremos los codecs permitidos separados por el caracter ampersand (&). Estos parámetros también son controlados por la centralita por lo que también están disponibles para el protocolo SIP.

El parámetro requirecalltoken se utiliza para requerir al peer un token de autenticación para registrarse contra la centralita. Dejare el valor No porque estoy utilizando varios softphones para la misma extensión y no me permite loguearme correctamente cuando cambio de cliente.

Módulo Asterisk Settings

Como se puede ver, con la instalación por defecto tenemos acceso a muchos parámetros de configuración de las extensiones pero la mayoría de ellos relacionados con la centralita. Para obtener más parámetros de configuración de los protocolos será necesario instalar los módulos Asterisk SIP Settings y Asterisk IAX Settings.

Pulsando la opción Module Admin localizada en el menú Admin llegamos a la pantalla principal del módulo, pulsando en Check Online nos muestra los módulos instalados, si se pueden actualizar y los que están disponibles en los repositorios. Una vez instalados aparecerán habilitados en la pantalla principal del módulo, recordad que es necesario aplicar la configuración tras la instalación de cualquier módulo.

Los módulos siguen la misma distribución de menús que vimos en la introdución a FreePBX. Desde el menú Settings de la barra de navegación tendremos acceso a los módulos recien instalados.

Opciones SIP

Lo primero que encontramos son las opciones NAT, pulsando en el botón Auto Configure nos resuelve la IP pública y la red local en los campos External IP y Local Network. El campo External IP se utiliza para indicar la IP o el nombre de host que se publicará en el router hacia Internet por lo que le pongo una dirección cualquiera.

Podemos habilitar el soporte para vídeollamadas desde la opción Video Support especificando los codecs que queremos utilizar y un máximo ancho de banda para estas llamadas.

En el apartado MEDIA & RTP Settings también tenemos acceso al parámetro canreinvite visto anteriormente con la opción Reinvite Behavior.

También podemos configurar un lenguaje por defecto especificando el código de caracteres asociado al país.

Las siguientes opciones previenen que un usuario anónimo se registre contra la centralita (Allow SIP Guests) y que pueda realizar llamadas (Allow Anonymous Inbound SIP Calls). Permitiendo el registro de clientes anónimos y denegando las llamadas entrantes anónimas podemos ver los intentos de llamadas de los usuarios registrados como invitados.

Además también es posible introducir los parámetros de configuración que queramos especificando el nombre y el valor de los mismos.

Opciones IAX

Lo primero que encotramos son las opciones de los codecs de audio pero a diferencia del caso anterior tenemos algunas prioridades y opciones de ancho de banda.

Soporte para video nuevamente

Language, Bind Address, Bind Port...

El campo Delay Auth Rejects se utiliza para reforzar la seguridad de la centralita contra ataques de fuerza bruta añadiendo un delay a la hora de rechazar un intento de login incorrecto.

Y al igual que en el caso del protocolo SIP, podemos añadir más parámetros de configuración a través de la opción Other IAX Settings.

Con esta entrada finalizo el repaso sobre las opciones de configuración más reseñables a la hora de crear extensiones en nuestro sistema y reforzar el comportamiento de las mismas. En siguientes entradas comenzaré a describir funcionalidades más atractivas con las que crear una verdadera centralita de telefonía.

Un saludo, Brixton Cat.

AsteriskNOW: Extensiones SIP e IAX2

2013-12-29T17:02:00.002+01:00

Continuando con la serie AsteriskNOW, voy a empezar a describir los pasos para añadir extensiones a la centralita y a hacer algunas pruebas llamando entre distintas extensiones. Asterisk soporta varios protocolos de señalización y transporte entre los que podemos encontrar SIP, IAX2 o DAHDI, este último es utilizado para el hardware (y compatibles) de la compañía Digium como teléfonos o tarjetas de telefonía.

En primer lugar voy a realizar la configuración de una extensión que va a utilizar el protocolo SIP para la señalización y el mantenimiento de las sesiones, mientras que el transporte de la llamada será realizado por protocolos como RTP o SRTP.

Extensión SIP

Desde el menú Applications pulsamos en Extensions para acceder al panel principal donde poder crear nuevas extensiones. En el desplegable elegiremos el tipo de protocolo que utilizará la nueva extensión, por defecto SIP.

Deberemos asignar un número de extensión en el campo User Extension y agregar un nombre descriptivo en el campo Display Name, éste además de aparecer en el terminal donde la extensión está configurada se utilizará como CallerID en las llamadas que la extensión realice.

En el apartado Extension Options encontramos diversas configuraciones como las opciones de Asterisk para las extensiones, timeouts para las llamadas, CallerIDs de salida y de emergencia entre otras opciones. Modificaremos el valor Outbound Concurrency Limit a 1 como medida de seguridad para evitar que se realicen más de una llamada simultánea al exterior.

Deberemos configurar una contraseña robusta para cada extensión sobre todo en sistemas en producción, esto lo configuramos desde el apartado Device Option. En el campo secret se encuentra la contraseña por defecto del dispositivo y tiene toda la pinta de ser un hash MD5. Podremos variar el comportamiento del DTMF en el campo dtmfmode al igual que indicar si nos encontramos detraś de un NAT y vamos a hacer llamadas al exterior.

La parte del VoiceMail la dejo deshabilitada de momento ya que tengo en mente una entrada con todas las opciones que nos permite este módulo.

Y por último guardamos cambios con el botón Submit y aplicamos la configuración con el botón Apply Config que aparece en la barra de navegación.

Una vez creada la extensión, aparece en el menú de la izquierda para poder editarla o eliminarla.

Extensión IAX2

Para configurar una extensión que utilizará el protocolo de señalización y transporte IAX2 elegiremos la opción Generic IAX2 Device en el desplegable y pulsamos el botón Submit. Realmente no hay diferencia entre ambos formularios salvo una excepción, deberemos indicar una extensión para el usuario (User Extension) y un nombre para mostrar en el dispositivo y que será utilizado en el CallerID, Display Name.

Limitamos también las llamadas simultáneas salientes que el dispositivo puede realizar.

Y configuramos una contraseña robusta para el dispositivo en la opción secret. En este caso no aparecen las opciones relativas al DTMF o el NAT pero a la hora de editar las extensiones veremos que aparecen muchos más parámetros.

Dejo el VoiceMail deshabilitado, guardo y aplico la configuración de manera idéntica al caso anterior.

Configuración de clientes

Ahora describiré la configuración de los softphones que utilizarán las extensiones recien creadas, voy a utilizar Linphone como cliente SIP y SFLphone como cliente IAX2 aunque este último también tiene soporte para el protocolo SIP.

Cliente SIP

Una vez instalado el paquete linphone, desde el menú Options en la opción Preferences podemos especificar desde la configuración de la red, los codecs para el audio o el idioma.

Desde la pestaña Manage SIP Accounts podemos añadir cuentas de usuarios SIP y especificar tanto un Display Name como el Username a utilizar. Pulsando en el botón Add aparece una ventana donde introducir la identidad SIP y la dirección IP de la centralita.

Será necesario ingresar la contraseña que hemos configurado para dicha extensión

Quedando la configuración definitiva del terminal de este modo

Si la configuración es correcta, en el teléfono se muestra un mensaje informando que se ha registrado satisfactoriamente contra la centralita.

Cliente IAX2

Una vez instalado el paquete sflphone-gnome, lastima que la versión de KDE sea inestable, desde el menú Editar tenemos acceso a las Preferencias de la aplicación y las Cuentas. Dentro de la configuración de las cuentas añadimos una e ingresamos los siguientes parámetros:

- Alias: Nombre descriptivo para la cuenta.
- Protocolo: En este caso IAX2.
- Nombre del equipo: Dirección IP o nombre de host de la centralita.
- Usuario: El número de la extensión.
- Contraseña: El secret configurado a la extensión.

Una vez creada la cuenta podemos ver el estado de la misma e informa que ha fallado la autenticación.

Podemos tirar de los logs de Asterisk (Reports > Asterisk Logs Files) pero a mi siempre me parece más entretenida la consola y en este caso encima colorea la salida del debug.

El error en cuestión es:

Call rejected, CallToken Support required. If unexpected, resolve by placing address 192.168.1.38 in the calltokenoptional list or setting user 1002 requirecalltoken=no

Entre las opciones Device Options que no aparecieron a la hora de crear la extensión se encuentra requirecalltoken con valor Yes por defecto por lo que lo cambio a No.

Una vez habilitada nuevamente la cuenta comprobamos que se registra el terminal correctamente contra la centralita.

Llamadas de pruebas

Una vez los teléfonos están registrados correctamente contra la centralita podemos realizar llamadas de prueba entre ambas extensiones.

En posteriores entradas lo comentaré más en detalle pero es bueno que conozcamos que existen una serie de numeraciones preconfiguradas en la centralita llamadas Features Codes. Estas se encuentran dentro del menú Admin y podemos editarlas a nuestro antojo e incluso como ya veremos añadir otras nuevas.

Por ejemplo, podemos consultar la hora del sistema marcando la opción *60 desde los teléfonos

Hasta aquí la introducción a la creación de extensiones y la configuración de softphones tanto para clientes SIP como IAX2. En la siguiente entrada describiré más parámetros de configuración alguno de ellos para asegurar en la medida de lo posible nuestra instalación.

Un saludo, Brixton Cat.

AsteriskNOW: Introducción

2013-12-28T23:47:00.000+01:00

Llevo unos días poniéndome al día con Asterisk, buscando información sobre las distintas opciones que nos ofrece a la hora de configurar la centralita y dar servicio a nuestros usuarios o a los clientes que nos llamen. Entre las muchas opciones me he decantado por AsteriskNOW por varias razones, una de ellas y la principal es que está mantenida por los desarrolladores de Asterisk, hace uso de FreePBX como interfaz gráfica y utiliza versiones recientes del software.

AsterisNOW actualmente tiene a disposición la versión 3.0.0 que corre sobre un Sistema Operativo CentOS 6.5 y utiliza para la centralita Asterisk 11.6.1 y FreePBX 2.11.0.11. Además podemos hacer uso del gestor de paquetes YUM para instalar o desinstalar paquetes y mantener el sistema actualizado en todo momento.

En el siguiente enlace se detella la instalación del Sistema Operativo y como repetición a lo mencionado en el mismo, es recomendable actualizar el sistema antes de acceder a la interfaz Web y hacer uso de la centralita.

Una vez actualizado nos logueamos en la intefaz Web utilizando los credenciales por defecto, usuario admin y contraseña admin para acceder al dashboard donde ver el estado del sistema y los servicios, notificaciones y estadísticas de la centralita.

En la parte superior de la página nos encontramos con la barra de navegación que contiene diversos menús desplegables para la configuración de la centralita, administración, herramientas, etc.

Admin

Menú dedicado a tareas de administrarción como crear usuarios y modificar sus contraseñas. Con el módulo System Recordings podemos subir o realizar una grabación en una extensión y utilizarla en la configuración de nuestro sistema. Desde la opción Module Admin podremos comprobar el estado de los módulos instalados y los disponibles, además de poder configurar una dirección de e-mail para que nos informe de las nuevas actualizaciones.

Applications

Dentro de este menú encontraremos por defecto algunas opciones básicas y no tan básicas como la administración de extensiones (Extensions), el parking de llamadas (Parking) o las colas de llamadas (Queues).

Connectivity

Este menú se utiliza para configurar parámetros de conectividad como su nombre indica, podremos definir troncales para la comunicación externa de la centralita, rutas de entrada y salida, etc...

Reports

En este menú encontramos opciones de reporte como los logs de la centralita (Asterisk Log Files) o el módulo CDR (Call Data Record) para el reporte de llamadas.

Settings

Aqui podemos encontrar opciones de configuración avanzadas para el servidor, así como herramientas varias como el módulo Music on Hold para la música en espera o la administración de los buzones de voz (VoiceMail Admin).

En la siguiente entrada empezaré con la creación de extensiones para después ver funcionalidades interesantes de cualquier centralita como buzones de voz, capturas llamadas entre extensiones, IVRs, etc.

Un saludo, Brixton Cat.

Monitorización con Cacti: Probando configuraciones

2013-10-19T12:53:00.000+02:00

Continuando con la serie Monitorización con Cacti, voy a explicar los pasos básicos para añadir equipos a nuestro sistema y configurar las gráficas que nos interesen para que el servidor pueda empezar a obtener datos.

Como comentaba en la introducción de la serie, Cacti es una herramienta de monitorización síncrona basada en protocolos de networking para obtener información de los equipos clientes que estén configurados en el sistema. Se pueden realizar desde peticiones ICMP (TCP y UDP) hasta consultas SNMPs especícifas para obtener la información de un OID único para un fabricante.

Una de las pruebas más básicas que realizar es un ping a un servidor externo de Internet, en este caso he utilizado uno de los servidores DNS de Google para controlar la latencia de la conexión. Para ello desde el apartado Devices, agregamos un nuevo equipo y rellenamos el formulario con los datos del dispositivo.

- Descripción: Descripción del dispositivo
- Hostname: FQDN o IP del dispositivo
- Host Template: None*
- Downed Device Detection: Método para comprobar si el host está disponible para realizar consultas**

* Colección de gráficas que se pueden aplicar a los host en función del fabricante, pruebas a realizar o cualquier otro grupo que queramos crear para facilitar la administración de los equipos.
** Dependiendo del valor aparecerá un menu con más o menos opciones.

Para crear gráficas vamos a Create Graphs for this Host y en este caso al no haber seleccionado ningún Host Template en la configuración anterior, no aparecen gráficas por defecto que utilizar para este dispositivo. Para añadir una, elegimos a través del menu desplegable el test a realizar y lo agregamos a nuestro dispositivo.

Pongo un nombre para la leyenda y un color alegre.

Una vez creada la gráfica, desde Graph Management se puede comprobar el estado de la misma.

A través de Graph Tree he añadido el host a la vista por defecto, por lo que al ir a la pestaña Graph están los dos dispositivos para poder ver los datos.

Una de las maravillas de RRDTools, a partir de la versión 2.2.0, es que puedes hacer zoom en las gráficas para centrar el detalle donde tu quieras. Cacti por supuesto también incorpora esta funcionalidad desde la versión 0.6.4.

Ahora voy a configurar un router, OpenWrt para ser más exacto, y obtener el tráfico de red de alguna de sus interfaces utilizando SNMP tanto para conocer el estado del dispositivo como para obtener los datos de actividad de las interfaces de red.

Para ello relleno el formulario con los datos del equipo asegurándome de tener correctos los datos de la versión del protocolo y de la community autorizada.

En este caso he utilizado Generic SNMP-enabled Host como template, que utiliza el estandar SNMPv2-MIB para obtener un listado de las interfaces del dispositivo y los datos relativos a las mismas.

La mejor manera de organizar nuestras gráficas es a través de grupos en Graph Tree, diferenciando los equipos por funcionalidades, vistas de las gráficas más utilizadas... imaginación al poder. En este caso para el router OpenWrt, lo he agregado al grupo Access Points donde tengo los dispositivos Wireless a monitorizar.

Configuraciones varias

En esta parte de la entrada voy a comentar las configuraciones mínimas y algunas veces por defecto que he utilizado para algunos routers, en caso de producción yo no haría esto...

- OpenWrt

Hay que tener instalado el demonio SNMP (snmpd), para ello opkg y los repositorios nos facilitan la administración de paquetes en estos equipos. Modifico los valores del system y curioseo la configuración por defecto para la community public.

- Mikrotik

Defino una community public accesible para el rango de direcciones IPs que estoy usando y modifico los datos de contacto del dispositivo.

- Cisco

En el caso de Cisco sólo he configurado una interfaz Ethernet, una community public con permisos de lectura y los datos de contacto del dispositivo.

- Juniper

Para Juniper muy similar que para Cisco: una interfaz de red, una community con permisos de lectura para el rango de IP que estoy usando y los datos de contacto del dispositivo.

Un saludo, Brixton Cat.

Monitorización con Cacti: Instalación

2013-09-28T03:28:00.000+02:00

Bueno, pues es hora de comenzar con la instalación...

Como comentaba en la Introducción, la instalación se realizará sobre un sistema Debian Wheezy y en esta entrada no se explica la instalación del sistema operativo pero en entradas anteriores del blog se detalla la instalación de Debian NetInstall.

Los paquetes necesarios para instalar Cacti en nuestro equipo son: apache2, php5, php5-mysql, php5-gb, mysql-server, rrdtool, snmp, php5-snmp y ejecutando el comando aptitude install con dichos paquetes nos resuelve e instala las dependencias necesarias.

Una vez preparado el sistema operativo, procedemos a la instalación de Cacti con el comando aptitude install cacti.

Tras una advertencia del cambio de ruta de la libreria adodb para PHP, seleccionamos el servidor Web que vamos a utilizar, en mi caso apache2.

Realizamos la configuración de la base de datos MySQL a través del instalador y le proporcionamos la contraseña del usuario administrador de la misma.

Una vez finalizado el proceso de instalación de los paquetes, queda realizar la instalación de la aplicación Web propiamente dicha. Para ello nos diriguimos a la siguiente URL: http://IP_SERVER/cacti que nos debería redirigir al mensaje de bienvenida del instalador.

En la siguiente pantalla seleccionaremos una nueva instalación y nos muestra los credenciales por defecto para el acceso a la base de datos. En caso de querer cambiar dichos datos, editaremos el fichero que nos indica el mensaje de información, include/config.php.

La siguiente pantalla nos informa de las diferentes herramientas que Cacti necesita para funcionar correctamente. En determinados casos, es posible especificar diferentes rutas para algunos de los ejecutables.

Una vez finalizado el proceso de instalación, accedemos a la URL de la aplicación y nos logueamos con el usuario admin y cualquier contraseña porque nos obligará a modificarla una vez logueados.

En cualquier caso, llegaremos a la pantalla inicial de la aplicación donde no ha pasado el tiempo por ella y aparentemente no ha cambiado nada.

Pero si nos fijamos en el apartado Configuration de la barra de navegación del lado izquierdo, vemos alguna que otra novedad: Plugin Management.

Antiguamente había que pelearse con Cacti para instalar el PIA (Plugin Architecture) y poder disfrutar de los plugins de la comunidad. Pero a partir de la versión 0.8.8a esta característica está incluida y gracias a que dicha versión se encuentra en el repositorio estable de Debian no tenemos que pelearnos instalándolo.

De siempre Cacti viene configurado para monitorizar el host donde está alojado y en esta versión no iba a ser una excepción. En el apartado Devices podemos administrar los dispositivos.

Al igual que en Graph Management podemos administrar las gráficas creadas para nuestros hosts.

Si accedemos al apartado Settings encontramos multitud de opciones donde podemos cambiar el nivel de debug en el log de la aplicación, modificar los paths, autenticación LDAP, etc.

Muy útil e interesante es el apartado System Utilities donde encontramos los logs de la aplicación para depurar en caso de ser necesario.

Por último, si accedemos a la pestaña graphs podemos ver las gráficas que por defecto vienen configuradas con la aplicación.

Un saludo, Brixton Cat.

Monitorizacion con Cacti: Introducción

2013-09-28T01:19:00.003+02:00

Voy a empezar una nueva serie de artículos para el blog y en este caso dedicada a la monitorización haciendo uso de Cacti, una herramienta Open Source con licencia GPL v2 que utiliza las librerias RRDTools para alegrarnos la vista con esas gráficas sobre el tráfico en nuestras conexiones o el estado de nuestros servidores por poner algunos ejemplos.

Cacti es una herramienta de monitorización síncrona, es decir, que cada cierto tiempo pregunta a los clientes su estado en función de la configuración de cada uno de ellos. Otras herramientas por defecto son capaces de recibir alertas de los equipos clientes cuando estos han sufrido alguna anomalía, por lo que se dice que realizan monitorización asíncrona. Cacti utiliza algunos protocolos de red como ICMP o SNMP para obtener datos o simplemente reconocer a los clientes a monitorizar.

SNMP (Simple Network Management Protocol) es un protocolo muy utilizado en Cacti y está diseñado precisamente para lo que su nombre indica: un protocolo básico de administración de red. Tan simple, tan simple, que hasta no hace mucho ha salido la tercera versión del protocolo que añade más capas de seguridad al estandar.

Pero lejos de los peligros de la seguridad, SNMP es uno de los protocolos más prácticos para administrar equipos en red. Podemos realizar consultas sobre un determinado objeto (OID), realizar cambios en la configuración o indicar a los clientes que envien alertas a un servidor remoto en este caso llamado colectora. SNMP es un protocolo muy extenso y esta entrada "trata de ser" una breve introducción a Cacti como herramienta de monitorización por lo que no quisiera explayarme.

En las siguientes entradas realizaré la configuración de Debian Wheezy junto las dependencias necesarias para instalar un servidor Cacti con el que realizar algunas pruebas, comentar las novedades de la nueva version, configurar algunos equipos, plugins interesantes, algunos scripts...

Un saludo, Brixton Cat.

No estaba muerto...

2013-07-26T02:11:00.000+02:00

Buenas noches mis queridos seguidores y desconocidos que encontreis estas líneas con la alevosía de vuestro buscador de Internet favorito. Hoy que tengo la noche inspirada me he decidido a escribir algo. Pero no nada técnico porque a estas horas no apetece demasiado que el despertador mañana no perdona y los paquetes no se instalan solos...

En primer lugar pedir perdon a las dos personas [que triste :'( ] que han comentado en los últimos meses y que hasta hoy no he publicado el comentario. Sorry, pero últimamente ando más perdido que la 10-11 en un taller mecánico.

Hace tiempo que ando con ganas de escribir algo pero no saco tiempo ni debajo de las piedras y dormir menos está contraindicado... Algunas de las cosas que me guardo en el tintero y con suerte un día de estos me pondré a escribir:

-- Cacti: Quería hacer una pequeña serie de entradas explicando la instalación, configuración de nuevos equipos, creación de scripts y gráficas, plugins interesantes...

-- Nagios: Nada del otro mundo, trucos y configuraciones que nos ayuden a la hora de crear nuestros equipos a monitorizar.

-- PandoraFMS: Idem que Cacti.. Quería hacer una pequeña serie con la instalación, configuración del servidor y los agentes, configuración de test, nodos satelites, etc...

-- Munin: Este es nuevo para mí... Sencillo, con una interfaz gráfica limpia y sin algunas funciones básicas como el retroceso en algunas pantallas (FAIL!). La creación de scripts y gráficas parece de los más sencillo, digo "parece" porque no he conseguido que grafique nada aún ejecutándose correctamente los scripts.

-- Mikrotic: Me falta ponerme a escribir unas cuantas líneas de como configurar un router de este fabricante utilizando máquinas virtuales para ello. Además de algún ejemplo de configuración de un router doméstico con un puerto WAN y un bridge en el resto de bocas LAN.

-- OpenWRT: Buff... Daría para un blog completo todo lo que hay escrito y se puede hacer con este software... Alguna entrada virtualizando el software y algunas configuraciones me gustaría escribir...

A estas horas y que yo recuerde, seguro me quedará algo en el tintero que se me haya escapado; pero como entrada para el blog puede valer y si no me acuerdo seguro que era mentira. Ah! y recordad:

Tus videos de Internet

2013-04-09T21:19:00.001+02:00

"Chupópteros lobbies del copyright" Así tenía pensado titular la entrada, al estilo de una famosa frase de Homer Simpson... pero al final me decidí por algo menos conflictivo y encarrilar el tema con un estilo más civilizado.

De todas maneras la entrada trata sobre el mismo tema, los archivos multimedia de nuestras páginas web favoritas. Esto es igualmente aplicable a documentos, fotografías o cualquier archivo que está público en Internet.

Cuando hablo con mis amigos sobre los orígenes de Internet y las páginas web, se extrañan que todo sea tan simple y transparente. Por eso mismo señores lobbies del copyright, tengo una cosa que decirles: Internet se diseño para ser libre y siempre seguirá así. Por no decir que Internet no es mas que una de las grandes redes públicas que existen.

Todo esto viene por una conocida serie que recientemente ha sido estrenada en televisión y que más de uno seguro que la conoceis... En la página web del programa se pueden ver los distintos capítulos y como no tenía nada mejor que hacer, pues me puse a mirar el código.

Hay que decir que la nueva versión del estandar web, HTML5, nos facilita bastante la tarea de encontrar los archivos multimedia que buscamos y si visitamos la página en un Windows, SilverLight también nos puede ayudar a localizar el video en cuestión.

En esta entrada no me quería limitar a las comodidades anteriormente citadas, sino que quería hacer un pequeño resumen de mis experiencias localizando vídeos y los distintos tipos de publicación que he encontrado. He de decir que no se detallan los pasos y tampoco incito a los lectores a descargar contenido con derechos de autor, solo me limito a comentar mis aventuras y desventuras.

Originalmente, los videos pudieron ser reproducidos en los navegadores gracias al archiconocido plugin Flash de la empresa Adobe System y para su reproducción se inserta un archivo SWF con el video a reproducir.

Se utilizan variables para definir más opciones como el tamaño, inicio automático, colores, etc. permitiendo la descarga del archivo.

Posteriormente y actualmente como veremos un poco más adelante, dichos ficheros se utilizan como reproductores de otros ficheros que son realmente el video pero igualmente son fáciles de localizar y descargar.

Lo más utilizado actualmente y sobre todo hablando de cadenas de televisión, son conexiones streaming y la gran mayoría que he visto han sido bajo el protocolo propietario RTMP de, nuevamente, Adobe System. Esto no es solo aplicable a páginas web, si abrimos un archivo ASX podemos ver que se tratan de conexiones streaming ya sea utilizando el protocolo propietario de Microsoft, MMS, o el estandar RTSP desarrollado por el IETF. Esta captura pertenece a un archivo de una conocida empresa de soluciones virtualizadas.

Podemos ver/descargar dichos archivos con reproductores como VLC, Amarok, Kaffeine y muchos otros más.

Es fácil encontrar conexiones streaming pero utilizando el protocolo RTMP comentado anteriormente y deberemos utilizar otras herramientas como Rtmpdump del que hablaré posteriormente.

En ocasiones se utilizan archivos XML donde se especifican los datos del archivo o archivos que componen el video y el servidor donde se encuentran ubicados.

Como comentaba anteriormente, con rtmpdump y sus herramientas hermanas podemos guardar el contenido de un streaming desde la línea de comandos. Para Debian tenemos la suerte que el paquete se encuentra en los repositorios oficiales.

Pero no todo es oro lo que reluce, hay veces en las que aun encontrando la dirección del video

No tenemos permiso para descargarlo.

Incluso aunque localizemos los datos correctos en el código y se reproduzca el video.

Si intentamos descargarlo, lo que obtenemos es simplemente el archivo SWF que reproduce el video.

En esta entrada he querido reflejar la facilidad con la que observando y rebuscando en el código fuente de una página podemos obtener mucha información e inclusive los contenidos ofredidos por la misma. Todo esto utilizando mayoritariamente un navegador web y las herramientas con las que estos cuentan.

Tal vez utilizando otras herramientas mas intrusivas tenga acceso al resto de videos que no he podido descargar. Eso puede ser tema para una siguiente entrada asi que quién sabe.

Un saludo, Brixton Cat.

Documentación certificación LPI 101 (developerWorks)

2013-01-19T19:51:00.000+01:00

Como proposito para este año, he decidido currar un poco y sacarme algunas certificaciones, entre ellas el LPI1. Por ello esta entrada está dedicada a toda la documentación desarrollada por developerWork (IBM) para superar el exámen 101 de dicha certificación.

El exámen consta de varios apartados cada uno asociado con un peso del 1 al 10 que le dá prioridad, podemos consultar los objetivos del mismo en la página del LPI. A continuación están listados todos los archivos PDFs para su descarga.

Topic 101

101.1 - Hardware and architecture
101.2 - Boot the system
101.3 - Runlevels, shutdown and reboot

Topic 102

102.1 - Hard disk layout
102.2 - Boot managers
102.3 - Manage shared libraries
102.4 - Debian package management
102.5 - RPM and YUM package management

Topic 103

103.1 - The Linux command line
103.2 - Text streams and filters
103.3 - File and directory management
103.4 - Streams, pipes, and redirects
103.5 - Create, monitor, and kill processes
103.6 - Process execution priorities
103.7 - Search text files using regular expressions
103.8 - File editing with vi

Topic 104

104.1 - Create partitions and filesystems
104.2 - Maintain the integrity of filesystems
104.3 - Control mounting and unmounting of filesystems
104.4 - Manage disk quotas
104.5 - Manage file permissions and ownership
104.6 - Create and change hard and symbolic links
104.7 - Find and place system files

Topic 110

110.1 - The X Window System

A parte de toda esta documentación, en la página del LPI podemos encontrar más información como libros y manuales o webs donde simular un exámen. También podemos prácticar haciendo exámenes como por ejemplo los que encontremos en Exam Collection o buscando información por Internet.

Un saludo, Brixton Cat

Python Script: QosCalc.py

2013-01-19T17:03:00.001+01:00

Feliz año, merry christmas y esas cosas que se dicen... Ya se que es un poco tarde pero es mi primera entrada del año y tenía que decirlo en algún momento. Tengo varias entradas entre manos y algunas de ellas dedicadas a scripts Python que estoy realizando.

En esta entrada voy a mostrar la actualización que he realizado del script TosCalc.py, descrito en esta entrada. En primer lugar le he cambiado el nombre porque el anterior no me convencía, he utilizado la variable self para almacenar todos los valores que se van calculando y un pequeño control de excepciones que controla los errores el script.

El script acepta solamente un argumento y éste debe ser un número entero (de tipo int), en caso de no pasar un número fallará salvo algunas excepciones siempre y cuando los valores estén comprendidos entre el 1 y el 7.

Sintaxis: ./QosCalc.py value

Código fuente:

#!/usr/bin/env python
#
# Name: QoSCalc.py
# Description: Calculate any QoS values through a IP Precedence or Class Selector
# Author: Brixton Cat
# Date: 19 Ene 2013
# Version: 1.0
# Sintax: ./QoSCalc.py value
#
 
### Dependencies
import sys
 
### tosCalc class
class qosCalc:
  """ Class to calc any QoS values through a IP Precedence or
      Class Selector """
  
  def __init__(self, value):
    """ Initializing qosCalc class """
    self.value = value                            # Creating value variable
    
    # Check value introduced
    if value < 1 or value > 7:
      print "[!] Error: Allow values it's from 1 to 7"
      sys.exit(3)                                 # Exit code: 3

  def eightBits(self):
    """ This function add 0s to right side of binary variable and calc their
        decimal value """

    self.tosb = self.dscpb + str(0) * 2           # Type of Service binary value
    self.tosd = int(self.tosb, 2)                 # Type of Service decimal value

  def main(self):
    """ Main function """
    
    calc.threeBits()
    calc.sixBits()
    calc.eightBits()

  def results(self):
    """ Prints values of the IP Precedence or Class Selectors argument """
  
    # Header of table
    print "Value  3bits   DSCP Bin  DSCP   ToS Bin   ToS"
    print "-----  -----   --------  ----   -------   ---"
    # Values
    print "  %d\t%s\t%s\t  %d\t%s  %d" % \
      (self.value, self.binary, self.dscpb, self.dscpd, self.tosb, self.tosd)

    return sys.exit(0)

  def sixBits(self):
    """ This function add 0s to right side of binary variable and calculate
        their decimal value """
  
      self.dscpb = self.binary + str(0) * 3       # DSCP binary value
      self.dscpd = int(self.dscpb, 2)             # DSCP decimal value

  def threeBits(self):
    """ This function convert decimal argument to 3 bits value and check
        correct lenght of this """

    # If less of 3 bits, add 0s to left of binary variable
    bina = bin(self.value).split('b')             # Array ['0', 'value']
    if bina[1] < "3":
        rest = 3 - len(bina[1])
        self.binary = str(0) * rest + bina[1]
    else:
        self.binary = bina[1]

### Script
if __name__ == "__main__":
  try:
    value = int(sys.argv[1])                      # Check first argument
    
    calc = qosCalc(value)                         # Initializing qosCalc class
    calc.main()                                   # Run main() function
    calc.results()                                # Prints results
    
  except IndexError:                              # Error: No argument
    print "[!] Error: Any value defined"
    sys.exit(1)                                   # Exit code: 1
    
  except ValueError:                              # Error: Bad arguments
    print "[!] Error: Not valid Class Selector or IP Precedence value"
    sys.exit(2)                                   # Exit code: 2

#EOF
##FVE

Un saludo, Brixton Cat

Citrix icaclient en Debian Squeeze 32 y 64 bits

2012-11-26T22:24:00.002+01:00

Recientemente he tenido que conectarme a algunas aplicaciones virtualizadas en Citrix y en esta entrada quiero explicar los pasos que he seguido para instalar el cliente de dicho fabricante bajo Debian Squeeze.

Lo primero que hay que hacer buscar información, en mi caso llegué al siguiente enlace con información importante que utilizaremos posteriormente.

Deberemos descargarnos el paquete Citrix ICAClient para nuestra plataforma desde la página del fabricante. En este primer apartado instalaré dicho cliente para un sistema x86 y posteriormente comentaré las diferencias en un sistema de 64 bits.

Cliente 32 bits

Como informa la página del fabricante, se necesita la libreria libmotif4 para hacer funcionar la aplicación. Tras ello, instalamos manualmente el paquete descargado anteriormente.

A la hora de arrancar nuestras aplicaciones virtualizadas recibo un fallo indicando que no confiamos en el certificado SSL de nuestra conexión. Aquí es donde entra en juego la información encontrada en primer lugar.

Deberemos renombrar el directorio keystore donde se almacenan los CA para autorizar los que están almacenados en la ruta /usr/share/ca-certificates/mozilla.

Tras ello se establece la conexión

Y arranca correctamente la aplicación solicitada.

Cliente 64 bits

Para equipos de 64 bits es necesario tener el paquete nspluginwrapper instalado.

Como se puede apreciar en la captura, el paquete icaclient se instala pero falla durante el proceso de configuración.

Al igual que anteriormente, deberemos renombrar el directorio donde se almacenan los certificados autoizados y crear un enlace simbólico al directorio donde Mozilla los guarda: ln -s /usr/share/ca-certificates/mozilla /opt/Citrix/ICAClient/keystore/cacerts.

Bajo Firefox es posible que no reconozca la aplicación y tengamos que especificar la ruta de la misma, /opt/Citrix/ICAClient/wfica.

Tras ello arranca la aplicación correctamente.

La versión de 32 bits fue instalada en una máquina virtual para poder explicar el proceso, mientas que la versión de 64 bits corre bajo mi ordenador personal.

Espero que os sirva de ayuda. Un saludo, Brixton Cat.

Fallo al crear el objeto COM de VirtualBox [Fix]

2012-11-15T21:17:00.001+01:00

Como dice el título, se trata de un error de VirtualBox que me ha ocurrido tras unos problemillas de espacio en el ordenador. Como muestra la Location, se trata de un fallo en un archivo XML situado en el directorio de usuario que crea la aplicación, (~/.VirtualBox/VirtualBox.xml)

Como es normal, me fui al directorio para echar un vistazo y se encuentra el archivo en cuestión, VirtualBox.xml, y otro curiosamente llamado VirtualBox-prev.

Como cabe esperar, es un archivo backup previo al error. Si abrimos el documento, podemos ver que se trata de un fichero de configuración con las opciones gráficas, de red, las máquinas virtuales instaladas, discos duros, etc.

Hacemos una copia del mismo y la aplicación arranca correctamente.

Pero, ¿Qué ha pasado aquí? ¿Qué es ese archivo realmente? Habrá que tirar de nuestro querido Internet y la información que el fabricante nos brinda.

[...]

Most importantly, in this directory, VirtualBox stores its global settings file, another XML file called VirtualBox.xml. This includes global configuration options and the list of registered virtual machines with pointers to their XML settings files. (Neither the location of this file nor its directory has changed with VirtualBox 4.0.)

[...]

Básicamente lo comentado anteriormente, dicho archivo almacena la configuración global y una lista de las máquinas virtuales y sus opciones. Dicho error ha sido producido utilizando la versión 3.2.10_OSE de VirtualBox.

Un saludo, Brixton Cat.

OpenVAS bajo BackTrack 5 R3

2012-10-30T15:02:00.001+01:00

En esta entrada no me gustaría ser pesado, pero como la entrada dedicada a la Configuración de OpenVAS y Greenbone Security tiene mucho éxito y hay muchos comentarios preguntando sobre cómo registrarse en el sistema, he decidido volver a configurarlo bajo la nueva versión de BackTrack.

Voy a seguir los mismos pasos que en la entrada citada anteriormente, por lo que no me entretendré demasiado en los comandos. Inicialmente crearemos un usuario para la aplicación a través del comando openvas-adduser

Crearemos el certificado con el comando openvas-mkcert

Y actualizamos los NVTs para disponer de todas las actualizaciones con el comando openvas-nvt-sync

Tras actualizar los test, cargamos los plugins de OpenVAS Scanner con el comando openvassd y recordad que este proceso tarda bastante tiempo.

Crearemos el certificado para el cliente con el comando openvas-mkcert-client -n om -i

Reconstruimos la base de datos de OpenVAS Management con el comando openvasmd --rebuild, esto es necesario tras la actualización de los NVTs realizado anteriormente.

Creamos un usuario con privilegios para el administrador, OpenVAS Administrator, con el comando openvasad -c 'add_user' -n 'NombreUsuario' -r Admin. Dicho usuario debe ser distinto del primer usuario que creamos con el comando openvas-adduser.

Arrancamos el demonio para el gestor y el administrador de OpenVAS con los siguientes comandos:

Y el demonio Greenbone Security Assistant para poder conectarnos a través de la interfaz web o del Greenbone Security Desktop.

Por último compruebo que tengo acceso a través de las distintas interfaces gráficas.

Un saludo, Brixton Cat.

CheckPoint R75 sobre VirtualBox: Interfaces de usuario

2012-10-24T19:10:00.001+02:00

Con esta entrada termino la pequeña serie CheckPoint sobre VirtualBox y como muestra el título, trata de las distintas interfaces de usuario que tenemos a nuestra disposición. Éstas son en modo texto: ya sea en local y a través de SSH, a través de la interfaz web si la hemos habilitado durante la instalación y utilizando la suite SmartConsole del fabricante.

Interfaz en modo texto

Podemos utilizar la conexión local a la máquina virtual y ver los comandos disponibles.

Hay algunos comandos típicos de un sistema Linux.

Y otros propios del fabricante.

Además podemos estableces conexiones remotas a través de SSH.

Interfaz web

Tras logearnos nos muestra la página de inicio, en la que podemos ver datos del software así como algunos datos de las interfaces del equipo.

Podemos ver en detalle y modificar la configuración de red.

Nombre de dominio, procesos, usuarios administradores, etc.

Y descargarnos la suite SmartConsole que utilizaremos posteriormente.

Suite SmartConsole

Tras instalar el software, podemos ver que no se trata de una sola aplicación sino de un conjunto de herramientas que se complementan.

A través del SmartDashboard tenemos multitud de herramientas para la configuración de los distintos servicios que podemos instalar. Podremos editar la configuración del dispositivo.

Y activar algunos servicios del mismo.

Ver la topología de red, reglas NAT, etc.

O ver el estado del equipo a través de SmartView Monitor.

Información del estado del sistema o de la red.

He probado ligeramente otras herramientas pero al no tener servicios activados no he conseguido sacar mucho en claro. Estas entradas están dedicadas a un primer contacto con estos equipos y su instalación. Posteriormente intentaré realizar alguna instalación manual y alguna configuración de pruebas.

Un saludo, Brixton Cat.

CheckPoint R75 sobre VirtualBox: Configuración inicial

2012-10-14T02:33:00.000+02:00

Una vez hemos instalado nuestra máquina vitual, pasamos a realizar la configuración inicial del dispositivo. Esta configuración consiste en poner el equipo en hora, configurar interfaces y tablas de rutas, nombre del dispositivo, DNS, etc.

Ésto lo podremos realizar a través de la consola de la máquina virtual con el comando sysconfig o a través de la interfaz web una vez nos logeamos en el sistema. En mi caso lo realizaré a través de la interfaz gráfica dado que la consola me falló en los últimos pasos de la configuración.

Tras aceptar los términos de licencia, podremos configurar el resto de interfaces del dispositivo.

Podemos ver la tabla de rutas y modificarla.

Dale un nombre de dominio y una interfaz de administración.

Ponerlo en hora y definir qué clientes que podrán conectarse a la interfaz web o vía SSH. La palabra clave any permite la conexión de cualquier equipo.

En el siguiente paso vamos a definir los paquetes a instalar en nuestro dispositivo.

Definiremos nuestro equipo como el principal, secundario o como un servidor de logs.

Como hemos instalado el SmartEvent y el SmartReporter Suite, nos presenta la pantalla de configuración del servidor.

Los equipos que tendrán acceso a la interfaz gráfica para la administración.

Y el nombre de usuario administrador.

Tras la confirmar los pasos de la configuración, se procede a su ejecución y al finalizar nos presentará un aviso confirmando el proceso.

Después de reiniciarse el equipo, nos podremos conectar a través de las diferentes interfaces de usuario. Éstas serán descritas en la siguiente entrada dedicada al acceso en modo texto, la interfaz web y el programa SmartDashboard que nos descargaremos del propio dispositivo.

Un saludo, Brixton Cat.

CheckPoint R75 sobre VirtualBox: Instalación

2012-10-12T19:29:00.001+02:00

Después de estar investigando la instalación de diversas versiones de Olive, voy a escribir unas entradas sobre la instalación, configuración y diversas interfaces de usuario del software R75.40 del fabricante Check Point. Hace tiempo que tenía ganas de instalarlo sobre todo porque nos puede servir para practicar de cara a una posible certificación de dicho fabricante.

En esta primera entrada voy a describir la instalación del software sobre una máquina virtual por lo que inicialmente crearé una nueva.

Al arrancarla deberemos pulsar Enter para que comience la instalación.

Y nos presenta una pantalla de bienvenida donde podemos ver la lista de dispositivos, añadir drivers, cancelar o continuar la instalación.

Tras elegir el idioma deberemos seleccionar una interfaz para configurarla en un primer lugar.

Podemos deshabilitar el servicio HTTPS o cambiar el puerto por el que va a escuchar las peticiones.

Tras confirmar el proceso de instalación, se formatea el disco duro y comienza la instalación.

Después las configuraciones post instalación.

Y tras la instalación del cargador de arranque nos presenta una pantalla de confirmación informando que la instalación ha finalizado correctamente.

Para completar la instalación el equipo va a ser reiniciado y tras el reinicio nos podremos conectar a la interfaz web con las credenciales por defecto. Una vez arranca el equipo, nos logeamos a través de la consola y nos pide cambiar la contraseña del usuario administrador.

Y tras ello, cambiar el nombre para no dejar el nombre del usuario administrador por defecto.

En la siguiente entrada realizaré la configuración inicial del dispositivo a través de la interfaz web dado que a través de la consola me falló en los últimos pasos de la configuración.

Estas entradas están basadas en los tutoriales de la gran página Sysadmin Tutorials, posteriormente me gustaría realizar algunas configuraciones pero eso es harina de otro costal.

Un saludo, Brixton Cat.

Juniper y Olive: Una historia de amor y odio

2012-10-04T20:41:00.000+02:00

En esta entrada voy a comentar brevemente el procedimiento para la instalación del software JunOS en un sistema FreeBSD usando Qemu como motor de virtualización, además de algunas anécdotas y curiosidades de dicha instalación.

Por empezar por algún sitio pongámonos en situación explicando quién es el protagonista de esta entrada. Olive es una instalación modificada del software desarrollado por la compañía Juniper Networks dedicada ésta al mundo de las telecomunicaciones. Fundada tan solo en 1996, en pocos años han sabido desarrollar software de calidad haciendo ferrea competencia a la gran Cisco Systems.

En realidad, el software realizado por dicha compañía se trata de una serie de shell scripts empaquetados y comprimidos con tar y gzip (.tgz) e instalados con la aplicación pkg_add en un sistema FreeBSD. En realidad dicha aplicación necesita una serie de ficheros como un comentario, archivos de contenido, instalación/desinstalación del paquete, etc.

Olive existe porque Juniper lo permite, aunque su postura oficial es que no existe y es una plataforma no soportada ni soportable que hace uso de software ilegal. Es fácil encontrar hilos del foro oficial de la compañía en los que se informa que dicha plataforma no está soportada e incumple las condiciones de licencia de su software. Recuerda usar esta información con responsabilidad:

Please do not abuse this feature by doing stupid things like contacting JTAC for support on an Olive, or selling illegal copies of the software as "router simulators". This type of activity is likely to have serious legal consequences and/or provoke a justified response from Juniper, so just don't do it.

¿Cómo comenzó todo esto? Un buen día algún hacker descubrió la manera de instalarlo y la compartió con el resto de la comunidad. Posteriormente se añadió un binario que comprueba la existencia de los módulos de red que Juniper utiliza en sus equipos, checkpic.

¿Y cómo se realiza la instalación?. Incialmente descomprimimos el fichero firmado (signed) y sin firmar

Y por último el paquete pkgtools.tgz dónde dentro del directorio bin/ encontramos el fichero checkpic citado anteriormente. Éste será reemplazado por /usr/bin/true que siempre devolverá 0.

Comprimiremos primero el contenido de la carpeta pkgtools/ así como el contenido del fichero sin firmar que descomprimimos anteriormente. El fichero que creemos será el que utilizaremos para instalar Olive.

Una vez copiados los archivos debemos reiniciar el sistema para que la instalación se complete borrándose los ficheros de arranque normales del sistema, por lo que si no dejamos que se complete no podremos volver a arrancar el equipo. Otra de las características del proceso de instalación es que necesitamos una conexión serial para completarla por lo que apagaremos la máquina virtual antes de pasar al siguiente paso (halt).

Si reiniciamos el equipo sin contar con una conexión serial, desde la ventana de Qemu no veremos nada. Por lo que añadiremos algunas opciones al comando para crearlas, por ejemplo conexiones telnet o la salida estándar de la consola (stdio).

Tras la instalación del software se reiniciará automáticamente el equipo completándose el proceso.

Nos logeamos con el usuario root sin contraseña para acceder al sistema y con cli para comprobar el software que tenemos instalado.

Luego añadieron al instalador una nueva función llamada platform_check con la que comprobar el RE (Routing Engine) del dispositivo a través de consultas sysctl. Modificando la variable re_model y gracias a la ayuda de Juniper podemos realizar la instalación.

Igualmente, deberemos sustituir el binario checkpic y comprimir el contenido del paquete sin firmar que descomprimimos para crear el instalador de Olive.

Tras el reinicio correspondiente podemos logearnos correctamente en el sistema y comprobar la versión que tenemos instalada.

Igualmente funciona para versiones más recientes como la 9 o la 12

En este punto hay que decir que en las nuevas versiones de JunOS, durante el proceso de instalación monta el directorio /tmp en la memoria RAM por lo que debemos aumentar la memoria de la máquina virtual hasta 1024M. En caso contrario la instalación quedará colgada y no finalizará.

No se el por qué pero durante el arranque del sistema recibo un error panic que no he conseguido solucionar. Igualmente me pasa al utilizar algunas versiones ya creadas de Olive descargadas de Internet.

Comentar que he intentado solucionar el error desactivando el software watchdog pero no ha funcionado. Además la información que he encontrado en el foro de GNS3 tampoco me ha sido de mucha ayuda.

Enlaces:

http://en.wikipedia.org/wiki/Juniper_Networks
http://juniper.cluepon.net/index.php/Olive
http://blog.gns3.net/2009/10/olive-juniper/
http://brezular.wordpress.com/2012/07/03/installing-olive-12-1r1-9-under-qemu/

Un saludo, Brixton Cat.

[BSOD] Stop 0x000000ED (Unmountable_Boot_Volume)

2012-09-12T19:43:00.002+02:00

Me ha tocado solucionar el problema escrito en el enunciado y fuera de las soluciones estándar que el gigante Google nos ofrece, me gustaría comentar mi experiencia con este error y la curiosa manera de solucionarlo.

Fuente: http://kamalsalem.wordpress.com/2010/04/08/unmountable_boot_device/

Entrando en detalles, el error Stop 0x000000ED se produce debido a cómo Windows escribe los datos en disco duro utilizando almacenamiento cache para aumentar la velocidad. Como podemos leer en la página de Microsoft:

"Debido a la optimización del modelo de escritura de las unidades de disco IDE, las rutinas de almacenamiento en caché a veces escriben los datos desordenados para mantener las velocidades de escritura lo más rápidas posible en función de dónde se encuentren los datos en el disco. Esto abre un lapso de tiempo en el que las tablas cruciales del sistema de discos NTFS podrían dañarse si una operación de escritura no se completara.[...]"

Tal y como comentan en la misma página del fabricante al igual que en otros blogs y otras páginas Web, como por ejemplo la siguiente página de soporte de HP. Se soluciona tras ejecutar el comando chkdsk con la opción /r para comprobar la integridad de los sectores dañados del disco duro e intentar solucionarlos:

"Locates bad sectors and recovers readable information. Implies /p."

Pero qué podemos hacer cuando el instalador de Windows no nos reconoce la partición y no tenemos acceso a la consola de recuperación. En mi caso he probado con varios Service Packs y cambiando las opciones de compatibilidad SATA en la BIOS pero con el mismo resultado.

Fuente: http://www.linux-noob.com/forums/index.php?/topic/3986-install-xp-from-fedora/

Cuando me dispuse a copiar la información del usuario en cuestión para asegurar no perderlos y tras intentos varios de copiar la información sin comprimir, comprimida, en un disco duro, en otro... Al final acabé montando el disco duro en mi portatil con Debian Squeeze instalado utilizando el paquete ntfs-3g incluido en los repositorios. Como superusuario, es decir root, escribimos:

mount [-t ntfs-3g] /dev/sdX /ruta/final

A mi me ha tocado montar, desmontar y volver a montar la unidad y ha cambiado el nombre de /dev/sdb1 a /dev/sdc1. Podéis verlo en la siguiente captura obtenida del archivo /var/log/syslog:

"Sep 12 14:50:45 Brixton ntfs-3g[2583]: Mounted /dev/sdb1 (Read-Write, label "", NTFS 3.1)
[...]
Sep 12 14:51:25 Brixton ntfs-3g[2583]: ntfs_attr_pread_i: ntfs_pread failed: Error de entrada/salida
Sep 12 14:51:25 Brixton ntfs-3g[2583]: Failed to read index block: Error de entrada/salida
[..]
Sep 12 14:52:09 Brixton ntfs-3g[2583]: ntfs_attr_pread_i: ntfs_pread failed: Error de entrada/salida
Sep 12 14:52:09 Brixton ntfs-3g[2583]: Failed to read index block: Error de entrada/salida
Sep 12 14:52:21 Brixton ntfs-3g[2583]: Unmounting /dev/sdb1 ()
Sep 12 14:52:54 Brixton ntfs-3g[2916]: Version 2010.3.6 integrated FUSE 27
Sep 12 14:52:54 Brixton ntfs-3g[2916]: Mounted /dev/sdc1 (Read-Write, label "", NTFS 3.1)
[...]
Sep 12 16:17:42 Brixton ntfs-3g[2916]: Unmounting /dev/sdc1 ()"

Cuando he montado los anteriores volúmenes, me apareció un mensaje informando que se solucionaban algunos problemas con el arranque del dispositivo ([...] fix boot [...]). No he capturado el mensaje porque no creía que tendría relación pero si ha alguien le aparece que me mande una captura.

Otra cosa de la que no he encontrado información es porqué se ha solucionado. He visto algo de información sobre ntfsfix para solucionar algunos problemas pero nada relacionado al montar unidades NTFS.

Al final, tras varias horas de comprimir la información útil del disco duro y volver a arrancar el portátil con el disco original se ejecuta un chkdsk automáticamente:

Fuente: http://www.techiwarehouse.com/engine/ce9db812/Disable-Automatic-CHKDSK-Option

Y tras el reinicio que le acompaña se recupera la estructura del disco duro y el normal funcionamiento del sistema operativo. Comentarios jocosos se me ocurren varios pero una solución lógica y documentada? Si alguien la tiene...

Un saludo, Brixton Cat.

Ejercicio MPLS: Cliente Rojo

2012-07-31T20:24:00.000+02:00

Continuando con la serie Ejercicio MPLS, vamos a comenzar la configuración de equipos clientes tanto en los routers frontera (PEs) como en los dispositivos finales (CEs). Como siempre, en primer lugar mostrar el escenario final con el que vamos a trabajar:

En la siguiente tabla observamos el direccionamiento que configuraremos en los diferentes equipos:

Como he añadido un switch al escenario, he intentado utilizar rangos de 256 direcciones simulando una configuración VPLS pero lógicamente no funcionaba. Al final me he decidido a utilizar rangos de 4 direcciones como en el resto de enlaces.

Utilizaremos routing RIP y BGP para la conexión entre los routers frontera y los diferentes clientes. Podéis repartirlo como queráis, yo he configurado: uno si, otro no...

Routers PE

Interfaces

En primer lugar vamos a configurar un enlace Ethernet asociado a una VLAN específica dentro de la red MPLS. En este caso, se trata de la configuración para el equipos Rojo0 en el PE CC.CO:

interface FastEthernet0/1
no ip address
duplex full
speed 100
!
interface FastEthernet0/1.110
description INT Rojo0
encapsulation dot1Q 110
ip vrf forwarding ROJO
ip address 10.10.0.1 255.255.255.252
!

También vamos a utilizar enlaces Frame Relay, en esta ocasión corresponde a la configuración para el router Rojo3 en el PE BA.AD:

interface Serial1/0
no ip address
encapsulation frame-relay IETF
no fair-queue
serial restart-delay 0
clock rate 5600
!
interface Serial1/0.100 point-to-point
description INT Rojo3
ip vrf forwarding ROJO
ip address 10.30.0.1 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 100
!

Hacer mención a la configuración realizada en el switch BA.SW, dado que crearé VLANs y serán asociadas a distintos puertos del mismo.

vlan database
vlan 100 name ROJO state active
exit
!
interface Vlan100
description VLAN ROJO
ip vrf forwarding ROJO
ip address 10.10.0.5 255.255.255.252
!
interface FastEthernet1/0
description INT Rojo1
switchport trunk allowed vlan 1,100,1002-1005
switchport mode trunk
ip vrf forwarding ROJO
duplex full
speed 100
!

Routing

Utilizaremos el equipo Rojo0 para mostrar la configuración del protocolo RIP que realizaremos en el PE CC.CO:

router rip
version 2
passive-interface default
no passive-interface FastEthernet0/1.110
no auto-summary
!
address-family ipv4 vrf ROJO
  redistribute bgp 300
  network 10.0.0.0
  network 172.16.0.0
  no auto-summary
  version 2
exit-address-family

En el caso de routing BGP, marco la configuración añadida en el PE ME.PR para el router Rojo2:

router bgp 300

address-family ipv4 vrf ROJO

redistribute connected

neighbor 10.30.0.6 remote-as 500

neighbor 10.30.0.6 activate

no synchronization

exit-address-family

Equipos intermedios

En este caso, con equipos intermedios me refiero a los switches Frame Relay y ATM que conectan los routers frontera a los dispositivos finales. En este caso solamente tenemos conexiones Frame Relay y en las siguientes capturas se muestra la configuración de los puertos y sus correspondientes DLCIs (Data Link Connection Identifier). En la tabla con el direccionamiento de los equipos se especifican los identificadores que he utilizado.

BA.FR

ME.FR

Routers CE

Interfaces

En el caso de las interfaces Ethernet que están asociadas a una VLAN, utilizaremos la siguiente configuración. En este caso, se trata de la configuración realizada en el CE Rojo1:

interface Loopback0
description INT GEST
ip address 10.40.0.2 255.255.255.255
!
interface FastEthernet0/0
no ip address
speed 100
full-duplex
!
interface FastEthernet0/0.100
description INT BA.SW
encapsulation dot1Q 100
ip address 10.10.0.6 255.255.255.252
!
interface FastEthernet0/1
description INT LAN
ip address 172.16.0.1 255.255.255.128
speed 100
full-duplex
!

Para el caso de conexiones Frame Relay, utilizaremos la siguiente configuración extraída del router Rojo3. Obviaré la configuración de la interfaz de gestión para no repetir:

interface Serial1/0
no ip address
encapsulation frame-relay IETF
serial restart-delay 0
clock rate 5600
!
interface Serial1/0.110 point-to-point
description INT BA.AD
ip address 10.30.0.2 255.255.255.252
frame-relay interface-dlci 110
!

Routing

Creamos un filtro de direcciones, prefix-list, llamado REDES con los rangos que se configuren en dichos equipos y los exportaremos a través del protocolo de enrutamiento que corresponda.

En el caso de routing RIP en los clientes, muestro la configuración aplicada al equipo Rojo3:

ip prefix-list REDES seq 5 permit 10.30.0.0/30

ip prefix-list REDES seq 10 permit 10.40.0.4/32

ip prefix-list REDES seq 15 permit 172.17.0.0/24

router rip
version 2
passive-interface default
no passive-interface Serial1/0.110
network 10.0.0.0
network 172.17.0.0
distribute-list prefix REDES out
no auto-summary
!

Para el caso de BGP, igualmente deberemos crear el filtro REDES con los rangos del equipo pero para no repetir será obviado. Muestro la configuración del router Rojo2:

router bgp 500
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 10.30.0.5 remote-as 300
distribute-list prefix REDES out
no auto-summary
!

Problemas

A la hora de encender el switch Ethernet BA.SW, las VLANs aparecen desactivadas siendo necesario levantarlas con los comandos:

vlan database
!
vlan 100 name ROJO state active
vlan 200 name VERDE state active
!

Otro de los grandes problemas que he tenido a la hora de realizar el ejercicio es el consumo de CPU que necesita. En estas imágenes podéis ver de lo que hablo, este es el estado de mi equipo mientras realizaba el ejercicio

Estado de los CPUs y la memoria

Temperatura (º C)

Muchos cuelgues de la aplicación teniendo que matar los procesos y perdiendo configuraciones que creía guardadas. Os aconsejo arrancar los dispositivos que necesitéis a la hora de configurarlos y posteriormente encender el resto para comprobar los resultados.

Pruebas

Desde los routers frontera, PEs, con los comandos ping y traceroute podemos comprobar que tenemos conexión entre los distintos equipos finales, CEs:

En los routers clientes igualmente comprobamos que conocemos todas las direcciones del resto de sedes

Y que tenemos conexión entre las mismas

En la siguiente entrada realizaré la configuración del cliente Verde y veremos como tenemos conexión entre las distintas sedes de cada VRF utilizando el mismo direccionamiento.

Un saludo, Brixton Cat.