Connexion FTP impossible

Support Debian
#1

Bonjour,

je n’arrive pas à me connecter à un serveur FTP à partir d’un poste client.

J’ai ouvert le port 21.
Le client FTP me retourne toujours un problème de temps.

$ sudo iptables -t filter -A INPUT -p tcp --dport 21 -j ACCEPT

$ ftp ftp.cluster023.hosting.ovh.net
ftp: connect: Connection timed out
ftp> 

$ sudo tcpdump -i wlan0 port 21
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:02:00.189873 IP paques.local.53344 > ftp.cluster023.hosting.ovh.net.ftp: Flags [S], seq 996031600, win 29200, options [mss 1460,sackOK,TS val 850799 ecr 0,nop,wscale 7], length 0
10:02:01.215725 IP paques.local.53344 > ftp.cluster023.hosting.ovh.net.ftp: Flags [S], seq 996031600, win 29200, options [mss 1460,sackOK,TS val 851056 ecr 0,nop,wscale 7], length 0

Je sais que le soucis viens de ce poste client car sur un autre poste, la connexion fonctionne très bien. Après, je suis sous testing, mais je ne pense pas que le problème soit à ce niveau.

Merci de vos idées.

#2

C’est-à-dire ?

#3

J’ai ouvert le port 21 en lançant la commande suivante :

$ sudo iptables -t filter -A INPUT -p tcp --dport 21 -j ACCEPT

#4

Sur le poste client ou le serveur ?
Cette règle autorise les paquets TCP entrants à destination du port 21. Elle ne sert à rien sur le poste client.
D’autre part, elle n’autorise pas les paquets sortants dans le sens retour. Il faut une autre règle pour cela, sans quoi la communication ne pourra s’établir. Et bien entendu il faut que ces règles soient placées avant d’éventuelles règles qui bloquent tout.

#5

J’ai lancé cette commande sur le poste client, dommage. :frowning:

#6

Il y a un pare-feu iptables sur le client qui bloque le FTP sortant par défaut ?
Si oui, il faudra ajouter une règle avec OUTPUT au lieu de INPUT au bon endroit, mais ce ne sera pas forcément suffisant.

#7

En fait, il n’y a pas de pare-feu :slight_smile:

#8

J’aurais dû le deviner en lisant la capture de tcpdump.
Donc une règle pour autoriser des connexions est inutile.
Pas de pare-feu en amont sur le chemin entre le poste client et le serveur non plus ?
Tu as écrit qu’un autre poste peut se connecter au serveur. Cet autre poste est-il situé dans le même réseau local et partage-t-il la même connexion internet ?

#9

Pas de pare-feu en amont sur le chemin entre le poste client et le serveur non plus !
Cet autre poste est-il situé dans le même réseau local : oui.
Partage-t-il la même connexion internet ? : oui.

#10

Le poste qui a le souci utilise-t-il la même passerelle et les mêmes serveurs DNS que le poste qui n’a pas le souci ?
Peut-il se connecter à d’autres serveurs extérieurs en FTP ?

Peux-tu faire une capture du paquet SYN avec tcpdump sur le poste qui peut se connecter au serveur et le comparer avec celui du poste qui ne peut pas ?

#11

Le poste qui a le souci utilise-t-il la même passerelle et les mêmes serveurs DNS que le poste qui n’a pas le souci ? Je pense que oui, et de toute façon on ne peut rien modifier car c’est une connexion wifi à la fac.

Peut-il se connecter à d’autres serveurs extérieurs en FTP ? J’ai testé et c’est non.

Peux-tu faire une capture du paquet SYN avec tcpdump sur le poste qui
peut se connecter au serveur et le comparer avec celui du poste qui ne
peut pas ? Pas évident, les autres ordinateurs ne sont pas à moi :frowning:

#12

L’accès internet de la fac a probablement un pare-feu.

#13

Oui soit mais il n’y a que moi qui n’ai pas de FTP :frowning:

#15

Les autres postes sont aussi sous GNU/Linux ?

#16

les autres sont en wifi aussi ?

#17

@jimbo : oui :slight_smile:

#18

@PascalHambourg : non, je suis le seul sous Linux Debian testing.

#19

as tu essayé de’utiliser le mode ftp passif ?

Ca se fait soit avec ftp -p, soit en utilisant pftp (ce qui revient au même).

#20

Le mode passif n’intervient que pour les connexions de données, or là c’est la connexion de commande sur le port 21 qui ne passe pas.

#21

un simple telnet deja ca fait quoi ?