Esto puede constituir un pequeño desastre para todos los servicios que tengo montados, ya que hay que copiar todos los datos al nuevo servidor, tirar el servicio antes para que los datos no cambien, y levantar los servicios en el nuevo, asegurándose de que todo funcione… vale, por ahí, ya sé que van a ser un par de horas… pero el DNS… con su propia caché y demás, eso sí puede ser un gran problema.

Por ese motivo me puse a buscar y, a modo de post-it, me lo dejo aquí escrito para futuro, y por si alguien lo necesita también. Básicamente es: cómo redirigir el tráfico de un servidor a otro, empleando iptables.

Redirigiendo…

Vale, estoy en el antiguo servidor, tengo email y web. Los puertos por los que llega la comunicación, todos TCP, y posibilidad de SSL, pero en eso no hay mayor problema. En esencia tengo que cuidarme de las peticiones a los puertos: 80 (http), 443 (https), 25 (smtp), 465 (ssmtp), 110 (pop3), 995 (pop3s), 143 (imap) y 993 (imaps).

Buscando, vi esta web sobre como redireccionar tráfico, por lo que, escribí:

echo 1 >/proc/sys/net/ipv4/ip_forward
export IP=XXX.XXX.XXX.XXX
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination $IP
iptables -t nat -A POSTROUTING -p tcp -d $IP --dport 80 -j MASQUERADE

NOTA: como es lógico, hay que cambiar XXX.XXX.XXX.XXX por la IP del servidor al que se quieren redireccionar las peticiones al puerto 80.

Lo que hacen estos comandos es:

1. Indica al kernel que puede hacer forward de los paquetes que pasen por su interfaz de red.
2. Indica al sistema que los paquetes entrantes al puerto 80 sean dirigidos a la $IP indicada.
3. Indica al sistema que los paquetes que deban de salir, se emascaren modificando su IP de origen por la propia.

Con esto conseguimos que la comunicación hacia el puerto 80 pase sin problemas al otro servidor. Lo único, es que se desvirtúan las estadísticas, ya que para el servidor web, todas las peticiones son del servidor que redirecciona las peticiones, pero si es un recurso temporal (como es mi caso), no tiene mucha o mayor importancia

¿Cómo funciona el enrutado?

Encontré también otra página donde se explica bastante bien (aunque algo esquemática) la forma en que funciona el enrutado de paquetes empleando iptables, el gráfico:

Como puede verse, el paquete pasa por la cadena de reglas PREROUTING al entrar, es procesado y, cuando se detecta que es para otra máquina, se pasa a FORWARD y después a POSTROUTING, donde se pueden agregar reglas de modificación antes de que el paquete sea entregado a su destino.

Recomiendo echar un vistazo al enlace dado para ampliar más sobre el tema.

Conclusiones

Nada es perfecto al 100%, por ejemplo, esto mismo lo probé con XMPP, y no funciona correctamente, ya que la comunicación de s2s del protocolo espera que los mensajes lleguen del dominio (e IP) al que se solicita información, mientras que, estos mensajes, en su mayoría, al estar direccionados al dominio, no es la misma IP. No obstante, como medida temporal y sobretodo para HTTP, el apaño lo da.

Conceptos

Antes de comenzar a entrar en el tema, vamos a definir algunos conceptos muy útiles y a tener en cuenta, para no perdernos. Es importante conocer estas palabras y el significado que conllevan para poder entender, a posteriori, cómo funciona el sistema web:

• web: en inglés, telaraña, se refiere al entramado que se imagina cuando de una página se pasa a otra enlazándose entre sí todas ellas, formando una imagen como de telaraña, o web.
• URL: Uniform Resource Locator, o lo que quiere decir como Localizador de Recurso Uniforme. En sí es la dirección completa de un recurso que se solicita a través de Internet (y más específicamente del protocolo HTTP). Este tiene la forma:

  http://host:port/uri

  o

  https://host:port/uri

• URI: Uniform Resource Identifier, o Identificador de Recurso Uniforme. Lo que es la parte de la ruta dentro de la URL, como se había visto más arriba. La URI puede contener, a su vez, particiones, que se indicarán con la barra inclinada (/) y zona de consulta, que comenzará con el signo de interrogación (?) y tendrá pares de clave valor separados entre sí por el signo de igualdad (=) y entre cada par por el símbolo del ampersand (&):

  /miruta/mifichero.ext?clave1=valor1&clave2=valor2

