MySQL detrás de un gateway/proxy

Intro

Docker ha resultado ser una forma excelente de reducir requerimientos de las máquinas virtuales. Además hace que sean más seguras reduciendo al mínimo el número de puertos expuestos. Cuando trabajamos con lxc en lugar de con docker, el asignarles una IP privada y hacerles accesibles a través de un gateway/proxy también ayuda a la administración de los equipos además de a la seguridad de los mismos.

Sin embargo, es necesario tunear un poco la conguración de los equipos implicados. En esta ocasión hemos tenido que modificar la configuración de MySQL por un error. Este error hacía que cada cierto tiempo nuestro servidor de base de datos bloquease el acceso al proxy a través del cual accedemos a una aplicación instalada en un lxc con IP privada.

El mensaje de error

Host ‘192.168.1.10’ is blocked because of many connection errors; unblock with mysqladmin flush hosts rds

Cualquier acceso a la aplicación arrojaba este mensaje de error, ya que el sistema conecta con la base de datos del otro container nada más iniciar la aplicación.

La solución

Tal y como dice el propio mensaje de error, la solución pasa por limpiar los errores de conexión con FLUSH-HOSTS en el servidor de base de datos remoto al que se conecta la aplicación. Sin embargo, al cabo de pocos días (horas en algunos casos) el error se volvía a repetir.

Buscando en google algunas soluciones pasaban por aumentar el número de conexiones máximas aceptadas por el equipo remoto. En nuestro caso esto no funcionó y al día siguiente de que se restableciese la conexión con el servidor remoto el problema volvió a aparece.

Errores de resolución reversa de DNS

Parece que aumentar el número máximo de conexiones permitidas no era la solución al problema. El número de conexiones no era el problema, sino el número de conexiones erroneas.

Por qué eran erroneas estas conexiones?

Podemos ver las conexiones fallidas en el log de mysql ejecutando el siguiente comando en la consola de MySQL:

SET GLOBAL log_warnings = 2;

En nuestro caso las conexiones erroneas se debían a un fallo en la resolución reversa de DNS de la máquina que estaba conectándose al servidor de MySQL remoto. Este error de resolución es más que lógico si tenemos en cuenta que la IP que estaba ofreciendo el cliente al servidor de MySQL era una IP privada.

Para solucionarlo indicamos al servidor de MySQL que no resuelva las IPs de las conexiones entrantes con el siguiente comando en la sección [mysqld] del archivo de configuración de MySQL:

skip-name-resolve

Reiniciamos el servidor de MySQL y a funcionar.