web-dev-qa-db-fra.com

Tentative de connexion à vsftpd, échec de l'extraction de la liste des répertoires

Quelque chose ne fonctionne vraiment pas ici. J'ai l'erreur suivante lors de l'utilisation de FileZilla pour me connecter à une machine distante exécutant vsftpdname__:

Command:    LIST
Error:  Connection timed out
Error:  Failed to retrieve directory listing

J'essaie de configurer des services FTP sur 3 machines derrière un pare-feu de FAI résidentiel. Tous sont Ubuntu 12.04 Server LTS, et je ne peux pas utiliser le port 21 en externe sur le site distant.

Bon .. Ok, je l'avoue, c'est moi qui impose la restriction. Je voulais juste avoir l’air de travailler pour une vraie entreprise. Quoi qu’il en soit, un seul des 3 systèmes aurait pu être affecté à 21, ce qui pose donc toujours problème.

J'ai essayé les solutions pour ajouter des lignes "pasv _...", mais je ne parviens toujours pas à passer l'étape de connexion LIST.

Alors, ayant échoué à cela, quel pourrait être le problème?

J'ai lu sur ce site que je devais transférer les ports 20 et 21. À l'heure actuelle, les sites distants ont des ports tels que 10000, 11000, 12000 transférés vers le port interne 21 de chacun des systèmes. Devrais-je transférer des ports supplémentaires à 20? cela n’a aucun sens car ce port n’est même pas ouvert, vsftpd n’écoute que 21.

Tout ce que je veux, c'est une connexion FTP réussie via ces ports transférés. Je suis frustré car j'ai transféré avec succès des services tels que SSH, Apache2, etc., et je ne comprends pas ce qui est cassé ici.

merci Joren d'avoir corrigé ma mise en forme!

EDIT: Je plaisante avec mes tests VPS qui sont directement exposés à Internet, j’ai installé vsftpd juste pour voir ce qui se passe, et le résultat de 'netstat -tuna' montre qu’une connexion réussie à partir de mon client filezilla ressemble à ceci:

tcp        0      0 vps.vps.vps.vps:21       fi.le.zil.la:54288      ESTABLISHED
tcp        0      0 vps.vps.vps.vps:46403    fi.le.zil.la:54289      TIME_WAIT

Remarque: le serveur FTP de mon serveur virtuel principal ne fonctionnait pas non plus au début, en raison d'un problème sans rapport avec les environnements virtualisés ("500 OOPS: priv_sock_get_cmd"). Lire: Je commence à voir que le vsftpd d'Ubuntu ne fonctionne pas "out-of-the-box" comme Apache2 et sshd, pour les personnes frustrées administrateurs système novices, ne pensez pas que vous êtes stupide si cela ne fonctionne pas à la première heure ...

Mon système de test VPS ne dispose pas de pare-feu, de sorte que tous les ports sont directement accessibles au démon FTP. Après avoir exécuté ce test, je constate qu'il est possible que cette connexion secondaire soit bloquée sur le site distant sur lequel je rencontre des problèmes (ports aléatoires tels que 46403).

Au moins maintenant, j’ai confirmé qu’il n’y avait pas de NAT problème avec mon Filezilla, car manifestement, filezilla ouvrait des ports aléatoires et discutait avec mon VPS.

La seule chose qui n'a aucun sens, c'est que la configuration 'connect_from_port_20 = YES' est définie sur ma configuration FTP VPS, mais je ne vois aucune connexion utilisant le port 20 !!! C'est pourquoi je ne sais même pas si ce port doit être transféré derrière un pare-feu.

L'une de mes lacunes en matière de connaissances est que je ne sais même pas ce que fait le port 20 et je ne peux pas apprendre par expérience, car je n'ai jamais vu aucune indication de son utilisation pour la connexion, le téléchargement ou le téléchargement.

OK, j'ai trouvé quelques problèmes (il y a clairement plus d'une chose qui ne va pas) - Cela concerne le transfert de port.

Suspect du problème d'origine (avant de personnaliser vsftpd.conf)

  1. Filezilla se connecte initialement au port distant 10000, ==> passe à 21 sur le serveur FTP interne (ok)
  2. Le serveur FTP ouvre un port aléatoire (PAS 20) comme 45678, mais le routeur n'a évidemment pas de règle pour ce port attribué de manière aléatoire. Il envoie un message indiquant à filezilla de se connecter également à 45678.
  3. Le client Filezilla ouvre son propre port de mon côté derrière le NAT (ok)
  4. Filezilla envoie une demande de connexion à 45678, mais le routeur distant n'accepte pas la connexion car il n'y a pas de règle de transfert pour ce port.

