11 votes

échec de la connexion ftp wget après la commande PASV

En essayant de transférer tous les fichiers d'un serveur web ("source") à un autre ("destination"), la commande wget se connecte via FTP, mais ne peut pas aller au-delà de la commande PASV.

J'utilise une connexion SSH au serveur "de destination" (une boîte Linux sur un hébergement partagé) pour exécuter la commande wget.

Le serveur "source" est un serveur Microsoft, et le client FTP sur mon bureau n'a aucun problème avec lui.

Voici la commande que j'utilise pour lancer le transfert :

wget -m ftp://username:'password'@sourceserver.com

La connexion est réussie, alors ces commandes sont émises :

==> SYST ... done.      ==> PWD ... done.
==> TYPE I ... done.    ==> CWD not needed.
==> ... couldn't connect to xxx.xxx.xxx.xxx port 1128: Connection timed out
Retrying.

Dans le cas de l'erreur "Impossible de se connecter", à chaque nouvelle tentative, il tente un numéro de port différent (pas le 21, auquel il s'est déjà connecté avec succès). La première fois que j'ai noté l'erreur, il a essayé des ports dans la gamme 487X.

Je ne peux pas dire si le problème se situe du côté du serveur Microsoft ("source") ou du côté de Linux ("client").

Qu'en pensez-vous ?

8voto

ytll21 Points 181

Une autre façon est d'éviter le mode passif, ajouter l'argument --no-passive dans votre commande wget peut le faire.

wget -r --no-passive --no-parent ftp://account:<password>@<ip address>/folder/ -P /root

3voto

Steffen Ullrich Points 11972

Pour les transferts de fichiers ou les listes de répertoires, FTP ouvre des connexions TCP supplémentaires sur des ports dynamiques. En mode actif, le client crée un auditeur local et communique au serveur son adresse IP et son port à l'aide de la commande PORT. Le serveur se connecte alors au port du client (généralement le port 20 du côté du serveur). En mode passif, le serveur ouvre le port et fait savoir au client où il écoute en réponse à la commande PASV du client.

Les deux modes nécessitent

  • une adresse IP accessible par l'autre partie, par exemple, le mode actif avec un client derrière un simple routeur NAT ne fonctionnera pas.
  • aucun ou un pare-feu largement ouvert, car les ports du côté de l'auditeur seront différents pour chaque connexion.

Si vous n'avez aucun problème pour l'atteindre à partir de votre client de bureau, il se peut que votre client de bureau utilise le mode actif, alors que wget utilise le mode passif, ou qu'il n'y ait pas de pare-feu/routeur NAT entre votre bureau et le serveur, mais qu'il y en ait un entre votre hébergement partagé et le serveur.

Sans plus de détails sur votre installation, il est difficile de spéculer davantage.

0voto

storm_m2138 Points 171

Pour VSFTPD, vous pouvez spécifier des plages de ports passifs

pasv_min_port=1024
pasv_max_port=1048

Crédit : Configuration du FTP sur le serveur Amazon Cloud

De plus, je voyais wget échouer mais boucles réussir lorsque le

pasv_address

ne correspondait pas à l'IP de la demande -- par exemple, la demande utilisait l'IP du réseau externe, mais l'adresse pasv_address était l'IP du réseau interne.

Je ne sais pas exactement pourquoi cela s'est produit, mais il doit y avoir une différence dans l'implémentation sous-jacente entre wget et curl.

0voto

Hogan Points 1

Je suppose que votre serveur ftp est une IP privée et qu'il utilise le port NAT pour le partage, vous devez activer FTP ALG dans votre dispositif NAT.

\==> PASV ... ne pouvait pas se connecter à 192.168.1.3 port 64316 : La connexion a expiré

Après avoir activé FTP ALG dans votre dispositif NAT ou votre pare-feu, l'adresse IP privée 192.168.1.3 deviendra une adresse IP publique, de sorte que wget puisse établir une connexion avec votre serveur FTP.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X