Blog de Javi

Hoy vamos a instalar un servidor secundario/failover del servicio DHCP de nuestra red Linux. Como todos sabemos, una simple caida del servidor DHCP puede dejar a toda la red sin funcionar ya que nuestros clientes (si usan el servicio de DHCP), no podran obtener una dirección IP válida y seria imposible que les funcionase algo. Para evitar posibles caidas de este servicio, vamos a instalar un segundo servidor failover.

Suponemos que ya tenemos el servidor principal funcionando en la subred 192.168.200.0/24 como se puede ver en el ejemplo. Tan solo tenemos poner las primeras lineas que estan entre los corchetes de failover, poniendo en address la IP del servidor principal, y en peer adress la IP del servidor failover. Aqui lo vemos:

#
# /etc/dhcpd.conf for primary DHCP server
#
 
authoritative;
ddns-update-style none;
 
failover peer "dhcp-failover" {
   primary; # declare this to be the primary server
   address 192.168.200.2;
   port 647;
   peer address 192.168.200.3;
   peer port 647;
   max-response-delay 30;
   max-unacked-updates 10;
   load balance max seconds 3;
   mclt 1800;
   split 128;
   }
 
subnet 192.168.200.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.200.255;
   option routers 192.168.200.1;
   option domain-name-servers 192.168.200.1;
   pool {
      failover peer "dhcp-failover";
      max-lease-time 1800; # 30 minutes
      range 192.168.200.100 192.168.200.254;
      }
   }

En el servidor secundario quedaria algo asi como lo siguiente. Fijaros que en address pone la IP del servidor secundario, y en peer address la IP del servidor principal:

#
# /etc/dhcpd.conf for secondary DHCP server
#
 
authoritative;
ddns-update-style none;
 
failover peer "dhcp-failover" {
   secondary; # declare this to be the secondary server
   address 192.168.200.3;
   port 647;
   peer address 192.168.200.2;
   peer port 647;
   max-response-delay 30;
   max-unacked-updates 10;
   load balance max seconds 3;
   }
 
subnet 192.168.200.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.200.255;
   option routers 192.168.200.1;
   option domain-name-servers 192.168.200.1;
   pool {
      failover peer "dhcp-failover";
      max-lease-time 1800; # 30 minutes
      range 192.168.200.100 192.168.200.254;
      }
   }

Lo respecto a la declaracion de las subredes, es exactamente igual en un servidor que en otro, por lo que tenemos que tener cuidado al hacer un cambio en un servidor, sea exactamente igual que en otro. Para solucionar esto podemos sacar todo el bloque subnet a un archivo y hacer un include de ese archivo, asi sincronizando el archivo de la subred entre los servidores no hay posible error.

De aquí a un tiempo he visto algunos scripts bastante simples que, sorprendentemente, hacen bastante daño a malas configuraciones de sitios con wordpress. El sistema de DoS (Denial of Service, Denegación de Servicio) que se usa para el ataque es de tipo flood (inundación) enviando un número muy alto de peticiones. Por ejemplo: Under Security.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.

Fuente: Bosque Viejo

Resumiendo mucho el funcionamiento de los VirtualHost en Apache, se puede decir que el cliente (nuestro navegador) envía al servidor el nombre del dominio al que deseamos acceder y Apache lo busca en sus configuraciones para entregarte la web. De esta forma en un solo servidor podemos tener alojados múltiples páginas web, cada una con su VirtualHost.

GET /blog/ HTTP/1.1
Host: javirodriguez.com.es
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.0.6) Gecko/2009020911 Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: es,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Pero la cosa cambia si las webs deben ser transmitidas mediante HTTPS, esto es, estableciendo una conexión SSL. Gracias a esta tecnología es posible que todo el tráfico entre el servidor y nuestro navegador vaya cifrado y esta es la raíz del problema. Al tener todos los datos cifrados, el servidor no puede saber que dominio está pidiendo el navegador, por lo que los VirtualHost en base a nombres (dominios) pierden utilidad. Para paliar este problema, se ponían múltiples IPs en el servidor y se asignaba cada IP a un VirtualHost. De esta forma, cada web HTTPS tenia como destino una IP distinta y así el servidor era capaz de darte la web que estabas buscando. Esto es, se pasaba de tener VirtualHost por nombre a tenerlos por IP. Si tenías dos páginas web esto no era problema, pero si tenías 200… acelerarías la implantación de IPV6 y eso no es bueno 😉

Para solucionar este problema se publicó en 2006 el RFC 4366. En resumen, TLS pasaba a tener extensiones a nivel cliente y servidor. Una de las cuales permite que el cliente en el establecimiento de la conexión (antes de comenzar el cifrado) pueda indicar el dominio al que desea acceder. La que nos hace la magia es SNI. Para que esto funcione es necesario cumplir una serie de requisitos:

