RouterMaN’s Blog

Como el título lo indica, el objetivo de este post es instalar estas 3 aplicaciones y que nos muestre las estadísticas de consumo. Normalmente si instalamos solo Dansguardian y Squid en los logs del squid vemos que las peticiones para loguearse son de la propia máquina. Lo cual es inútil para el Sarg, pues todas las estadísticas serían con localhost. Para arreglar este problema, se debe compilar el squid con el tag “–enable-follow-x-forwarded-for”. Para hacerlo simplemente seguimos los siguientes pasos:

Instalamos las dependencias del squid

apt-get build-dep squid

Descargamos las fuentes del squid

cd /usr/src/

apt-get source squid

Modificamos las opciones de compilación

vim /usr/src/squid-2.6.5/debian/rules

En este archivo, en la parte del configure (linea 141 apróx) aumentamos la opcion:

--enable-follow-x-forwarded-for \

Editamos el changelog y le ponemos una version superior

vim /usr/src/squid-2.6.5/debian/changelog

En mi caso la linea queda squid (2.6.5-7) unstable; urgency=high
(Antes era squid (2.6.5-6) unstable; urgency=high)

Ahora creamos el paquete

cd /usr/src/squid-2.6.5
dpkg-buildpackage

Instalamos los paquetes generados con dpkg -i. En nuestro caso, estos paquetes son squid y squid-common

Una vez instalado los paquetes, configuramos el archivo /etc/squid.conf. Las siguientes lineas deben estar añadidas o descomentadas

acl localhost src 127.0.0.1/255.255.255.255
acl redinterna src 10.1.0.0/255.255.0.0
acl reddmz src 192.168.214.0/255.255.255.0

follow_x_forwarded_for allow localhost
acl_uses_indirect_client on
log_uses_indirect_client on

http_access allow localhost
http_access allow redinterna
http_access allow reddmz

Con eso terminamos la configuración del squid. Ahora para el dansguardian y el Sarg los instalamos como cualquier otro paquete en debian, es decir, con apt-get. Debemos indicarle al Dansguardian que mande en la cabecera HTTP al squid, el cliente inicial, para eso activamos el parametro forwardedfor (línea 248 aproximadamente)

forwardedfor = on

Para el caso del sarg, simplemente se instala, pero debemos tener en cuenta el logrotate, que por defecto está en un día. Debemos cambiarlo para que sea una vez a la semana, así como también aumentar el tamaño máximo del access.log

Una configuración RoadWarrior es aquella en la cual se tiene una red privada con uno o varios clientes que accesarán a la red como si fueran parte de ella (arquitectura host-to-net). El presente tutorial explica como configurar correctamente el openvpn 2.0.9-4 en un Debian Etch que ya tiene configurado Shorewall. Tomé como base el tutorial de la configuración para CentOS y lo modifiqué de acuerdo a lo que yo quería.

Primero instalamos el openvpn:

apt-get install openvpn

El openvpn viene con un directorio llamado easy-rsa, que tiene scripts bastante útiles para la configuración. Este directorio lo copiamos a /etc/openvpn

cp -a /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn

Ahora nos vamos a ese directorio recién creado y ejecutamos los siguientes comandos

. vars
./clean-all
./build-ca

Con ellos lo que haremos es:
* Inicializar variables de ambiente para poder trabajar con los siguientes scripts de shell para generar las variables
* Inicializamos el directorio de las claves (borrando potenciales archivos viejos)
* build-ca: procedemos a generar el certificado CA

Nos pedirá datos sobre la organización. No poner cualquier cosa ya que las preguntas se van a repetir más adelante y debemos estar seguros de lo que habíamos escrito. En Common Name debemos poner cualquier cosa pero ponerla

Una vez creado el Certificate Authority (CA), creamos la llave del Servidor

./build-key-server servidor

En Common Name ponemos Servidor u otro nombre pero que sea diferente al anterior

Con este paso se crearon dos archivos (servidor.crt y servidor.key). Estos archivos debemos copiarlos al directorio /etc/openvpn

