Probleme FTP : connection refused
Fermé
shirwae
-
17 nov. 2008 à 10:28
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 17 nov. 2008 à 14:55
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 17 nov. 2008 à 14:55
A voir également:
- Ftp: connect: connection refused
- Ftp //192.168.l.2121 - Forum Réseau
- Hotmail connection - Guide
- Gmail connection - Guide
- Silkair connect avis ✓ - Forum Consommation & Internet
- Créer un compte france connect ameli - Guide
1 réponse
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
17 nov. 2008 à 14:55
17 nov. 2008 à 14:55
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 :
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 :
Exemple :
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 :
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
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.99Ici 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
