Blog About

B Y MANUEL VIERA JANUARY 06, 2013

Nginx como proxy HTTP

#NGINX #LINUX

De regalo de Reyes os traigo un post bastante sencillo sobre Nginx. Se trata de

con gurar Nginx para que funcione como un proxy HTTP, pero antes de nada

Qu es un proxy?
Un proxy no es ms que un intermediario, que es el signi cado que tiene la
palabra proxy en ingls, en la comunicacin que se realiza entre dos puntos. Por
ejemplo, entre un cliente, que puede ser un navegador web, peticin Ajax, etc;
y un servidor. Hay muchos tipos o aplicaciones distintas para un proxy como
pueden ser proxy inverso (reverse proxy), proxy transparente, proxy cache; y
todas ellas se pueden combinar en una misma con guracin. Por ejemplo
podramos con gurar un proxy HTTP inverso con cache para acelerar el tiempo
de respuesta de ste a medida que se va utilizando. En este caso vamos a
con gurar un proxy HTTP inverso, pero

Que nos ofrece un proxy HTTP inverso?

Antes de nada, nuestro proxy, como su propio nombre indica, va a estar
orientado al servicio HTTP o HTTPS (HTTP Secure), es decir, slo va a trabajar
con peticiones HTTP. Aunque Nginx como tal, tambin podra actuar como IMAP
Proxy, un proxy para el protocolo IMAP (Internet Message Access Protocol) de
correo, pero no va a ser este el caso. Como proxy inverso nos va a permitir:

Aadir seguridad, protegiendo al resto de servidores web del ataque

directo de los usuarios.
Reescribir las URLs segn nuestras necesidades.
Securizar el acceso a nuestras aplicaciones web con HTTPS, es decir,
podremos enrutar la peticin HTTP hacia HTTPS y securizar la comunicacin
entre los dos puntos.

Imaginemos que en nuestra red corporativa o domstica, tenemos varios

servidores web en nuestra DMZ publicando diferentes aplicaciones web, pero
queremos controlar la publicacin de cada una de stas al exterior. En ese
caso, podramos redirigir todo el tr co HTTP entrante desde el rewall hacia el
proxy HTTP y controlar la publicacin de las aplicaciones web al exterior. Como
he comentado anteriormente, podramos aadir HTTPS obligatoriamente al
acceder a una aplicacin web, aadir autenticacin bsica (usuario y
contrasea), etc.

Con guracin
Vamos a suponer que Nginx ya se encuentra instalado en nuestro sistema. Si no
fuera el caso, es posible consultar mi anterior articulo sobre la instalacin de
Nginx. La con guracin que obtengo, eliminando los comentarios, tras haber
instalado Nginx desde los repositorios de Debian 7 (Wheezy) es la siguiente:

root@nginx:/# grep v "#" /etc/nginx/nginx.conf |uniq

user wwwdata;
worker_processes 4;
pid /var/run/nginx.pid;

events {
worker_connections 768;
}