Ahora generamos las claves de los clientes. Debemos ejecutar los mismos para cada cliente:

./build-key cliente1

Esto genera los archivos cliente1.key (llave) y cliente1.crt (certificado)

Creamos los parámetros Diffie-Hellman:

./build-dh

Ahora todos los archivos creados menos los de los clientes deben ser copiados a /etc/openvpn/, es decir ca.crt, ca.key, server.crt, server.key y dh1024.pem

Ahora pasamos los archivos necesarios a los clientes. Estos archivos son clientex.crt, clientex.key y ca.crt, se los podemos pasar vía sftp o scp, pero siempre tratando de que sea seguro.

La configuración del servidor la ponemos en /etc/openvpn/server.conf

port 1194
proto udp
dev tun
persist-tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

#Direcciones que se asignaran a los
#clientes, el server es .1
server 10.1.1.0 255.255.255.0

ifconfig-pool-persist ipp.txt

#Ruta para que los clientes alcancen la red local del server (1.0/24)
push “route 192.168.1.0 255.255.255.0″

#Para que los clientes se visualicen entre ellos
#Debe ir junto con la opción routeback en el shorewall
client-to-client

keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 4

La red local de la VPN es 192.168.1.0/24 y la red de la VPN es 10.1.1.0/24. El usuario remoto, si está detrás de un NAT debe tener una dirección local no perteneciente a la red de la VPN.

La configuración de los clientes sería así:

client
dev tun
proto udp
remote host.dominio.com
float #debido a que la IP de arriba es dinamica
resolv-retry infinite
nobind
persist-key
persist-tun
ca “D:\\Archivos de programa\\OpenVPN\\ca.crt” #Tener cuidado con el doble backslash (\\)
cert “D:\\Archivos de programa\\OpenVPN\\clientx.crt”
key “D:\\Archivos de programa\\OpenVPN\\clientx.key”
comp-lzo
verb 4

Ahora solo falta inicializar en los clientes, para ello es necesario el siguiente código:

openvpn –config “ruta_cliente.ovpn”

En este caso no son necesarios los \\, con uno solo basta.

Con las líneas de arriba se arma la VPN, ahora solo falta modificar el firewall para que esa nueva interfaz sea procesada y sus paquetes sean aceptados. Uso shorewall como frontend de iptables, y las modificaciones necesarias son las siguientes:
/etc/shorewall/zones (agregamos la nueva zona llamada road)

#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
road ipv4

/etc/shorewall/interfaces

#ZONE INTERFACE BROADCAST OPTIONS
road tun+ detect routeback

El Broadcast y las opciones se ponen siempre y cuando se pueda accesar desde la red a los usuarios de la VPN

/etc/shorewall/tunnels

#TYPE ZONE GATEWAY GATEWAY ZONE
openvpnserver:1194 net 0.0.0.0/0

openvpnserver puede ser reemplazado por openvpn, aunque no se recomienda debido a que este último no soporta a clientes detrás de un NAT.

/etc/shorewall/policy

#SOURCE DESTINATION POLICY
road loc ACCEPT

Aceptamos todo el tráfico proveniente de la VPN

Reiniciamos el shorewall e iniciamos el openvpn y todo debería funcionar.

AjaxTerm es un terminal basado en web. Está escrito en Python e implementa Ajax en el lado del cliente.

En Debian se instala como cualquier otro paquete:

# apt-get install ajaxterm

Una vez iniciado solo acepta peticiones del mismo equipo (127.0.0.1) al puerto 8022. Sin embargo, el Apache puede actuar de proxy y hacer esa petición por nosotros. Esto lo hacemos con el mod_proxy

# apt-get install libapache2-mod-proxy-html 

De todas formas para que el viaje hasta el apache sea cifrado debemos usar SSL. Para esto debemos habilitar el módulo ssl del apache, que viene por defecto pero que no está habilitado, así como también el módulo proxy