• OpenSSL 0.9.8f o posterior con extensiones TLS (enable-tlsext)
• Apache compilado con dicho OpenSSL
• Navegadores Mozilla Firefox 2.0, Opera 8.0 Internet Explorer 7.0, Google Chome, Safari 3.2.1

Para activar esta extensión añadimos la siguiente línea a httpd.conf:

SSLStrictSNIVHostCheck on

Una vez hecho configuraríamos nuestros VirtualHost SSL como si fuesen los de toda la vida (sin SSL).

Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
        ServerName test1.javirodriguez.com.es
        ServerAlias test1.javirodriguez.com.es
        DocumentRoot /var/www/test1
        Options FollowSymLinks
        <Directory /var/www/test1>
        AllowOverride All
        </Directory>
        ErrorLog /var/log/apache2/test1error.log
        CustomLog /var/log/apache2/test1access.log combined env=!client-ip-request
        SSLEngine on
        SSLCertificateFile /etc/ssl/test.pem
        SSLCertificateKeyFile /etc/ssl/test.key
</VirtualHost>
<VirtualHost *:443>
        ServerName test2.javirodriguez.com.es
        ServerAlias test2.javirodriguez.com.es
        DocumentRoot /var/www/test2
        Options FollowSymLinks
        <Directory /var/www/test2>
        AllowOverride All
        </Directory>
        ErrorLog /var/log/apache2/test2error.log
        CustomLog /var/log/apache2/test2access.log combined env=!client-ip-request
        SSLEngine on
        SSLCertificateFile /etc/ssl/test.pem
        SSLCertificateKeyFile /etc/ssl/test.key
</VirtualHost>

Si vemos el siguiente error en los logs de Apache es que nuestro navegador no es compatible:

[error] No hostname was provided via SNI for a name based virtual host

Y listo, ya puedes tener múltiples VirtualHost con SSL en una única IP 🙂

Fuente: Miguel Angel Nieto

Es algo bastante simple, pero necesario en ciertas ocasiones, cuando debemos actualizar la edición de nuestro servidor, sea de Windows Server 2008 Standard a Windows Server 2008 Enterprise o Windows Server 2008 Datacenter, o de Windows Server 2008 Enterprise a Windows Server 2008 Datacenter. Normalmente por qué hemos ampliado la memoria RAM y nuestro Sistema operativo no soporta tanta, o por qué necesitamos instalar una característica o función que no está en la edición actual de nuestro servidor.

En principio muestro una tabla, una comparativa entre las diferentes ediciones que os facilitará el porqué escoger una edición u otra en este link de Microsoft: http://www.microsoft.com/windowsserver2008/en/us/compare-features.aspx. Además tendremos que mirar la HLC de Microsoft para comprobar que el hardware de nuestro servidor está soportado o el software instalado.

Es algo sencillo, debemos introducir el CD/DVD de Windows Server 2008 con el servidor ya arrancado y con todas las actualizaciones posibles instaladas, para evitar durante el proceso de instalación que debamos instalarlas. Pulsamos en “Instalar ahora” en el autorun.

Como ya tendremos nuestro servidor ‘up to date’ 😉 omitimos el proceso para actualizar el servidor tras la instalación o posteriormente lo haremos, pulsamos en “No obtener las actualizaciones más recientespara la instalación. Seleccionamos la edición a la que queremos actualizar, en mi caso subiré a una Enterprise & “Siguiente”, Aceptamos el acuerdo de licencia marcando “Acepto los términos de licencia” & “Siguiente”, y pulsamos sobre “Actualización”, para actualizar de forma inmediata.

Primero realizará un proceso de compatibilidada y esperamos unos cuantos minutos mientras actualiza, se reiniciará varias veces durante el proceso de actualización y listo, una vez reiniciado, ya podremos comprobar que nuestro servidor tiene la Edición de Windows seleccionada!

La conexión parece estar bien. Las luces del módem y del router parpadean saludablemente, y nada ha sido cambiado en la configuración respecto al día anterior. Sin embargo, al querer abrir una página que sabes que funciona perfectamente, recibes un error (incluso a veces un 404) a cambio. Antes de desechar tu red y rehacerla desde cero, deberías verificar que los servidores DNS de tu proveedor no te estén dando problemas.

