Tener un servidor web o de correo doméstico es para cualquier aficionado a la informatica un pequeño lujo. Es una verdadera gozada poder tener un espacio propio para almacenar lo que te dé la gana sin tener que preocuparse de restricciones de espacio o de tráfico típicas que suelen tener muchos hostings. Además, administrar tu propio hosting te obliga a aprender muchísimas cosas que puedes luego aplicar a ámbitos profesionales.

Y por supuesto, cuando ese servidor es directamente para un uso profesional, es una verdadera tranquilidad saber que no tienes que preocuparte de restricciones de ningún tipo y que en cuanto a costes lo único que debe preocuparte es el consumo energético y tener un dominio comprado.

Y que lo digas, pero yo estoy intentando montar el mío y no consigo que funcione. Esto es una locura. Prefiero gastarme los ahorros en un hosting de verdad y no tener que pelearme con esto. Me da que esto no va a funcionar nunca y...

No desesperes Usuario Anónimo. Evidentemente no todo es un camino de rosas cuando te animas a un proyecto de este tipo, pero cuando hay algún problema con un servidor web suele ser sencillo saber dónde está la causa. Un servidor Web que no funciona es como un enfermo. Tienes que fijarte mucho en sus síntomas, porque te darán muchas pistas de dónde puedes tener el fallo. En este artículo veremos como interpretar esos síntomas en un servidor web LAMP para poder tener pistas de cómo curar al enfermo de forma rápida y efectiva. Ojo: la cantidad de problemas posibles que pueden causar una web caída es enorme, así que vamos a centrarnos sólo en cómo saber dónde está el problema y veremos unas cuantas soluciones.

1. Problemas que no tienen que ver con nuestro servidor.

Antes de empezar a pelearnos con el servidor, deberíamos hacer una comprobación básica: saber si está funcionando correctamente aunque no podamos acceder a él desde internet.

¿Lo qué? Pero... a ver. Si no puedo acceder a él desde internet es que el servidor no funciona ¿No es así?

Pues no exactamente. Puede que el servidor esté ejecutándose, pero que por algún motivo desde internet sea posible acceder a él. ¿Cómo podemos saber si ese es el caso? Una forma muy sencilla es escribir la dirección IP del servidor en un navegador web situado en su misma red local. Si escribiendo la IP privada del servidor nos sale alguna página, aunque no sea la que esperamos, podemos empezar a descartar cosas.

Página-por-ip-privada
Esta es la página de bienvenida por defecto de Apache en Ubuntu. Fijaos que accedo a ella desde una ip privada.

Lo que sabemos si se nos presenta este caso es que el servidor Web Apache está funcionando. Eso seguro. Puede ser que el servidor web esté mal configurado, pero al menos sabemos que está encendido. Otra prueba básica es intentar acceder a la IP pública de nuestro servidor (la ip de nuestro router) y ver si nos presenta el mismo resultado o algún otro.

Pues desde la ip privada puedo acceder, pero no desde la pública. No lo entiendo. Esto no tiene sentido.

Pues ese es el mejor de los escenarios, porque si accediendo por la ip pública obtenemos una página de error (la web no carga) y el servidor web funciona cuando apuntamos hacia la ip interna, entonces tenemos el problema localizado. Nuestra conexión a internet está fallando de algún modo. Lo más probable es que no tengamos los puertos correctos mapeados hacia nuestro servidor web. Normalmente deberían ser los puertos 80 y el 443, pero en caso de tener un servidor de correo podríamos tener muchos más (25, 587, 993, 110, etc..). Es un problema en el que a veces no pensamos pero es mucho más habitual de lo que pueda parecer a primera vista.

¡Pero si antes funcionaba! ¿Cómo puede pasarme esto si no he tocado nada?

Que te ocurra es increíblemente sencillo. Puede que hayas cambiado de router y te hayas olvidado de mapear de nuevo los puertos. Tal vez algún problema con el router (apagón, mal contacto…) haya hecho que volviera automáticamente a la configuración de fábrica. O incluso algo muy habitual: que tu operadora de internet haya reseteado los valores por los de fábrica sin que te hubieras dado cuenta. En todo caso si funciona desde la red local y no funciona desde internet, el problema a priori apunta al router.

En principio, si al intentar acceder a nuestro servidor web apuntando a la ip pública obtenéis algo cómo esto, entonces podemos descartar problemas de configuración de puertos.

Página-por-ip-pública
Fijaos que es la misma página que antes, pero estamos accediendo a ella desde una ip pública.

2. No puedo acceder a mi página desde la red local pero sí desde otra conexión a internet.

¿Lo qué? A ver... eso no me lo creo. Si puedes acceder a tu propia web desde otra conexión a internet eso significa que el servidor web lo tienes funcionando y deberías poder verla entonces desde dentro de tu red.