http {

sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;

include /etc/nginx/mime.types;
default_type application/octetstream;

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

gzip on;
gzip_disable "msie6";

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sitesenabled/*;
}

NOTA: la con guracin suele ser diferente dependiendo del mtodo de

instalacin: utilizando los repositorios de la distribucin o compilando desde las
fuentes.

Qu signi ca sta con guracin?

Podemos apreciar varias directivas que son globales: user ,
worker_processes y pid ; y varios bloques como events , que con gura
el nmero de conexiones para cada worker (recordad, nmero de conexiones
totales = worker_processes * worker_connections) y el bloque http que de ne
algunas directivas como:

keepalive_timeout : tiempo que se va a mantener una conexin viva.

include : permite incluir cheros que contienen ms con guracin como

en este caso los tipos MIME y los cheros de con guracin en el directorio
sites-enabled.
access_log : de ne el chero de acceso donde se registrarn las
conexiones al proxy http.
error_log : igual que access_log pero solo registrar los intentos fallidos
de conexin.
gzip : permite comprimir los datos enviados con gzip, consumiendo
menos ancho de banda.

Es posible que dentro del bloque http podamos encontrar otro bloque
llamado server y que contenga algo como lo siguiente:

server {
listen 80;
server_name localhost;

location / {
root html;
index index.html index.htm;
}

error_page 500 502 503 504 /50x.html;

location = /50x.html {
root html;
}
}

Es necesario eliminar este bloque de con guracin en el chero de

con guracin principal nginx.conf ya que el bloque server lo de niremos
para cada uno de los sitios a publicar, dentro del directorio
sites available .

sites-available y sites-enabled
Normalmente, y sobretodo si se instala Nginx utilizando los repositorios del
sistema, durante la instalacin se crean dos directorios
llamados sites available y sitesenabled , pero para qu funcin
tienen y para qu se usan? Muy fcil.

sitesavailable : se utiliza para almacenar la con guracin de cada

sitio o aplicacin web. Siguiendo las buenas prcticas, se debe crear un
chero de con guracin por cada sitio, para evitar tener la con guracin
de todos los sitios en un solo chero.
sitesenabled : directorio que utiliza Nginx para saber qu sitios estn
activados. El contenido de este directorio deben ser enlaces simblicos que
apuntan a los cheros de con guracin del directorio
sitesavailable .

Nota: la creacin de los directorios sitesavailable y sitesenabled

son una prctica muy comn realizada por la paquetera del sistema, es decir, es
una accin que realiza el paquete descargado de los repositorios durante la
instalacin. Pero es muy probable que dichos directorios no aparezcan si se
instala Nginx desde las fuentes. En ese caso, solamente habra que crear dichos
directorios e incluir el futuro contenido de estos mediante la
directiva include en la con guracin principal de Nginx.

Publicando un sitio web

Ya estamos casi a punto. Slo nos falta con gurar una redireccin en el
directorio sitesavailable y enlazarla con un enlace simblico
en sites enabled , as que vamos a ello!

1. Creamos el chero de con guracin test.manuelviera.es.conf en el

directorio /etc/nginx/sitesavailable/ con una con guracin
como la siguiente:

server {
listen 80;
server_name test.manuelviera.es;
location / {
proxy_pass http://192.168.1.200:8080;
proxy_set_header XRealIP $remote_addr;
proxy_set_header Host $http_host;
}
}

Nota: creo que es buena prctica establecer como nombre de chero el

mismo que el dominio que estamos publicando, es decir, el valor de la
directiva server_name . De esta forma, le indicando nuestro Nginx que
cuando reciba una peticin del dominio test.manuelviera.es por el puerto
80, debe redirigir la peticin HTTP al host 192.168.1.200 al puerto 8080,
que es donde se encuentra nuestra aplicacin web desplegada. El
ingrediente estrella en esta con guracin es el uso del
mdulo proxy_pass incluido en el Core de Nginx, y es la directiva que
nos permite pasar la peticin que nos llega hacia otro destino, en este caso,
el servidor web donde se aloja nuestra supuesta aplicacin. Como podis
observar, tambin hemos hecho uso de otra directiva
llamada proxy_set_header que nos permite aadir o modi car
cabeceras, en este caso hemos editado dos cabeceras:

XRealIP : contiene la IP del cliente que inicia la peticin, y se ha

establecido el valor de la variable $remote_addr con la idea de que al
servidor destino le llegue la IP del cliente y no la del proxy HTTP. Si no
se hubiese modi cado esta cabecera (header) la IP que recibira el
servidor web objetivo siempre sera la del proxy HTTP.
Host : Al igual que la anterior cabecera, establecemos el valor con el
contenido de la variable $http_host, es decir, el nombre de host que
especi c el cliente.

2. Una vez con gurado nuestra primera redireccin, slo nos falta activarla, es
decir, crear un enlace simblico hacia esta en el directorio sites-enabled:

root@nginx:~# cd /etc/nginx/sitesenabled/
root@nginx:/etc/nginx/sitesenabled# ln s ../sitesavailab
le/test.manuelviera.es.conf
root@nginx:/etc/nginx/sitesenabled# ls l
total 0

lrwxrwxrwx 1 root root 43 Jan 6 12:05 test.manuelviera.es.

conf > ../sitesavailable/test.manuelviera.es.conf

3. Una vez enlazada el chero de con guracin, debemos obligar a Nginx a

recargar la con guracin con la siguiente instruccin:

root@nginx:~# service nginx reload

Reloading nginx configuration: nginx.

Perfecto! Pero an nos queda el ltimo paso, y no por ello menos

importante

Comprobar el funcionamiento del proxy HTTP

Siempre debemos comprobar que lo que hemos hecho realmente funciona, ya
que de no ser as, es como si no hubisemos hecho nada y daremos mala
imagen como profesionales. Si lo que tenemos es un entorno de prueba, que
an no se encuentra implantado en produccin, una prueba muy sencilla sera
utilizar el chero /etc/hosts aadiendo la IP de nuestro proxy HTTP y el
dominio especi cado en la directiva server_name , de la siguiente forma:

$ sudo sh c "echo 192.168.1.200 test.manuelviera.es >> /etc/ho

sts"

Nota: en mi caso, el proxy HTTP se encuentra en la IP 192.168.1.200. Si todo ha

ido bien, nuestro proxy HTTP, tras realizar la peticin, deber habernos redirigido
al host especi cado en la directiva proxy_pass :-) Otra prueba sencilla para
comprobar que el proxy HTTP funciona es especi car un sitio externo como
terra.es, google.es, etc; en la directiva proxy_pass , si an no se dispone de
un servidor web interno que sirva una aplicacin web.

Y esto ha sido todo amigos! Espero que os sea de utilidad y Feliz da de Reyes!

Un saludo.

Tweet 21

Written with by Manuel Viera

Manuel Viera Blog About

Powered by Hugo & hosted by |

Hecho con + + + +