• Host: del inglés máquina. Se refiere al nombre del servidor donde se alberga la URI que se solicita. El nombre debe de ser un nombre que se pueda resolver vía DNS, pudiendo ser un conjunto de letras, símbolos (válidos: guión (-) y subrayado (_)) y números: www.midominio.com
• Port: o puerto. Es el número en el que escucha el servidor web. No hace falta indicarlo explícitamente, a menos que sea diferente del puerto estándar, que es el 80. Se indica en formato decimal.
• Servidor web: es el programa que se mantiene a la escucha para atender las peticiones de los navegadores, a modo de servir las páginas web. También puede ejecutar códigos para generar páginas, imágenes y otros contenidos para cada petición. Hay servidores de pago y gratuitos, y libres, algunos ejemplos de los más usados: Apache, Cherokee y Microsoft IIS.
• Navegador web: es una aplicación de escritorio que permite, dando una URL, visualizar una página web, escrita en lenguaje HTML. Los navegadores web tienen la posibilidad de emplear plugins de forma que puedan: reproducir vídeos, sistemas interactivos Java, Flash, Silverlight, …; reproducir audio, usar hojas de estilo, o código JavaScript…; algunos ejemplos de navegadores web más usados son: Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, Opera y Safari.

Peticiones: modo Cliente/Servidor

El sistema web se diseño para ser de modo cliente/servidor. Eso quiere decir que hay un elemento activo, en este caso el navegador web, que haría las veces de cliente, y un elemento pasivo, en este caso el servidor web, que haría las veces de servidor.

La dinámica siempre es la misma, el cliente realiza una conexión a través de la red para solicitar una página web, mediante una URL, y el servidor responde a esta URL con un mensaje en el que puede indicarle el contenido de lo solicitado (200 OK), que no encuentra la página (404 Not Found), que no tiene acceso a ese recurso (403 Forbidden), que necesite autenticarse antes (401 Authorization Required), que el recurso solicitado está en otra ubicación (302 Redirect), etc.

Formato de las Peticiones

Las peticiones pueden ser de varios tipos, pero básicamente, se nombran, para navegadores, dos: GET y POST. Cuando un cliente realiza una petición de URL de forma normal, esta se realiza siempre vía GET. En cambio, cuando se realiza mediante el envío de un formulario, presionando en el botón de tipo submit de una página web, este puede realizarse mediante POST (a menos que se explicite, en el propio código HTML, que se hará mediante GET u otro método que soporte el navegador web).

Por tanto, una petición se envía en formato texto, como sigue:

GET / HTTP/1.1
Host: www.google.es
User-Agent: Mozilla Firefox
Connection: close

La petición se divide en:

• Primera línea: es en la que se especifica el método de solicitud, seguida por la URI, y por último el protocolo usado (normalmente HTTP/1.1).
• Cabeceras: es el espacio destinado a dar información al servidor sobre la solicitud. Las cabeceras son frases cortas de letras y guiones que terminan con los dos puntos (:), para dar lugar al valor de la clave. El host se indica siempre para informar al servidor del dominio al que queremos solicitar la página, así como el user-agent, en el que le informamos desde qué navegador (o tipo de navegador) estamos realizando la petición. En este enlace se puede ver cómo se construyen los user-agent para cada navegador, y el porqué son tan largos.
• Cuerpo del mensaje: una petición de tipo GET no suele tener cuerpo de mensaje, por lo que no se especifica una cabecera de tipo Content-lenght, que indicaría que hay cuerpo de mensaje, y el tamaño del mismo. También se puede indicar que el contenido irá por trozos. Entre la línea de cabeceras y el cuerpo, se deja siempre una línea en blanco.

Formato de la respuesta

La respuesta que emite el servidor viene formada por una serie de líneas de texto en las que se indica el protocolo en el que se responde (normalmente HTTP/1.1), seguido de tres dígitos, el código de retorno, y un texto informativo sobre el retorno.

Al igual que en el caso de la solicitud, se incluyen cabeceras, y el cuerpo de la respuesta, que está separado de las cabeceras por una línea en blanco. Un ejemplo:

HTTP/1.1 200 OK
Date: Tue, 16 Nov 2010 02:30:00 GMT
Server: Apache/2.2.9 (Debian)
Content-Length: 4
Content-Type: text/plain

hola

En este caso, como se puede ver, el servidor también responde informando de su huella (la cabecera Server), donde especifica el tipo de servidor que es. En este caso, la respuesta tiene cuerpo de mensaje, de 4 bytes y de tipo texto plano (en formato MIME: text/plain).

