Problema FTP: conexión rechazada
Hola,
He instalado y configurado vsftpd según este tutorial:
http://www.debianaddict.org/article47.html
Estoy en RedHat y me gustaría montar un ftp en una red local
Cuando ejecuto vsftpd start, todo está bien.
Al reiniciar, me dice que ha fallado al detener.
Y cuando hago ftp localhost
ftp: connect: Conexión rechazada
Estoy perdido, se habla en varios foros de telnet port21 etc.
y a pesar de todo esto, no logro resolver mi problema
Gracias de antemano (soy nuevo en Linux)
He instalado y configurado vsftpd según este tutorial:
http://www.debianaddict.org/article47.html
Estoy en RedHat y me gustaría montar un ftp en una red local
Cuando ejecuto vsftpd start, todo está bien.
Al reiniciar, me dice que ha fallado al detener.
Y cuando hago ftp localhost
ftp: connect: Conexión rechazada
Estoy perdido, se habla en varios foros de telnet port21 etc.
y a pesar de todo esto, no logro resolver mi problema
Gracias de antemano (soy nuevo en Linux)
Configuración: Windows XP Firefox 3.0.4
1 respuesta
Ftp es un protocolo en el que el servidor escucha por defecto en el puerto 21. Recuerdo que una máquina que alberga varios servidores (por ejemplo, un servidor http, un servidor ssh, un servidor ftp) abre varios puertos. Escucha con un puerto por servidor (respectivamente 80 para http, 22 para ssh y 21 para ftp por defecto) con el fin de recibir las conexiones de posibles clientes. Una vez que se establece la conexión, la comunicación entre las dos máquinas puede comenzar.
En el caso de ftp, un cliente intenta conectarse a servidor:21 para acceder a los datos compartidos. Telnet permite probar una conexión en un puerto cualquiera y verificar que el diálogo se establece entre el cliente y el servidor. Además, si un firewall bloquea la comunicación, esta fallará.
Ahora intentamos encontrar la causa del problema. A ojo creo que tu problema se situará en los pasos C o D ya que tu mensaje es "conexión rechazada". Para estar seguros de que todo va bien, te invito, sin embargo, a verificar que A y B están bien. Por ejemplo, si estás en una red corporativa, un servidor ftp puede rechazar las conexiones ftp provenientes del exterior, pero permitir las internas. Si pasas por tu puerta de enlace en lugar de conectarte directamente, el servidor puede rechazarte creyendo que vienes de fuera.
A) Lo primero que hay que hacer es verificar que puedes enrutar tu tráfico hasta el servidor. Si usas su nombre de host en lugar de su nombre de dominio, primero debes ver si puedes resolverlo (si no, pasa a B). Por ejemplo, puedes usar los comandos host o nslookup:
B) A continuación, debes verificar si tienes una ruta para acceder a este destino a nivel del cliente. A priori creo que es el caso, pero no cuesta nada verificarlo. Esto se verifica, por ejemplo, con el comando:
Ejemplo:
En este ejemplo, todas las direcciones del tipo 192.168.1.* están enrutadas por la primera ruta, y todas las demás por la segunda ruta (llamada ruta por defecto, ya que captura todos los destinos que no están ya tratados por la primera).
C) Luego, debes verificar si el puerto 21 está abierto. A mi parecer, el problema seguramente proviene de ahí. En lugar de hacer un telnet, es más sencillo hacer un nmap desde el cliente. Reemplazando x.x.x.x por el nombre o la dirección IP del servidor ftp, lanza un nmap:
En este ejemplo, el puerto 21 no está abierto, por lo que es imposible conectarse por ftp (si el servidor realmente escucha en el puerto 21).
Si el puerto está cerrado, no hay necesidad de buscar más, es una causa del problema. O pasas por un equipo intermedio que filtra ftp (un proxy o una puerta de enlace con firewall, por ejemplo), o el firewall del cliente o del servidor filtra la solicitud ftp. Si no, ¡continuemos!
D) Si el puerto está abierto, el problema proviene ya sea de la configuración del servidor (lista negra, firewall) o del cliente (mala autenticación, nombre de usuario incorrecto, contraseña incorrecta...). Intenta ver si puedes conectarte a tu servidor a través de lftp (en particular si tu servidor espera una conexión SSL y tu cliente actual no lo maneja, eso podría explicar tu problema).
De manera general, considero que ftp no es muy práctico y no necesariamente muy seguro. Te aconsejo más bien ssh que está directamente asegurado y es mucho más simple de configurar. Ten en cuenta que existen clientes ssh tanto en linux (konqueror bajo KDE, nautilus bajo gnome + los comandos ssh y scp) como en windows (winscp, por ejemplo).
Buena suerte
En el caso de ftp, un cliente intenta conectarse a servidor:21 para acceder a los datos compartidos. Telnet permite probar una conexión en un puerto cualquiera y verificar que el diálogo se establece entre el cliente y el servidor. Además, si un firewall bloquea la comunicación, esta fallará.
Ahora intentamos encontrar la causa del problema. A ojo creo que tu problema se situará en los pasos C o D ya que tu mensaje es "conexión rechazada". Para estar seguros de que todo va bien, te invito, sin embargo, a verificar que A y B están bien. Por ejemplo, si estás en una red corporativa, un servidor ftp puede rechazar las conexiones ftp provenientes del exterior, pero permitir las internas. Si pasas por tu puerta de enlace en lugar de conectarte directamente, el servidor puede rechazarte creyendo que vienes de fuera.
A) Lo primero que hay que hacer es verificar que puedes enrutar tu tráfico hasta el servidor. Si usas su nombre de host en lugar de su nombre de dominio, primero debes ver si puedes resolverlo (si no, pasa a B). Por ejemplo, puedes usar los comandos host o nslookup:
(mando@aldur) (~) $ nslookup www.google.fr Server: 80.10.246.130 Address: 80.10.246.130#53 Respuesta no autoritativa: www.google.fr nombre canónico = www.google.com. www.google.com nombre canónico = www.l.google.com. Nombre: www.l.google.com Dirección: 74.125.43.104 Nombre: www.l.google.com Dirección: 74.125.43.147 Nombre: www.l.google.com Dirección: 74.125.43.103 Nombre: www.l.google.com Dirección: 74.125.43.99Aquí puedo resolver correctamente www.google.fr. Para tu servidor debería ser lo mismo.
B) A continuación, debes verificar si tienes una ruta para acceder a este destino a nivel del cliente. A priori creo que es el caso, pero no cuesta nada verificarlo. Esto se verifica, por ejemplo, con el comando:
/sbin/route -n
Ejemplo:
(mando@aldur) (~) $ /sbin/route -n Tabla de enrutamiento IP del núcleo Destino Pasarela Genmask Indicador Métrica Refuso Uso Interfaz 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
En este ejemplo, todas las direcciones del tipo 192.168.1.* están enrutadas por la primera ruta, y todas las demás por la segunda ruta (llamada ruta por defecto, ya que captura todos los destinos que no están ya tratados por la primera).
C) Luego, debes verificar si el puerto 21 está abierto. A mi parecer, el problema seguramente proviene de ahí. En lugar de hacer un telnet, es más sencillo hacer un nmap desde el cliente. Reemplazando x.x.x.x por el nombre o la dirección IP del servidor ftp, lanza un nmap:
(mando@aldur) (~) $ nmap x.x.x.x Iniciando Nmap 4.62 ( https://nmap.org/ ) en 2008-11-17 14:36 CET Puertos interesantes en ...... (x.x.x.x): No mostrado: 1708 puertos cerrados PUERTO ESTADO SERVICIO 22/tcp abierto ssh 80/tcp abierto http 111/tcp abierto rpcbind 113/tcp abierto auth 631/tcp abierto ipp 797/tcp abierto desconocido 7634/tcp abierto hddtemp Nmap terminado: 1 dirección IP (1 host activo) escaneado en 0.235 segundos
En este ejemplo, el puerto 21 no está abierto, por lo que es imposible conectarse por ftp (si el servidor realmente escucha en el puerto 21).
Si el puerto está cerrado, no hay necesidad de buscar más, es una causa del problema. O pasas por un equipo intermedio que filtra ftp (un proxy o una puerta de enlace con firewall, por ejemplo), o el firewall del cliente o del servidor filtra la solicitud ftp. Si no, ¡continuemos!
D) Si el puerto está abierto, el problema proviene ya sea de la configuración del servidor (lista negra, firewall) o del cliente (mala autenticación, nombre de usuario incorrecto, contraseña incorrecta...). Intenta ver si puedes conectarte a tu servidor a través de lftp (en particular si tu servidor espera una conexión SSL y tu cliente actual no lo maneja, eso podría explicar tu problema).
De manera general, considero que ftp no es muy práctico y no necesariamente muy seguro. Te aconsejo más bien ssh que está directamente asegurado y es mucho más simple de configurar. Ten en cuenta que existen clientes ssh tanto en linux (konqueror bajo KDE, nautilus bajo gnome + los comandos ssh y scp) como en windows (winscp, por ejemplo).
Buena suerte