Maintenant, les problèmes que j'ai créés:

pasv_enable=YES
pasv_min_port=10000
pasv_max_port=10000
  1. Filezilla se connecte au port distant 10000, ==> passe à 21 sur le serveur FTP interne (ok)
  2. Le serveur FTP ouvre le seul port possible, 10000, [moment stupide] car j'ai ce port dans ma tête associé à ce système. Mais 10000 est en réalité le pendant WAN correspondant pour 21 sur ce système. Le serveur envoie un message à FileZilla pour qu’il se connecte à 10000 et écoute en interne sur 10000
  3. Le client Filezilla ouvre son propre port aléatoire de mon côté (ok)
  4. Filezilla essaie la connexion secondaire sur le port 10000, le routeur distant la dévie vers le port 21 où elle doit être ignorée ou perdue, tandis que le serveur FTP attend une connexion au port interne 10000 qui n'arrive jamais. (échouer)

Deuxième problème que j'ai créé: j'ai essayé de lier le port 21 cette fois-ci, mais je pense que ça a gâché filezilla.

pasv_enable=YES
pasv_min_port=21
pasv_max_port=21
  1. Filezilla se connecte au port distant 10000, ==> passe à 21 sur le serveur FTP interne (ok)
  2. Le serveur FTP ouvre le port 21 (ou échoue peut-être parce que 21 est déjà utilisé). Si cela réussit, il envoie un message à Filezilla pour qu'il se connecte au port 21.
  3. Le client Filezilla ouvre son propre port aléatoire de mon côté (ok)
  4. Filezilla envoie une demande de liste à 21, ce que le routeur ne va pas accepter ... (échec)

Conclusion: tant que le port est modifié par un routeur, le serveur FTP ne pourra jamais dire au client de se connecter au bon port. Si vous essayez d'utiliser le port interne, le client se heurtera au routeur. Si vous essayez de spécifier le port externe, le routeur transfèrera la connexion entrante vers un autre numéro - ce que le serveur ne s'attendait pas.

Je vais tester une solution et faire rapport ici avec les résultats.

Je pense que, comme le protocole du serveur FTP semble indiquer au client à quel port se connecter, cette connexion secondaire DOIT avoir le même numéro de port externe qu’interne.

J'appellerai cela une "connexion secondaire" et je pense que cela a quelque chose à voir avec le port 20 que je ne comprends pas.

Je vais donc contacter le site distant et faire transférer un port supplémentaire directement , afin que le serveur FTP puisse ouvrir une connexion en interne et que le client puisse envoyer une demande de connexion à ce numéro de port exact.

Nouveau plan:

(Remarque: le '%' indique le port modifié par le routeur distant.)

 
 
 serveur n ° 1 
 connexion principale: 21 <-% -> 10000 
 connexion secondaire 10001 <-----> 10001 
 vsftp.conf: 
 pasv_min_port = 10001 
 pasv_max_port = 10001 
 
 serveur n ° 2 
 connexion primaire 21 <-% -> 11000 
 connexion secondaire 11001 <-----> 11001 
 vsftp.conf: 
 pasv_min_port = 11001 
 pasv_max_port = 11001 
 
 serveur n ° 3 
 connexion principale 21 <-% -> 12000 
 connexion secondaire 12001 <-----> 12001 
 vsftp.conf: 
 pasv_min_port = 12001 
 pasv_max_port = 12001
vsftpd
4
ajhcasual

Mon routeur (fritz.box, allemagne) devait être configuré pour déverrouiller les ports les plus élevés dans le même état sortant que entrant. (ci-dessus: ces "pasv_min .. et ... max" insérés ici/prescrits par debian-vsftpd):