Tipos de Respuestas

Las respuestas que puede dar un servidor web pueden ser:

Para más información sobre los códigos se puede ver el anexo de códigos HTTP de la wikipedia.

Cookies

Debido a que el sistema web es lo que se conoce como stateless, es decir, que cada petición se realiza independientemente de las anteriores y siguientes, por lo que, en muchos sitios, para poder establecer una sesión o identificar a un usuario para poder usar sus preferencias preguardadas, o información sobre su navegación en nuestro sitio, se usan las polémicas cookies.

Una cookie es un dato que indica el servidor para el cliente, que debe de almacenarlo y enviarlo cada vez, hasta que se cumpla el tiempo límite en el que expira. Por ejemplo:

HTTP/1.1 200 OK
...
Set-Cookie: name=value; expire=Tue, 16-Nov-2010 15:00:00 GMT; path=/; domain=www.google.es
...

Las cookies tienen 4 partes,

• la primera se establece el par clave-valor, esto quiere decir que se establece, como si de una variable se tratase, el nombre de la cookie, con el valor que contendrá,
• la segunda es la expiración de la cookie, o caducidad. Pasada esa fecha, la cookie debe de ser destruida del navegador web para no volver a ser usada,
• la ruta, en la tercera posición, es la URI base de la que cuelga la cookie. Para tenerla como referencia en su uso, y solo enviar la cookie cuando la ruta base se cumpla en la URI solicitada.
• por último, se especifica el dominio para el que se configura la cookie. Este debe de ser igual a la cabecera host enviado en la petición, a menos que haya cambiado de dominio.

Una vez el servidor ha enviado esta información al navegador web, el navegador almacena (o solicita antes si se desea almacenar) dicha información como cookie, para reenviarla cada vez que se visite el dominio con la misma URI base. El navegador realiza las peticiones de la siguiente forma:

GET / HTTP/1.1
Host: www.google.es
Cookie: name=value
...

El tema de las cookies y la privacidad ha sido muy discutido y hay legislaciones (la de EEUU y Europa) que han incluido artículos para su regulación, ya que puede ser empleado como un medio para minar nuestra privacidad. Esto se puede leer de forma más amplia en este enlace.

Conclusiones

El protocolo HTTP, en el que se basa el sistema web, es el más usado en internet, junto con el correo electrónico. Con este artículo se pretende dar una visión un poco más a bajo nivel sobre cómo funciona dicho sistema, y se espera ampliar en un futuro con más artículos referentes a otros aspectos que conforman y completan al propio protocolo.

Tener este tipo de URLs, o URIs en nuestro dominio, se puede hacer mediante la creación de directorios y especificando los ficheros dentro de los mismos que tengan los nombres (sin extensión) que queremos que se visualicen en la barra del navegador… pero no es nada útil y es complejo, sobre todo cuando se usan entornos como WordPress o similares, donde el contenido de la base de datos dicta lo que aparece en la página, y es totalmente dinámico.

La solución que se puede emplear: rewrite. En Apache, a través del módulo mod_rewrite, se pueden crear reglas de redireccionado de modo que una URL que es:

http://midominio.com/?p=129&a=crea-usuario

Se puede convertir en:

http://midominio.com/crea-usuario/129

En el caso concreto, tan solo bastaría con agregar un bloque de configuración como el siguiente:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/(.+)/([0-9]+)$    /index.php?p=$2&a=$1

Para más información vea la documentación oficial de Apache.

En un artículo sobre el tema, la alta disponibilidad, se decía que la disponibilidad de un servicio, servido únicamente por una máquina, normalmente es de un 90%, con lo que, a lo largo de un año (365 días) el servicio se ha mantenido en funcionamiento un máximo del 90%, aproximadamente, y ha tenido un tiempo de inactividad del 10% (más o menos unos 36 días).

Con sistemas de alta disponibilidad, es decir, teniendo más de una máquina siriviendo un servicio, la proporción se incrementa, pero siempre a razón de nueves. Es decir, con dos máquinas, tenemos una disponibilidad del 99%, con tres máquinas tenemos un 99,9%, con cuatro un 99,99% y así sucesivamente.

Como nota curiosa, hace poco leí que los sistemas desarrollados sobre Erlang/OTP tienen una alta disponibilidad de nueve nueves (99,9999999%), lo cual me parece algo increíble, pero totalmente cierto, ya que he probado la infraestructura y realmente es muy estable.

