Pruebas servidor de correo de respaldo mx backup

Después de la entrada «Servidor de correo de respaldo o MX Backup con Postfix» es obligada otra para hacer las pruebas que nos den la seguridad de que funciona. Las pruebas van a tener tres partes: confirmar que la configuración DNS es correcta, confirmar que el servidor de respaldo recibe correos y se los envía al principal y por último parar controladamente el servidor principal y monitorizar que no perdemos correos y después llegan a los buzones del servidor principal.

Para comprobar la configuración DNS del dominio utilizamos el comando NSLOOKUP, podemos hacerlo desde una consola de Linux o desde un interprete de comandos de cualquier windows:

Ejecutamos nslookup, depués decimos que queremos consultar las entradas MX, las que corresponden a los servidores de correo, haciendo «set q=MX» y por último escribimos el nombre de dominio para el que hacemos la consulta: «trebede.com». Terminamos con exit. En mi caso se muestra esto:

mail:~# nslookup
> set q=MX
> trebede.com
Server:         80.58.0.33
Address:        80.58.0.33#53

Non-authoritative answer:
trebede.com     mail exchanger = 10 mail.trebede.com.
trebede.com     mail exchanger = 30 mx30.diariodeleon.es.

Authoritative answers can be found from:
mail.trebede.com        internet address = 80.59.96.83
mx30.diariodeleon.es    internet address = 79.148.124.40
> exit

Lo importante es comprobar que las entradas «mail exchanger» están bien, la de mayor prioridad, que es la del número menor debe apuntar al servidor principal y debe haber al menos otra con número mayor apuntando al servidor MX Backup. Podemos tener uno o varios servidores de respaldo.

Ahora vamos a enviar un correo al servidor principal creandolo en el servidor de respaldo, para ello utilizamos telnet y dialogaremos con el protocolo SMTP simulando que somos otro servidor de correo.

Primero abrimos la conexión al servidor de respaldo por el puerto 25, que es el que se utiliza para la transmisión de correos entre servidores: «telnet mx30.trebede.com 25», a esto nos contestara con un comando 220 dandonos informacion del servidor, sistema opertativo, etc. Ahora empezamos a dialogar; con «HELO trebede.com» indicamos que vamos a enviar un correo a trebede.com; «MAIL FROM: fran@trebede.com» presentamos quien envía el correo; «RCPT TO: fran@trebede.com» le indicamos para quién es el correo; «DATA» Escribiremos a continuación los datos del correo; «Subject: Titulo de la prueba» primero el titulo del correo; a continuación escribimos el contenido del correo y para terminar ponemos un punto en una linea en blanco; salimos de la sesion de telnet con quit.

Aqui os dejo mi ejemplo:

mail:~# telnet mx30.trebede.com 25
Trying 79.148.124.40…
Connected to mx30.trebede.com.
Escape character is ‘^]’.
220 mx30.trebede.com ESMTP Postfix (Debian/GNU)
HELO trebede.com
250 mx30.trebede.com
MAIL FROM: fran@trebede.com
250 2.1.0 Ok
RCPT TO: fran@trebede.com
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Titulo de la prueba
Hola esto es el cuerpo del correo de prueba.
Adios.
.
250 2.0.0 Ok: queued as DD0753C572
quit
221 2.0.0 Bye
Connection closed by foreign host.

Esto crea un correo que debe llegarnos, así que lo mejor es enviarlo a una dirección del servidor que podamos ver y pasado un momento mirar el buzón. Si nos llega tenemos operativo y funcionando el servidor MX Backup. Si no llega tenemos que revisar los logs del servidor de respaldo, para comprobar si establece el dialogo con el principal y consigue enviar el correo, y los del servidor principal comprobando si llega a recibir la comunicación, para buscar el motivo.

El último paso es la comprobación del sistema completo. Para ello podemos cerrar la entrada SMTP al servidor principal en el firewall o parar este servicio si podemos o si no parar el servidor. La idea es que no nos puedan llegar correos. Para estar seguros de que los correos pasar por el servidor de respaldo enviamos un par de correos desde gmail, hotmail, yahoo o algun otro sitio externo. En el servidor de respaldo podemos monitorizar el log del postfix, que en debian esta en /var/log/mail.log y vigilar que nos están llegando correos. Con el comando postqueue -p comprobaremos que la cola de mensajes pendientes va creciendo.

Observamos unos minutos que la cosa va bien y volvemos el servidor principal a su funcionamiento normal, el servidor de respaldo debe empezar a enviar los correos al principal, con el comando postqueue -p veremos que la cola va disminuyendo. Si ha pasado mucho tiempo el servidor principal parado podemos utilizar postqueue -h para forzar la cola y no esperar demasiado.

Con esto ya tenemos todo funcionando y comprobado. Si necesitas ayuda con alguna cosa deja un comentario, y si te resulta de utilidad los comentarios siempre son un aliento para escribir cosa de estas.

Comentarios 4

  • Excelente post, realice toda la configuración en base a yener redundancia y no perder los correos de los dominios y puedo añadir que encontré mucha información adicional:
    Se aconseja que para el segundo backup MX este protegido mediante antivirus/antispam ya que los MX secundarios son objetivo prioritario de los spamers pues en muchas ocasiones no estan tan bién protegidos como el primario, se puede usar la técnica de configurar cuatro MX donde el primero es falso el segundo es el primario el tercero es el backup MX y el cuarto también es falso…
    En mi caso tengo los dominios en un registrador apuntando los NS a otro proveedor donde tengo un Plesk VPS multidominio con las zonas DNS configuradas por cada dominio, una vez configurado el backup MX en otro VPS de otro proveedor para tener redundancia me di cuenta de que si apago el servidor Plesk los dominios ya no resuelven las MX de echo no resuelven ninguna zona por lo que los correos se pierden… tan solo me es útil si paro el servicio pero si apago el servidor no funciona que es lo que realmente me interesaba. No se si existe otra forma ahora que ya lo tengo todo montado.

    Saludos.

    • Gracias.
      Efectivamente es muy recomendable tener antivirus y antispam en todos los servidores de correo, y si quieres que funcione mejor, que solamente acepte correos para las cuentas que existen realmente, con esta configuración te admite correo para cualquier destinatario, aunque no exista. Sobre la téctina de los cuatro MX no lo había oido nunca, pero lo investigaré.
      En cuanto a tu problema cuando apagas el servidor Plesk te falta la redundancia del DNS, debes tener funcionando al menos dos servidores DNS para tus dominios, para hacerlo sencillo podrias haer que el VPS que utilizas de servidor de correo de backup también sea servidor de DNS con la misma configuración que el principal. Recuerda ponerlo en el registrador.
      Si necesitas ayuda no dudes en pedirla.
      Saludos.

      • Hola,

        para el tema de la rebundancia DNS creo que seguie estas instrucciones creado un tunel entre servidores para la sincronización:

        http://www.virtualmin.com/documentation/id,dns_slave_auto-configuration_quickstart

        creo que terminare quitando los falsos MX ya que puse las greylist que causan el mismo efecto.

        Saludos.

        • Hola Sergio, con eso creo que conseguirías tu objetivo. Si ya usas Webmin está bien, pero si no lo utilizas yo no lo instalaría solamente para conseguir la comunicación entre los servidores DNS. ¿Haces muchas actualizaciones? Si actualizas poco puedes plantearte cambiar los ficheros de configuración de zonas en ambos servidores y no necesitarás la sincronización, aumentando la seguridad.
          Ya nos contarás cómo va la cosa.
          Saludos.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.