Mostrando entradas con la etiqueta Proxy. Mostrar todas las entradas
Mostrando entradas con la etiqueta Proxy. Mostrar todas las entradas

martes, 5 de mayo de 2009

Nagios, monitorizando los miembros de un cluster

Después de configurar el cluster para el servicio de proxy surge la inevitable necesidad de monitorizar su funcionamiento.

Nagios es un excelente software de monitorización y testeo de disponibilidad de servicios, yo incluso he logrado monitorizar una centralita Avaya con este software, y el cluster heartbeat también es posible monitorizarlo, en este post voy a explicar como chequeo el estado del servicio de proxy y la disponibilidad de cada uno de sus miembros.

Hay muchos manuales para instalar Nagios, por lo que paso directamente al tema; lo primero es monitorizar la disponibilidad del servicio que estamos ofreciendo, en este caso de proxy, independientemente del estado de los miembros del cluster;

En el directorio NAGIOS:/etc/nagios2/conf.d#

# Definimos el Host de nuestro cluster y definimos los miembros

define host {

host_name proxy.dominio.local

alias vIP Cluster Proxy

address 192.168.1.100

use generic-host

}

define host {

host_name A4

alias Proxy A1

address 192.168.1.101

use generic-host

}


define host {

host_name A5

alias Proxy A2

address 192.168.1.102

use generic-host

}


define host {

host_name A6

alias Proxy A3

address 192.168.1.103

use generic-host

}


#Definimos el hostgroup para chequear servicios

# Proxys


define hostgroup {

hostgroup_name PROXY-CLUSTER

alias PROXY-CLUSTER

members proxy.dominio.local,A1,A2,A3

}


# Definimos el servicio para el grupo

define service{

hostgroup_name PROXY-CLUSTER

service_description PROXY-CLUSTER

check_command check_squid

use generic-service

}



Hay que tener en cuenta que la definición de comando de servicio este correcta en /etc/nagios-plugins/config/http.cfg deberiamos de tener una linea como la siguiente


# 'check_squid' command definition

define command{

command_name check_squid

command_line /usr/lib/nagios/plugins/check_http -H $HOSTADDRESS$ -p 3128 -u http://www.google.es -e 'HTTP/1.0 200 OK'

}

Yo compruebo que este disponible google.es pero se puede utilizar cualquier URL.

Con esto ya tendriamos resultados a cerca del estado del servicio, pero no sabriamos si un miembro del cluster ha caído, para ello se puede hacer algo simple como un ping (o en Nagios un Check_host_alive) pero así solo tendríamos la disponibilidad del host, no la del servicio proxy y mucho menos si para el cluster el miembro sigue presente.

Utilizo un pluggin de Nagios llamado check_heartbeat_link descargable aquí, con este pluggin podemos consultar en cada miembro del cluster como esta viendo al resto de los miembros, este pluggin hay que ejecutarlo mediante NRPE (nagios remote pluggin execute) aquí hay un manual para configurarlo.


define service{

use generic-service

host_name A1

service_description Heartbeat

check_command check-nrpe-heartbeat

}

define service{

use generic-service

host_name A2

service_description Heartbeat

check_command check-nrpe-heartbeat

}

define service{

use generic-service

host_name A3

service_description Heartbeat

check_command check-nrpe-heartbeat

}


El resultado, mas un par de cosas interesantes a chequear debería de ser el siguiente;


miércoles, 18 de julio de 2007

Squid, optimizando el acceso a la red

El acceso a la red es uno de esos servicios en las empresas a los
que no se les suele prestar demasiada atención; "hay internet no,,, pues entonces cual es el problema??" el problema es que normalmente tienes una red LAN plana con un router ADSL que te ha puesto telefónica y que ofrece DHCP para que todo el mundo pueda "navegar". Esto es un gravísimo problema de seguridad, sabemos que internet es "la herramienta" pero tambien es la entrada de la mayoría de problemas que nos podemos encontrar en las grandes y medianas redes corporativas.


No podemos confiar en el firewall integrado del router ADSL, normalmente tienen una configuración por ser generosos, escueta, y no ofrecen ninguna información ante ataques no gestión snmp...

Y aun asi este no es el unico problema, el acceso masivo en las empresas a Internet provoca graves cuellos de botella, todo el mundo accede a la vez al servidor Webmail, a la aplicación Web de ventas, al Marca, al mundo, Youtube, flickr, Wikipedia, ebay, myspace, segundamano... ¿me equivoco? La optimización del acceso a Internet es una necesidad, el ancho de banda es estático y los usuarios sólo tienden a crecer en número y peticiones.

Squid es un potentísimo servidor Proxy-cache con funciones muy avanzadas tanto para el control de acceso como para la gestión de la cache, aquí voy a tratar de explicar cual es la solución más de control de acceso que de cache, que hemos implantado para un servidor proxy para 1300 usuarios compulsivos de Internet con Squid con unos resultados increíbles.

La distro como siempre Debian, pero es indiferente, si alguien se quiere complicar la vida con otra ... La máquina elegida es un servidor Proliant DL360 G5, con un Dual Core Xeon y dos discos SAS de 65Gb en mirroring. La distro de Debian es Testing "etch" mientras escribo estas líneas... El servidor Proxy siempre debería de estar ubicado en un DMZ o sea protegido por un frirewall, aunque también podemos levantar IPtables en nuestra máquina y utilizar un interface de red a Internet y otro a LAN (esto en otro capitulo...).


MASAKO:~# apt-get install squid


Y ya tenemos instalado el servicio, por defecto asi sin más ya tendríamos acceso proxy desde nuestra propia máquina . El fichero de configuración por defecto estaría en;


MASAKO:~# vim /etc/squid/squid.conf


Editando este fichero, que es enorme, podemos ver la cantidad de configuraciones que podemos hacer, todo esta muy bien comentado, la mayoría de configuraciones que vienen por defecto las dejamos con están a no ser que después de documentarse interese lo por lo que voy a lo que interesa;


http_port 3128 #puerto en el que va a escuchar nuestro proxy

acl all src 0.0.0.0/0.0.0.0 # Red de nuestro servicio

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255 #acl para nuestra propia máquina


# puertos que denominamos seguros

acl SSL_ports port 443 444 563 # https, snews

acl SSL_ports port 873 # rsync

acl Safe_ports port 80 81 # http


acl sitiosDENEGADOS url_regex "/etc/squid/sitiosDENEGADOS" # Regla para los sitios a los que no vamos a permitir entrar a los usuarios, basada en expresiones en las URL's


#ACL USUARIOS con esta regla otorgamos acceso

acl USUARIOS src 172.95.30.0/24 #a esta subred

http_access allow !sitiosDENEGADOS USUARIOS # a acceder a internet pero filtrando por el acceso a las paginas por expresiones en la URL como vermeremos a continuación; editamos el fichero #vim /etc/squid/sitiosDENEGADOS


http://www.hotmail.com/

http://www.microsoft.com/

sex

hacks

virus

anonymizer

games

juegos


Como veras se pueden restringir tanto URLs como expresiones en URL's o sea que no vamos a definir restringir todo el acceso a paginas web de juegos, pero si que podemos restringir el acceso a páginas que contengan el string en la dirección...

Luego con este comando comprobamos que la configuración es válida
# squid -k debug

Y con este otro le decimos al servicio que asuma los cambios
# /etc/init.d/squid reload

Podemos comprobar que el servicio continua ejecutándose comprobando que se escuchan las peticiones TCP en el puerto configurado
# netstat -an grep LIST grep 3128

(…)