Pues fíjate que se me ha dado el caso. Una vez tuve un servidor de correo al que se podía acceder desde internet (desde otra red local) sin problema, pero desde la red interna la gente no podía acceder a él. Incluso si intentabas hacer un ping hacia la ip pública, el ping no respondía. Y aquí evidentemente el problema ya es de servidor. Dependiendo de cómo esté configurado el origen puede ser muy distinto. Yo miraría tres puntos clave:

  • Configuración del servidor web.
  • Configuración de proxies si los hubiera
  • IP’s baneadas en el Fail2Ban si lo tienes implementado en el servidor.

Este último punto es el que originó los problemas en mi caso. Fail2Ban es un programa que cuando detecta un ataque de algún tipo hacia nuestro servidor, bloquea las peticiones de la IP atacante. En nuestro caso había un ordenador en la red local que se intentaba logar al servidor de correo con una contraseña incorrecta. Eso lo detectaba el fail2ban como un ataque de fuerza bruta y baneaba la ip del atacante, pero como el supuesto atacante accedía a través del router de la empresa (la conexión salía hacia internet, pero volvía a entrar en la red privada) al final toda la red quedaba baneada en el servidor por culpa de ese usuario. El Fail2Ban estaba baneando la ip pública de la conexión, que era compartida por un montón de equipos.

Así que siempre que se pueda acceder a nuestro servidor desde un móvil con el wifi desactivado pero no se pueda acceder desde la propia red, pensad primero que el problema pueda estar en algún bloqueo en el propio servidor.

3) Accedo a todo correctamente desde otra conexión a internet y desde dentro de mi red puedo acceder al apache, pero no a la página que quiero.

¿Qué nos quieres decir con eso? ¿Que funciona... pero no funciona?

Pues algo así. Un problema similar también lo he vivido en persona. El problema era que podía acceder al servidor tanto mediante la IP pública como mediante la IP privada, pero al intentar acceder a uno de los dominios alojados en el servidor obtenía un error. ¿Qué nos está diciendo esto? Tal y cómo vimos en el punto 1, debemos descartar problemas de puertos, porque si no no podríamos acceder ni mediante la IP. Sin embargo podemos acceder a la ip del servidor, por lo que no nos está baneando el Fail2Ban. Por tanto en este caso el problema podría venir de dos sitios:

  • De la configuración del servidor (te has colado al editar el archivo de configuración en «Sites-available»).
  • De la configuración de tu router o tus DNS
¿Cómo que de la configuración de mis DNS? Si yo uso los DNS de Google, ya sabes... 8.8.8.8. Los que usa todo el mundo.

Ya, ya… pero a veces hay empresas que usan servidores de DNS propios. Tal vez tengan un Windows Server ejerciendo labores de servidor de DNS. O puede que algún software libre haciendo estas labores, como un NXFilter. En mi empresa el problema vino por ahí precisamente. Si apuntabas hacia la ip pública, podías ver la página de prueba de apache, pero si intentabas entrar en un dominio configurado en el servidor no podías acceder.

Lo que ocurría era lo siguiente: el navegador de internet hacía la petición de la página web al servidor de DNS. El servidor de dns resolvía que había que coger la página en la misma IP pública desde la que estábamos navegando… pero el router no era capaz de enrutar la conexión de nuevo hacia dentro de nuestra red. Si os pasa esto, hay dos formas de abordar el problema:

  • Configurando correctamente el router (es la mejor solución, aunque a veces es algo complicada)
  • Engañando a nuestro servidor de DNS, diciendo que resuelva esa DNS en concreto en la ip privada del servidor Apache, en lugar de la IP pública.
Oye... la segunda opción... ¿No es un poco cutre-salchichera?

Para nada. No es un poco cutre, sinó super-cutre-salchichera. Pero a la vez es altamente efectiva. Los equipos de la red local no se van a enterar de la «ñapa» y nosotros volveremos a tener la página funcionando en los equipos de nuestra red. En los de fuera ya funcionaba anteriormente, así que dejaría el problema completamente resuelto.

¿Y si no tengo ningún servidor de DNS configurado en mi red local?

Pues la solución sencilla si son pocos ordenadores es editar el archivo hosts de los equipos de tu red local para que cuando pidan la ip de nuestra página web, los equipos obtengan una ip privada y no pública.

Estos son sólo unos pocos casos por lo que este artículo no pretende ser una guía completa de resolución de problemas. Simplemente es una muestra para ver que con los errores en los servidores Web debemos siempre aplicar la lógica. No debemos desesperar en cuanto aparezca un problema y debemos ir pensando paso por paso qué funciona y qué no funciona e ir sacando conclusiones. Esa es la forma correcta de abordar un problema en un servidor Web.

Y tú ¿Has tenido algún problema de esta índole? ¿Lo has llegado a resolver con estos métodos o con algún otro? Déjanos tu experiencia en los comentarios.

Share