El blog de LandM

Cuando se monta una infraestructura algo más compleja que las normales, se suele utilizar un frontend web para servir contenido estático y el resto pasarlo al backend para que sea interpretado por un servidor de aplicaciones (java, php, …). Esto es muy cómodo de administrar y se puede montar alta disponibilidad desde el frontend.

En este caso se hace un proxy inverso, es decir, se envían las peticiones desde el frontend al backend. El “problema” es que las peticiones tienen origen (frontend) 127.0.0.1 (si en el backend está en la misma máquina) o la ip interna 192.x.x.x (si el backend está en la red interna). Si el frontend es suficientemente flexible soporta balanceo entre servidores. Esta es una lista de frontends que funcionan muy bien:

• pound: básicamente es un balanceador, pero muy eficiente
• perlbal: balanceador hecho en perl y servidor web para archivos estáticos. El código perl es sencillo y muy pontente, por lo que se pueden añadir funcionalidades rápidamente. Muy eficiente.
• squid: el de siempre. Se ha utilizado mucho para hacer proxy directo en vez de inverso, pero también se puede utilizar. Funciona muy bien y tiene un montón de funcionalidades, pero es menos eficiente que los anteriores.
• HAPrroxy: si buscas información detellada no te pierdas la documentación. Al final existe una explicación de la arquitectura separada en contenido estático y dinámico. Es uno de los mejores balanceadores/proxy, aunque incluye más funcionalidades.
• lighttpd: es un servidor web que nos puede servir páginas estáticas y hacer de proxy para el resto de peticiones. Una de las funcionalidades más interesantes es que puedes aplicar regular expressions para decidir el backend. Lo utilizamos en alguna ocasión con éxito.
• nginx: es un servidor web que cada día tiene mejor pinta. Es muy eficiente, rápido y sencillo de configurar. Cada día peligra más la hegemonía del apache. Permite servir un tipo de contenido y reenviar el resto al backend. Permite también regular expressions. Lo tenemos como frontend en algunos servidores y es una maravilla.

Pues bien, todas estas soluciones hay que configurarlas para que envíen la ip real al backend. Por ejemplo, en el caso del nginx hay que poner estas líneas:

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Sin embargo, el apache siempre pinta la ip del que viene la petición: 127.0.0.1 o la ip interna. Para lograr que pinte la ip real hay que utilizar un pequeño módulo: mod_rpaf.

El montaje es sencillo:

$ wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.5.tar.gz
$ tar xzf mod_rpaf-0.5.tar.gz
$ cd mod_rpaf-0.5
$ vi Makefile (editar la variable APXS)
$ make rpaf; make install (para el apache 1.x)
$ make rpaf-2.0; make install-2.0 (para el apache 2.0.x)

Luego hay que editar la configuración del apache y añadir estas líneas:

LoadModule rpaf_module        libexec/mod_rpaf.so
AddModule mod_rpaf.c
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 192.168.1.1
RPAFheader X-Forwarded-For

Ojo, en la línea RPAFproxy_ips hay que poner todas las ips desde donde vengan las peticiones al apache. Reiniciamos el apache y ya están las ips reales en los ficheros de logs.