Red Hat Cluster Suite: Configuring and Managing a Cluster | ||
---|---|---|
Anterior | Capítulo 11. Configuración de un Cluster LVS Red Hat Enterprise Linux | Siguiente |
El File Transport Protocol (FTP), protocolo de transferencia de archivos, es un protocolo multipuerto viejo y complejo que presenta un conjunto distinto de retos para un ambiente cluster. Para entender la naturaleza de estos retos, se debe primero entender algunas cosas clave sobre como funciona FTP.
Con la mayoría de las relaciones con otros servidores cliente, la máquina cliente abre una conexión al servidor en un puerto particular y el servidor luego responde al cliente en ese puerto. Cuando un cliente FTP se conecta a un servidor FTP abre una conexión al puerto de control FTP 21. Luego el cliente le dice al servidor FTP si quiere establecer una conexión activa o pasiva. El tipo de conexión escogida determina como el servidor responde y en que puertos ocurrirán las transacciones.
Los dos tipos de conexiones de datos son:
Cuando se establece una conexión activa, el servidor abre una conexión de datos al cliente desde el puerto 20 a un puerto de alto rango en la máquina del cliente. Toda la data del servidor es luego pasada sobre esta conexión.
Cuando se establece una conexión pasiva, el cliente le pide al servidor FTP que establezca un puerto de conexión pasiva, el cual puede ser en cualquier puerto más alto que 10,000. El servidor se enlaza a este puerto de número alto para esta sesión particular y transmite ese número de puerto de vuelta al cliente. El cliente luego abre el puerto recién enlazado para la conexión de datos. Cada petición de datos que el cliente ejecuta resulta en una conexión de datos separada. La mayoría de los clientes FTP modernos intentan establecer una conexión pasiva al servidor a FTP.
Las dos cosas importantes a notar sobre todo esto en relación a clustering es:
El cliente determina el tipo de conexión, no el servidor. Esto significa, que para hacer cluster con FTP efectivamente, se deben configurar los enrutadores LVS para que manajen ambos tipos de conexiones, pasivas y activas.
La relación FTP cliente/servidor puede abrir potencialmente un gran número de puertos que la Herramienta de configuración Piranha e IPVS no conocen.
El reenvío de paquetes IPVS sólo permite conexiones de entrada y salida del cluster basado en el reconocimiento de su número de puerto o su marca de cortafuego. Si un cliente desde afuera del cluster intenta abrir un puerto que IPVS no está configurado para manejar, este dejará caer la conexión. De forma similar, si el servidor real intenta abrir una conexión de vuelta a la Internet en un puerto que IPVS no conoce, dejará caer la conexión. Esto significa que todas las conexiones desde los clientes FTP en la Internet deben tener la misma marca de cortafuegos asignada y que todas las conexiones desde un servidor FTP deben ser redirigidas apropiadamente a la Internet usando las reglas de filtrado de paquetes.
Antes de asignar cualquier regla de iptables a un servicio FTP, revise la información en la Sección 11.3.1 concerniente a servicios multipuerto y a técnicas para chequear las reglas existentes de filtrado de paquetes.
Abajo hay reglas que asignan la misma marca de cortafuego, 21, al tráfico FTP. Para que estas reglas funcionen apropiadamente, usted debe también usar la sub-sección SERVIDOS VIRTUAL de la Herramienta de configuración Piranha para configurar un servidor virtual para el puerto 21 con un valor de 21 en el campo Marca de cortafuegos. Consulte la Sección 12.6.1 para más detalles.
Las reglas para las conexiones activas le dicen al kernel que acepte y reenvíe las conexiones que vienen para la dirección IP flotante interna en el puerto 20 — el puerto de datos de FTP.
/sbin/iptables -t nat -A POSTROUTING -p tcp \ -s n.n.n.0/24 --sport 20 -j MASQUERADE |
En los comandos iptables de arriba, n.n.n debería ser reemplazado con los primeros tres valores para la dirección IP flotante para la interfaz interna de red de NAT definida en el panel CONFIGURACIONES GLOBALES de la Herramienta de configuración Piranha. Estos comandos permiten al enrutador LVS aceptar las conexiones de salida desde los servidores reales que IPVS no conoce.
Las reglas para las conexiones pasivas asignan la marca de cortafuegos apropiada a las conexiones entrando desde la Internet a la dirección flotante IP para el servicio en una variedad de puertos — 10,000 a 20,000.
![]() | Aviso | ||
---|---|---|---|
Si está limitando el rango de puertos para las conexiones pasivas, debe también configurar el servidor VSFTP para usar un rango de puertos a juego. Esto se puede lograr agregando las siguientes líneas al final de /etc/vsftpd.conf:
También debe controlar la dirección que el servidor muestra al cliente para las conexiones FTP pasivas. En un sistema LVS enrutado con NAT, añada la línea siguiente a /etc/vsftpd.conf para ignorar la dirección IP del servidor real al VIP, que es lo que el cliente ve al conectarse. Por ejemplo:
Reemplace X.X.X.X con la dirección VIP del sistema LVS. Para la configuración de otros servidores FTP, consulte la documentación respectiva. |
Este rango debería ser lo suficientemente amplio para la mayoría de las situaciones; sin embargo, se puede incrementar este número para incluir todos los puertos inseguros disponibles cambiando 10000:20000 en los comandos de abajo a 1024:65535.
/sbin/iptables -t mangle -A PREROUTING -p tcp \ -d n.n.n.n/32 \ --dport 21 -j MARK --set-mark 21 /sbin/iptables -t mangle -A PREROUTING -p tcp \ -d n.n.n.n/32 \ --dport 10000:20000 -j MARK --set-mark 21 |
En los comandos de iptables mostrados arriba, n.n.n.n debería ser reemplazada con la dirección IP flotante para el servidor virtual FTP definido en la sub-sección SERVIDOR VIRTUAL de la Herramienta de configuración Piranha. Estos comandos tienen el efecto de red de asignar cualquier tráfico dirigido a la dirección IP flotante en los puertos apropiados una marca de cortafuegos de 21, la cual es luego reconocida por IPVS y redirigida apropiadamente.
![]() | Aviso |
---|---|
Los comandos de arriba toman efecto de inmediato, pero no persisten luego de un reinicio del sistema. Para asegurar que las configuraciones de filtrado de paquetes de red sean restaurados luego de un reinicio, consulte la Sección 11.5 |
Finalmente, necesitará asegurarse de que el servicio apropiado este configurado para activarse en los niveles de ejecución respectivos. Para más información sobre esto, consulte la Sección 10.1.