# cd /etc/apache2/mods-enable/
voip:/etc/apache2/mods-enabled# ln -s ../mods-available/ssl.load ssl.load
voip:/etc/apache2/mods-enabled# ln -s ../mods-available/proxy.load proxy.load

Existe otra forma de cargar los módulos en apache, y es con el comando a2enmod. Usamos este comando para añadir los modulos que faltan:

# a2enmod proxy_connect
# a2enmod proxy_ftp
# a2enmod proxy_http

Ahora lo que falta es crear las llaves válidas, para ello vamos a la carpeta donde estarán los certificados del apache, en este caso /etc/apache2/ssl/. Si no existiera, creamos el directorio con mkdir

 

# openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem

Con esto ya hemos configurado todo lo referente a lo necesario para el apache. Ahora debemos configurar explicitamente la configuración del Host Virtual. Para esto editamos el archivo /etc/apache2/sites-available/default. Añadimos lo siguiente al final del mismo.

 

Listen 443
NameVirtualHost *:443

<VirtualHost *:443>
        ServerName voip.tumihost.net
        SSLEngine On
        SSLCertificateFile ssl/apache.pem

        # Suppresses the Via header
        ProxyVia Off
        # Do not flood the log
        #CustomLog /var/log/apache2/access.log combined env=!dontlog
        #SetEnvIf Request_URI "^/ajaxterm/u" dontlog

        ProxyRequests Off
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>
        ProxyPass /ajaxterm/ http://localhost:8022/
        ProxyPassReverse /ajaxterm/ http://localhost:8022/
</VirtualHost>

 Y listo!!. Ahora para entrar a la aplicación basta hacer https://servidor/ajaxterm/
Una vez dentro aceptar el certificado y ya podemos usar el ajaxterm cifrado.

Siguiendo las instrucciones que encontré en munckfish.net, hice mi propio paquete  de netbeans en (K)Ubuntu, bueno en realidad lo unico que hice fue seguir exactamente las instrucciones mostradas ahí y cambiar la dependencia al java5 por java 6, y cambiar algunos scripts de instalación. (como por ejemplo añadir las variables de entorno PATH, CLASSPATH a los directorios del java 6).

En el proceso de debianización, se crean dos paquetes, los cuales son:

• netbeans-ide_5.5-1_all.deb
• netbeans-platform_5.5-1_all.deb

Estos paquetes .deb ya se encuentran colgados en GST.

Bueno, siguiendo experimentando con Debian y Asterisk, tuve un pequeño accidente con la distribución Xorcom, la cual desconfiguró por completo mi asterisk.

No sé que ocurrió exactamente, solo supongo que fue porque me puse a modificar a la mala los archivos de configuración, cuando debí hacerlo a través de la BD. Pensé que era problema de la distribución en sí y volví a instalar pero esta vez un debian sarge, al cual agregue sólo los paquetes necesarios (AMP y asterisk) para que funcionase.

Ahora estoy probando esta nueva fórmula y me me va bien. El webphone de nuevo está disponible.

Saludos,

El “click-to-talk” es simplemente poder llamar a anexos IPs desde una página web mediante un solo click.
En estos tiempos estoy de cabeza con el asterisk, pues quiero hacer mi tesis en algo relacionado a VoIP (todavía no sé exactamente el tema en sí, pero tengo varias ideas que ya las iré descartando y me quedaré con la mejor) . Pues bien, en mis investigaciones con el asterisk encontré el proyecto IAXclient, el cual usé para el click to talk, la implementación y el cómo funciona es tema de otro post y cuando tenga tiempo escribiré sobre eso.

Para los que quieran comunicarse conmigo pueden hacerlo a través de este enlace. Estoy de Martes a Viernes de 9 hasta que me quite (normalmente después de comer). Ah, el webphone por ahora solo funciona en iexplorer 6 o más, ya veré que puedo hacer para que funcione en firefox.

