Probleme FTP : connection refused

[Fermé]
Signaler
-
Messages postés
30183
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
12 octobre 2021
-
Bonjour,
J'ai installer et configurer vsftpd celon ce tuto:
http://www.debianaddict.org/article47.html

Je suis sous redHat et j'aimerai me faire un ftp sur un réseau local
Quand je fais vsftpd start c est bon
restart, il me met echoué pour arret.

Et quand je fais ftp localhost
ftp: connect: Connection refused

Je suis perdu, sa parle dans les divers forum de telnet port21 ect
et malgré tout cela je narrive pas a régler mon probleme

merci d avance (je suis depuis peu sous linux)

1 réponse

Messages postés
30183
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
12 octobre 2021
7 185
Ftp est un protocole ou le serveur écoute par défaut sur le port 21. Je rappelle qu'une machine qui héberge plusieurs serveurs (par exemple un serveur http, un serveur ssh, un serveur ftp) ouvre plusieurs ports. Elle écoute avec un port par serveur (respectivement 80 pour http, 22 pour ssh et 21 pour ftp par défaut) en vue d'accueillir les connexions provenant d'éventuels clients. Une fois la connexion établie, la communication entre les deux machines peut débuter.

Dans le cas de ftp, un client tente de se connecter sur serveur:21 pour accéder aux données partagées. Telnet permet de tester une connexion sur un port quelconque et de vérifier que le dialogue s'établit entre le client et le serveur. En outre si un pare-feu bloque la communication, celui-ci échouera.

On va a présent essayer de trouver la cause du problème. Au feeling je pense que ton problème se situera au niveau des étapes C ou D vu que ton message est "connexion refused". Pour être sûrs que tout va bien, je t'invite toutefois à vérifier que A et B sont ok. Par exemple si tu es dans un réseau d'entreprise, un serveur ftp peut refuser les connexions ftp venant de l'extérieur mais autorisées celles qui sont internes. Si tu passes par ta passerelle au lieu de t'y connecter directement, le serveur peut te jeter en croyant que tu viens de dehors.

A) La première chose à faire consiste à vérifier que tu arrives à router ton trafic jusqu'au serveur. Si tu utilises son hostname au lieu de son nom de domaine, il faut déjà voir si tu arrives à le résoudre (sinon passe à B). Par exemple tu peux utiliser les commandes host ou nslookup :
(mando@aldur) (~) $ nslookup www.google.fr
Server:         80.10.246.130
Address:        80.10.246.130#53

Non-authoritative answer:
www.google.fr   canonical name = www.google.com.
www.google.com  canonical name = www.l.google.com.
Name:   www.l.google.com
Address: 74.125.43.104
Name:   www.l.google.com
Address: 74.125.43.147
Name:   www.l.google.com
Address: 74.125.43.103
Name:   www.l.google.com
Address: 74.125.43.99
Ici je parviens bien à résoudre www.google.fr. Pour ton serveur il doit en être de même.

B) Ensuite, il faut vérifier si tu as une route pour accéder à cette destination au niveau du client. A priori je pense que c'est le cas mais ça ne coûte rien de vérifier. Cela se vérifie par exemple avec la commande :
/sbin/route -n

Exemple :
(mando@aldur) (~) $ /sbin/route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
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

Dans cet exemple, toutes les adresses de la forme 192.168.1.* sont routées par la première route, et toutes les autres par la seconde route (appelée ici route par défaut, puisqu'elle capture toutes les destinations qui ne sont pas déjà traitées par la première).

C) Ensuite il faut vérifier si le port 21 est ouvert. À mon avis le problème vient sûrement de là. Plutôt que de faire un telnet, il est plus simple de faire un nmap depuis le client. En remplaçant x.x.x.x par le nom ou l'adresse IP du serveur ftp, lance un nmap :
(mando@aldur) (~) $ nmap x.x.x.x

Starting Nmap 4.62 ( https://nmap.org/ ) at 2008-11-17 14:36 CET
Interesting ports on ...... (x.x.x.x):
Not shown: 1708 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
111/tcp  open  rpcbind
113/tcp  open  auth
631/tcp  open  ipp
797/tcp  open  unknown
7634/tcp open  hddtemp

Nmap done: 1 IP address (1 host up) scanned in 0.235 seconds

Dans cet exemple, le port 21 n'est pas ouvert, donc impossible de se connecter en ftp (si le serveur écoute bien sur le port 21).

Si le port est fermé, inutile de chercher plus loin c'est une cause du problème. Soit tu passes par un équipement intermédiaire qui filtre ftp (un proxy ou une passerelle avec firewall par exemple), soit le firewall du client ou du serveur filtre la requête ftp. Sinon on continue !

D) Si le port est ouvert, le problème vient soit de la configuration du serveur (blacklist, firewall) soit du client (mauvaise authentification, mauvais login, mauvais mot de passe...). Essaye de voir si tu arrives à te connecter à ton serveur via lftp (en particulier si ton serveur attend une connexion SSL et que ton client actuel ne le gère pas, ça pourrait expliquer ton problème.

De manière générale je trouve que ftp n'est pas très pratique et pas forcément très sûr. Je te conseille plutôt ssh qui est directement sécurisé et beaucoup plus simple à configurer. Note qu'il existe des clients ssh aussi bien sous linux (konqueror sous KDE, nautilus sous gnome + les commandes ssh et scp) que sous windows (winscp par exemple).

Bonne chance
7
Merci

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

CCM 41713 internautes nous ont dit merci ce mois-ci