¿A quién no le ha sucedido? Todo aparenta estar en orden, las conexiones físicas intactas, la configuración de Windows reluciente, y sin embargo, cada página que visitas te saluda con un temerario error de servidor. Llamas a tu proveedor de Internet, sólo para recibir como respuesta que todo funciona perfectamente, y que el problema está de tu lado. Pero hay veces en que dicen eso cuando en realidad están corriendo de aquí para allá, tratando de resucitar a sus servidores DNS, porque se cayeron de forma apocalíptica.

La importancia de los servidores DNS, es crítica. Si no fuera por ellos, deberíamos escribir cada número IP de cada página de manera manual para poder visitarla, y algo tan sencillo como www.google.com se convertiría en 72.14.207.99. En otras palabras, una pesadilla.

Entonces, ¿cómo puedes comprobar que el servidor DNS de tu proveedor te está haciendo la vida imposible? Es sencillo: Usando otro servidor DNS. Redirigir tus solicitudes de nombres a otro servidor puede sacarte del apuro en ese mal momento cuando a los servidores DNS de tu proveedor se les ocurre la mala idea de caerse. También puedes probar otro servidor DNS con el objetivo de obtener una resolución de nombres más rápida, lo que aceleraría la navegación. Sin embargo, si eres de llevar a cabo tareas muy importantes en Internet, es probable que apuntes más a la estabilidad que al rendimiento. En casos muy aislados, existe la posibilidad de que la navegación sea un poco más lenta al abrir páginas, pero al menos sabes que no te abandonará cuando estés caminando sobre las brazas.

El primer paso es determinar el estado de los servidores DNS de tu proveedor, ya sea llamando por teléfono al soporte técnico, o simplemente haciendo un ping hacia el servidor. Para hacer esto, debes abrir una consola de sistema, y usar el comando ping, seguido del número del servidor. Por ejemplo, para Telefónica de España, uno de los números de servidor DNS más conocidos es 80.58.61.250. Si el comando ping arroja un error, entonces puedes probar a buscar otros servidores del mismo proveedor, pero si el error persiste, hay que tomar medidas.

El segundo paso es conseguir un número alternativo de un servidor DNS público. Hay muchos disponibles en la red, y que además de ser gratis, ofrecen un servicio muy bueno. Para nuestro ejemplo, usaremos unos de los tantos servidores DNS que tiene Telefónica de España.

Si estás usando Windows Vista, debes ir al Panel de Control, luego a Centro de redes y recursos compartidos, y finalmente a Administrar Conexiones de red. Haz un clic con el botón secundario sobre la conexión de red que estés usando (sea una placa de red física, o una inalámbrica), y escoge Propiedades. Resalta la opción Protocolo de Internet versión 4, y haz clic en el botón Propiedades. Haz clic en Usar las siguientes direcciones de servidor DNS, y escribe 80.58.0.33 para el servidor primario, y 80.58.32.97 para el secundario. Acepta todos los cambios, y reinicia Windows Vista para aplicar la configuración.

Para los usuarios de Windows XP, los pasos a seguir son muy similares, sólo que la manera de llegar allí es diferente. Ve al Panel de Control, y luego haz un doble clic en Conexiones de Red. Luego, un clic con el botón secundario sobre la conexión de red, y un clic en Propiedades. El resto es igual que en el ejemplo de Windows Vista, con la única diferencia que el nombre es simplemente Protocolo de Internet. Coloca los mismos números en los servidores primario y secundario, y acepta los cambios. Windows XP te pedirá reiniciar para poder operar con los nuevos DNS.

Esta forma de configurar los DNS hace que sean usados en cada ordenador, y no de manera global. Si tienes un router en tu red, lo más efectivo será que configures estos DNS en el router. Entra a su configuración y busca la sección relacionada con los servidores DNS (usualmente ubicado bajo opciones de DHCP). Escribe los números, confirma los cambios, y reinicia el router para que tomen efecto. No podemos decirte con exactitud cómo debes proceder con tu router, debido a la gran cantidad de modelos existentes, pero lo cierto es que no debería ser muy complicado. Consulta el manual de tu router si tienes dudas.

Por último, deberías descartar cualquier problema que puedas tener en el caché DNS de Windows, abriendo una consola de sistema, y usando el comando ipconfig /flushdns para purgar cualquier rastro de caché existente.

Con estas cosas combinadas, podrás sortear sin problemas la pesadilla de quedarte sin servidores DNS, al menos hasta que tu proveedor pueda volver a colocarlos en línea. Puedes incluso reemplazar los DNS de tu proveedor con los de OpenDNS de manera permanente, si las fallas de tu proveedor son demasiado frecuentes. Recuerda que esto sólo afecta la resolución de los nombres de páginas web, y no debería afectar a otras aplicaciones como mensajería (MSN) y descargas p2p (BT, Emule). ¡Buena suerte!