Ajouter une gamme de ports non bloqués dans le Fritz! Box-Router avec le bouton correspondant:
"Autres applications" -> "Portokoll": TCP, sur le port: 13450, sur le port: 13500 (ou les ports hauts dans une plage ~ 50), "un ordinateur": RasPi, "une adresse_IP": (grisé, l'adresse LAN-IP interne de mon "RasPi" donnée par le routeur fritz.box) -> et voilà: "un port" (= la même plage!): 13450, "bis Port": 13450, et cela fonctionne très bien avec vsftpd et FTPS (AUTH TLS/SSL-Tranfer avec OpenSSL + fort chiffrement DES-CBC3-SHA) ...

Cela transférera les bons ports et connectera les requêtes de et vers mon petit serveur RasPi- "(derrière le FB-NAT) à la demande IP externe entrante/sortante SUR LA MÊME GAMME DE RAPPORTS ÉLEVÉS (ER), comme à droite - connecté "câbles" aux mêmes ports sur la partie interne ...

Un fichier vsftp-config "/etc/vsftpd.conf":

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
force_dot_files=YES

ssl_enable=YES
force_local_data_ssl=NO
force_local_logins_ssl=NO
allow_anon_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
# rsa_cert_file=/etc/ssl/private/vsftpd.pem   # not working alright, so single-lined:
rsa_cert_file=/etc/ssl/private/vsftpd.crt
rsa_private_key_file=/etc/ssl/private/vsftpd.key

pasv_enable=YES
# pasv_promiscuous=YES
# port_promiscuous=YES
pasv_addr_resolve=YES
pasv_address=[yourDNSadress.no-ip.com] # for Dynamic-DNS the routers daily changing IP.
# port_enable=YES
pasv_min_port=13450
pasv_max_port=13500
file_open_mode=0755
2
Norbert

Dans /etc/vsftpd.conf, vous devez fournir une plage de ports, au moins 2 ou 3, avec les paramètres pasv_min_port et pasv_max_port.

Lorsque vous vous connectez à vsftpd en mode passif avec le client FileZilla, vsftpd répondra avec la connexion de données sur un autre port sélectionné de manière aléatoire dans la plage indiquée par pasv_min_port et pasv_max_port. Si vous essayez de tout faire sur un port, cela va probablement causer des problèmes.

Si vous travaillez avec le port 12001, essayez:
pasv_min_port = 12001
pasv_max_port = 12005

1
Brian Grogan Jr.

Dans mon cas, notre pare-feu a bloqué tous les ports FTP passifs. Lorsque nous avons essayé FTP en mode actif, cela fonctionnait. Nous n'avions ouvert que le port 21 sur notre pare-feu.

Vérifiez si c'est le cas pour vous, changez le paramètre de votre client FTP transfer mode en activeet essayez de vous connecter.

Lorsque notre client FTP était en mode automatic_ ou passivename__, il passait au mode passiveaprès avoir envoyé une demande LISTet que la connexion était interrompue.

0
cjohansson

Pour moi, le problème n'était pas le fichier de configuration "vsftpd.conf" sur le (mini) serveur Raspberry-Pi FTP (avec son logiciel: vsftpd), mais ON MY House-ROUTER avec son pare-feu ne laissant pas passer le " les signaux ", me disant sur mon programme FTPS Windows (je n'utilise pas Filezilla mais CoreFTP) ->" 192,168,178,21,71,27 -> 500 port illégal. " Donc, libérer manuellement ON MY ROUTER non seulement "Port 21", mais aussi une plage de déblocage de port beaucoup plus élevée (ici, par exemple, les chiffres peuvent être aussi beaucoup plus élevés, comme 35000, 40000 ou même plus. .) pour laisser passer les signaux entrants/sortants via l’un de ces ports choisis au hasard dans le logiciel à travers le pare-feu interne de le routeur, (mon RasPi est "derrière" eux sur mon réseau local!), comme suivant (sur le routeur):

Active  Description  Protocol  Port          an Computer(RasPi)  an Port
(OK)    FTPS-Server  TCP       13450-13500   192.168.178.120     13450-13500

Ainsi, à la fois, les ports entrants et sortants SUR LE ROUTEUR sont maintenant des câbles LE MÊME (haut de gamme) comme ceux qui connectent le ROUTEUR en interne avec des "connecteurs à numéro identique" (= ports).

0
norbert

Étape 1 - Désactivez le pare-feu Windows (Restart Must)

Étape 2 - Ouvrez Filezilla Client et modifiez le type de cryptage Fichier -> Gestionnaire de site -> Cryptage -> Utiliser uniquement un FTP simple

0
Chandu