He estado probando la distribución Xorcom Rapid basada en debian sarge, he quedado maravillado con el AMPortal (ahora conocido como Freepbx). Esta interfaz permite modificar el asterisk “en caliente” y muy intuitivamente, lo recomiendo para aquellos que recien se inicien en asterisk pero ya tienen experiencia en debian (para los que no, les recomiendo asterisk@home, basado en CentOS).

El procedimiento para instalar AMPortal lo pueden encontrar aquí (se supone que ya se tiene instalado un Xorcom Rapid, aunque con un debian sarge no debería fallar). Básicamente es el siguiente:

Agregamos la siguiente línea a nuestros repositorios:

deb http://rapid.dotsrc.org/ unstable/

luego actualizamos con

apt-get update

y luego para instalar AMP

apt-get dist-upgrade
apt-get install amportal

Intenté hace algún tiempo el procedimiento anterior en una debian etch sin resultados satisfactorios, cuando tenga tiempo (y otra máquina para probar) lo haré desde una debian sarge.

Ha llegado a mis manos una tarjeta digium TDM22B. Esta tarjeta tiene 2 interfaces FXO y dos interfaces FXS. Llegó la hora de jugar un poco con asterisk!!!!!

Desde hace un par de días, mis posts no están apareciendo en el planeta Debian Perú. No sé si sea problema de mi feed o problema del planet en sí. Ojalá que se arregle pronto

RoundCube es un webmail hecho con PHP y Mysql. La ventaja que tiene frente a otros webmails es que usa AJAX, lo cual lo convierte en un webmail de última generación.
RoundCube, a diferencia de otros webmails, funciona como un cliente imap, lo que le permite conectarse a cualquier servidor imap. Si lo quieres tener en tu servidor, necesitas instalar un servidor imap, en este tutorial usaremos dovecot. Existen otros servidores imap, pero su configuración es un tanto más engorrosa y ya no se podrían ver los correos con el webmail tradicional (openwebmail en mi caso) debido a que la mayoría de servidores imap almacena los correos en un directorio “Maildir” y no en los mbox a los que estamos acostumbrados.

1) Lo primero que tenemos que hacer es bajar el RoundCube y subirlo por (s)ftp a cualquier webhost (no necesariamente a la misma máquina del servidor de correo).

2) El siguiente paso a seguir es modificar los permisos de los directorios temp y log para que se puedan leer y escribir desde web. Nos posicionamos en el directorio donde subimos el RoundCube y ejecutamos:

chown -R www:www temp logs

3) Ahora pasamos a crear la BD rcm en mysql. La forma más fácil es teniendo phpmyadmin instalado, y crearlo por ahi junto con el script de inicio que se encuentra en SQL/mysql.initial.sql

4) Nos vamos al directorio config y copiamos los archivos *.php.dist a *.php

cp db.inc.php.dist db.inc.php
cp main.inc.php.dist main.inc.php

5) Editamos db.inc.php y lo modificamos dándole el nombre de usuario y la contraseña para poder ingresar a la base de datos creada en 3. Específicamente tenemos que modificar las variables:
$rcmail_config[’db_dsnw’] (acá ponemos el String de conexión a nuestra BD),
$rcmail_config[’smtp_server’] (dejar en blanco y solo modificarlo si es que prueban que el php no puede enviar correos),
$rcmail_config[’default_host’] (si está en blanco al accesar por web podremos elegir a que servidor imap conectarnos; si ponemos uno, ya no podremos elegir y solo nos conectaremos a ese),
$rcmail_config[’enable_caching’] (si nuestro webserver está en la misma PC que el mail server esta opción debe estar en FALSE.

6) Antes de accesar por web a nuestro webmail, debemos instalar previamente un servidor imap. Como dije anteriormente, usamos dovecot porque este permite seguir usando los buzones de formato mbox (queremos usar mbox para permitir compatibilidad de acceso al correo con otros webmails como por ejemplo openwebmail)

7) Estando todo listo, no queda más que ingresar por web y disfrutar de este maravilloso webmail hecho usando AJAX