Mongrel y Thin no son multi-hilo

Fue algo que nos sorprendió mucho, una aplicación servidora secuencial, que atiende las peticiones una a una y, en caso de que una petición se tarde un par de segundos (que las teníamos :-S ), el sistema se queda trabado durante todo ese tiempo.

Las soluciones posibles eran dos:

• Phusion Passenger, también conocido como mod_rails, es un módulo para Apache que mantiene tantos hilos como peticiones se vayan gestionando, siempre con unos límites máximos y mínimos, tal y como apache suele hacerlo.
• Ngnix + Thin, esta solución fue un poco más artesana, por decirlo de alguna forma, ya que consistía en configurar este servidor web como proxy inverso, para hacer el balanceo de peticiones entre todos los hilos de thin que se quieran cargar en el sistema. Descartamos en este punto a mongrel por comentarios que había leído en otros blogs.

Bien, por correr lo más posible, lanzamos tantos hilos como nos fue posible en la máquina que dedicamos al proyecto y, nos complació ver que podía aguantar hasta 40 hilos, sin que sus CPUs lo notasen apenas. Con lo que conseguimos un pool de 40 puertos dedicados a atender peticiones HTTP.

En otra máquina se configuró un proxy inverso. En el escenario de pruebas usamos nginx, aunque el tenerlo en la misma máquina y hacer pruebas masivas, nos dio como resultado que una cantidad importante de peticiones se perdían o transformaban en respuestas de tipo 500 por parte de nginx. Optamos entonces por un balanceador que tiene la compañía vía hardware, muy rápido y, a día de hoy el sistema web tira tan rápido y casi mejor que el que tenemos montado en PHP

En el próximo artículo comentaré las configuraciones, arquitecturas y demás seguidas, sobre todo a nivel de nginx y thin, que es lo que realmente interesa.

Conceptos

En principio, vamos a definir algunos términos que usaremos de forma natural en el resto del artículo, para adentrar lo que son los términos de funcionamiento del email:

• MUA: (Mail User Agent, Agente de Usuario de Correo), es el sistema que se encarga de recibir y enviar emails usando los protocolos STMP (para el envío) y POP3 o IMAP (para la recepción). Ejemplos de MUA son evolution, kmail, sylpheed o incluso squirrelmail (los webmails).
• MTA: (Mail Transfer Agent, Agente de Transferencia de Correo), es el sistema que se encarga de tomar el email de un MUA o de otro MTA y entregarlo a otro MTA o a un MDA, en caso de que el email pertenezca al dominio propio del MTA. Ejemplos de MTA son postfix, qmail, exim, cyrus y courier.
• MDA: (Mail Delivery Agent, Agente de Entrega de Correo), es el sistema que se encarga de la recpeción del email por parte de un MTA, y lo almacena de la forma que tenga configurada. Los MDA pueden almacenar en disco, base de datos o llamar a otro programa para hacer el procesado de emails (p.ej: listas de correo, sistemas de control de incidencias, etc.). Ejemplos de MDA son procmail, maildrop… cyrus y courier implementan también sus propios MDA.
• MAA: (Mail Access Agent, Agente de Acceso de Correo), es el sistema que se encarga del acceso al correo almacenado. Sería como la oficina de correos, y por ello su protocolo más usado es POP3 (Post-Office Protocol version 3). Se encarga de hacer accesible lo buzones a equipos remotos. Ejemplos de MAA son dovecot, uw, qpopper… cyrus y courier implementan también sus propios MAA.

Funcionamiento

Un ejemplo básico, desde el punto de vista de un usuario sería:

• Un usuario abre su MUA (evolution, por ejemplo), escribe un email desde su buzón yo@miemail.com a un amigo, que tiene la dirección de correo el@suemail.com.
• Su programa MUA se conecta con el MTA que está en el dominio miemail.com, este MTA comprueba que el remitente es suyo, pero que el destinatario es de otro dominio, por lo que realiza un relay del email al MTA del dominio suemail.com.
• El MTA del dominio suemail.com ve que el destinatario es propio, por lo que, libera el email a su MDA.
• El MDA comprueba el usuario a través de los alias y las reglas configuradas en el equipo y libera el email en el soporte, buzón y carpeta que tiene configurados.
• El usuario el se conecta a un webmail, que hace de MUA para leer sus emails.
• Los MUA, para leer emails, ya sean aplicaciones en el equipo o webmails, se conectan a MAA para leer los emails vía POP3 o IMAP, y estos MAA acceden a los datos que han liberado los MDA, por lo que el puede leer el email de yo.

Como dato a tener en cuenta, podemos ver las cabeceras del mensaje completas y aparecerán unas cabeceras redundantes que tienen por nombre Received. Estas cabeceras se agregan a cada paso por un MUA, MTA y MDA.

Spam

Por la forma de funcionamiento del protocolo SMTP (MTA), los antiguos programas que solo comprobaban el remitente y el destinatario, se veían en el problema de que esos datos se pueden falsear sin problemas, con lo que la veracidad de los mismos queda entredicho.

Para solventar estos problemas, se han desarrollado varios sistemas, antispam y de seguridad de conexión, que aseguran, en la medida de lo posible, que estos problemas no sucedan, pero aún así, hay una guerra entre desarrolladores de sistemas de correo para realizar sistemas cada vez más seguros, y spammers para el desarrollo de sistemas que salten esta seguridad.

Por ello, el uso de filtros es cada vez más común en los MTA, MDA e incluso los MUA.

La sincronización horaria es completamente posible de llevar, simplemente, instalando un servidor de hora NTP dentro de nuestra red, para que nos haga de servidor de sincronización.

En España, generalmente, se suele usar hora.rediris.es como servidor de hora, puesto que es un sistema formado por varios servidores, algunos de ellos con el uso de relojes GPS.

Muchos sistemas ya tienen el servidor ntpd instalado. En otros habrá que hacer la instalación, ya sea del paquete con nombre: ntp, ntp-server, ntpd…

El archivo de configuración, normalmente: /etc/ntp.conf; debería de tener un contenido parecido a este:

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
 
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
 
server hora.rediris.es
 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
 
restrict 127.0.0.1
restrict ::1
 
restrict 192.168.123.0  mask  255.255.255.0 notrust
 
broadcast 192.168.123.255
disable auth
broadcastclient

Con esto, el servidor de hora recién instalado, servirá como repetidor para los equipos de la red interna. En caso de tener un solo equipo, en ese caso es mejor tomar el archivo de /etc/ntp.conf y modificarlo levemente para hacer que el sistema fucnione, y nada más.

Espero que os sirva de ayuda.

En lo que llevamos de año, se han sucedido grandes vulnerabilidades de seguridad. La primera ha afectado la protocolo DNS, la segunda al protocolo BGP y ha habido otra vulnerabilidad sobre SSL que ha afectado solo a las distribuciones Debian y derivadas del mismo.

Esta última vulnerabilidad afecta al TCP/IP, aunque matizan los expertos que, de momento, solo es supuesta y que no solo afecta a IP, sino al conjunto TCP/IP. De momento, hasta que sea publicada la vulnerabilidad de forma específica por la compañía sueca, estamos ante, incluso, un posible FUD.

De todas formas, Internet, la concepción de sus protocolos más usados (como DNS y SMTP), no estaban pensandos para ser seguros, sino prácticos, puesto que Internet era una red a la que pocos tenían acceso. Hoy en día, el enfoque ha cambiado, pero los protocolos siguen siendo los mismos y, quizás, el problema haya sido la forma de parcheo que se ha realizado sobre los protocolos existentes, en lugar de optar por desarrollar mejores protocolos orientados a las necesidades actuales.

¿Estamos ante una necesidad de cambio en los protocolos de Internet?, ¿se nos hunde Internet?, no lo creo… pero llegan momentos difíciles y quizás vientos de cambio

Esto viene determinado porque el navegador se ha convertido en todo un sistema operativo en el que se ejecutan aplciaciones que se cargan de forma remota. Lo que ya habían visualizado hace años Sun con el uso de sus paquetes en forma de nombre de dominio y otros… pero de una forma mucho más transparente.

En el navegador web, solo hay que poner una dirección web (URL) y con ello se puede acceder a un software con el que se interactúa para: leer el correo (Gmail, Yahoo!, Hotmail…), tener la agenda de contactos (en los mismos webmails), escribir diarios (blogs como Blogger), organizar las fotos e imágenes (fotoblogs o galerías tipo Flickr)… e incluso tener acceso a bancos, tiendas, el Estado…

Microsoft ultima su Office Online, junto con aplicaciones de tipo Office que ya tenía en uso Google mediante Google Docs, y con ello, con todo en Internet, ¿qué más da ejecutar un Windows, GNU/Linux, MacOS X…?