Le Sagem 3302 aime pas le FTP ?

Sphaaxx · Lapin blanc Inscrit le: 07 Juil 2006 Messages: 1

Bonjour à tous,

Nouvel alicien, ch'ui plutôt satisfait. Le transfert de mon accés internet depuis mon ancien FAi a été rapide, le débit est à la hauteur de ce qu'on m'avait promis. La Vo IP fonctionne plutôt bien......j'ai mêm réussi à avoir la hotline sans trop galérer.
Razz

Le soucis c'est que le Sagem semble me bloquer l'accés au serveur FTP que j'héberge sur ma bécane. Pourtant j'ai consciencieusement configuré les serveurs virtuels. J'ai aussi coupé temporairement le firewall voire ce que ça donne. J'ai même vérifié ma config avec l'assistanec tech, pour eux tout devrait fonctionner.........comme avant avec mon précedent modem/routeur (le trés bon Siemens gigaset se 515).

D'ou ma question, qq'1 arrivet'il à faire tourner un serveur FTP sur sa bécane avec le Sagem devant? Shocked

hdecreis

Busyspider · Adjoint-Admin Inscrit le: 06 Sep 2005 Messages: 68415

Juste un mot pour saluer les nouveaux arrivants et leurs souhaiter la Bienvenue sur le forum ..

Je vous laisse à votre petite cuisine, bien trop spécialisée pour moi ... Smile

JkP · Chat de Cheshire Inscrit le: 05 Oct 2005 Messages: 328

en tout cas cela méritera un bon tutoriel tout cela Smile

hdecreis

JkP a dit: en tout cas cela méritera un bon tutoriel tout cela :)

Et ben nah, tu l'auras voulu ;-)

~~ FTP, NAT, et Sagem ~~

Il doit exister des 100aines de tuto sur le FTP et la facon dont sa fonctionne mais bon, pas sur c-alice ou alors j'ai juste pas trouve / mal cherche... alors zou... Celui ci essaye d'etre le plus clair possible meme pour un neophyte, mais je suis pas tres doue pour ca, tout commentaire bienvenu...

* FTP: Comment ca marche

FTP utilise un canal de "dialogue" et un canal de "donnees", souvent appeles respectivement "ftp" et "ftp-data", etant mappes par defaut sur les ports TCP 21 et 20.

** FTP: Canal de dialogue

Quand on se connecte a un serveur FTP, on retrouve la facon de fonctionner standard de la plupart des protos internet, c'est a dire du "plain text" (comprehensible par un etre humain, testable avec du telnet). Exemple d'un login FTP classique en se connectant sur le port 21 de l'ip a.b.c.d:
([recv] pour ce que le serveur nous dit, [send] pour ce qu'on lui envoie)

[recv] 220 ProFTPD 1.2.10 Server (...) [a.b.c.d]
[send] USER nom_d_utilisateur
[recv] 331 Password required for nom_d_utilisateur
[send] PASS monpassword
[recv] 230 User nom_d_utilisateur logged in
[send] HELP
[recv] 214-The following commands are recognized (* =>'s unimplemented):
[recv] 214-CWD XCWD CDUP XCUP SMNT* QUIT PORT PASV
[recv] 214-EPRT EPSV ALLO* RNFR RNTO DELE MDTM RMD
[recv] 214-XRMD MKD XMKD PWD XPWD SIZE SYST HELP
[recv] 214-NOOP FEAT OPTS AUTH CCC* CONF* ENC* MIC*
[recv] 214-PBSZ PROT TYPE STRU MODE RETR STOR STOU
[recv] 214-APPE REST ABOR USER PASS ACCT* REIN* LIST
[recv] 214 Direct comments to admin_du_site@domaine.com
[send] FEAT
[recv] 211-Features:
[recv] 211-MDTM
[recv] 211-REST STREAM
[recv] 211-SIZE
[recv] 211 End

Nous venons de faire, en humain:
Le client se connecte
SERVEUR - salut toi, je suis le serveur machin sur telle ip etc
CLIENT - je m'appelle toto
SERVEUR - OK, mais donne moi ton mot de passe
CLIENT - mon pass c'est xxx
SERVEUR - OK, c'est bien toi.
CLIENT - aide moi
SERVEUR - Je comprends ces mots la: CWD ...
CLIENT - quelles fonctions evoluees connais-tu ?
SERVEUR - Je sais faire du MDTM, REST STREAM, etc

** FTP: modes passif et actif

C'etait donc le port "dialogue", ou on tappe la discute. Des qu'un echange de donnees est souhaite (par exemple, lors d'un "LIST" pour lister les fichiers ou "RETR" ou "STOR" pour respectivement downloader ou uploader un fichier, on etablit la seconde connexion, le fameux canal "donnees". Hors il existe plusieurs facons de l'etablir. Et il faut specifier ce que l'on souhaite utiliser, car sinon:

[send] LIST
[recv] 425 Unable to build data connection: Invalid argument

Ca marche pas quoi...

L'utilisation de ces deux canaux rends le fonctionnement du protocole un peu plus complexe que necessaire, mais permet de s'affranchir d'un probleme tout simple... Car comment faire avec un seul canal lorsque le fichier que l'on souhaite envoyer contient par exemple "QUIT" ? est-ce une commande du client qui veux fermer la connexion ? est-ce que ca fait partie des donnees ? Pas de doute lorsque les donnnees passent ailleurs. Pas besoin d'encoder, d'escaper, ou de dire le nombre de bits exact que l'on va transferer pour faire la difference...

*** FTP: mode actif

En mode "actif", le client va dire au serveur qu'il peut se connecter a telle addresse IP et tel port (tcp toujours) pour envoyer / recevoir les donnees qui doivent etre echangees, en utilisant une syntaxe un poil barbare mais neammoins comprehensible:

[send] PORT e,f,g,h,x,y
[recv] 200 PORT command successful

En francais, ca donne:

CLIENT - Pour les donnees, envoie les ou recois les en te connectant a l'IP e.f.g.h, sur le port x*256 + y
SERVEUR - OK

A partir de la, des que l'on va taper une commande necessitant l'echange de donnees, c'est exactement ce que le serveur va faire: etablir une connexion vers e.f.g.h:(x*256+y). (que l'on va retranscrire ici sous la forme [send2] et [recv2], sur le meme principe que plus haut). Par exemple, le LIST qui a echoue tout a l'heure:

[send] LIST
[recv] 150 Opening ASCII mode data connection for file list
[recv2] -rw-r--r-- 1 user group 12 Apr 6 2005 fichier1
[recv2] -rw-r--r-- 1 user group 12 Apr 6 2005 fichier2
[recv2] -rw-r--r-- 1 user group 12 Apr 6 2005 fichier3
[recv] 226 Transfer complete.

Le serveur s'est connecte chez le client et lui a envoye les donnees. Ca marche pareil meme si c'est le client qui souhaite envoyer des donnes. Exemple d'envoi de fichier:

[send] HELP STOR
[recv] 214 Syntax: STOR <sp> pathname
[send] STOR test1.txt
[recv] 150 Opening ASCII mode data connection for test1.txt
[send2] coucou toi !
[recv] 226 Transfer complete.

Le serveur a cree le fichier "test1.txt" et a mis dedans "coucou toi !".

Ce qu'il faut bien comprendre dans tout ca c'est que la connexion "data" est ETABLIE PAR le serveur VERS le client, mais que c'est cette connexion qui sera utilisee quel que soit le sens que les donnees prendront (que le client envoie ou recoive des donnees, c'est toujours le serveur qui etablit la connexion).

Tout ca c'est tres bien... mais que ce passe-t-il quand le client est derriere un firewall pas tres intelligent ? Le firewall refuse la connexion du serveur, et le transfert ne peut pas se faire. C'est pour parer a ce probleme (enfin je crois) que le mode passif a ete cree.

*** FTP: mode passif

En mode passif, le client va dire au serveur "eh, je veux faire du passif", et le serveur va lui repondre en lui proposant une IP et un port sur lesquels echanger les donnees. A charge alors pour le client de s'y connecter. C'est donc en gros l'inverse du mode actif. Exemple:

[send] PASV
[recv] 227 Entering Passive Mode (a,b,c,d,v,w).

On voit ici que le format ressemble: le serveur demande au client de se connecter sur l'IP a.b.c.d, sur le port v*256 + w.

Autant il est difficile de tester le mode "actif" avec juste "telnet" ("netcat", lui, permet aussi d'ecouter un port, c'est lui qu'on utilise sur le client pour attendre la connexion du serveur, je ne sais pas s'il existe des equivalents sous windows), le mode passif ne pose pas de probleme, car c'est le client qui ETABLIT les deux connexions. deux fenetres telnet sont donc suffisantes, et c'est _exactement_ le meme principe. Exemple avec les vrais ports du client e.f.g.h vers le serveur a.b.c.d:

Etablissement du canal "dialogue":

client: [cmd ou sh] telnet a.b.c.d 21
[recv] 220 ProFTPD 1.2.10 Server (...) [a.b.c.d]
[send] USER nom_d_utilisateur
[recv] 331 Password required for nom_d_utilisateur
[send] PASS monpassword
[recv] 230 User nom_d_utilisateur logged in
[send] PASV
[recv] 227 Entering Passive Mode (a,b,c,d,151,86).
[send] LIST
... il ne se passe plus rien, le serveur attends la connexion.

Etablissement du canal "donnees":

client: [cmd ou sh] telnet a.b.c.d 38742
[recv2] -rw-r--r-- 1 user group 13 Jul 14 01:23 test1.txt
[recv2] -rw-r--r-- 1 user group 12 Apr 6 2005 fichier1
[recv2] -rw-r--r-- 1 user group 12 Apr 6 2005 fichier2
[recv2] -rw-r--r-- 1 user group 12 Apr 6 2005 fichier3
[recv] 226 Transfer complete.

On retrouve les fichiers de tout a l'heure et le fichier test1.txt que l'on a "STOR"-e.

*** FTP: avantages et inconveniants de ces "modes"

D'abord, ca permet de se liberer d'un eventuelle contrainte provenant d'un firewall (bete) devant le serveur ou devant le client. Si le serveur est derriere un firewall bete, on utilise le mode actif (le firewall bete laisse le serveur "sortir"). Si c'est le client qui est devant un firewall tout aussi bete, on utilise le mode passif.

Ensuite, ok, inconveniant, ca complexifie. certes.

Mais ca permet par exemple de faire du (c'est a la mode) FXP: comment transferer un fichier de 1Go d'un serveur a un autre lorsqu'on est derriere un PC connecte a internet avec un modem 56k ? Eh bien on se contente de dire au premier serveur:
PASV
(il nous renvoie _son_ adresse IP et un port: ip1, port1)
ensuite nous lui disons
RETR fichier_de_1Go.dat
et la il attends que nous nous connections pour nous envoyer les donnees. On dit alors au second serveur:
PORT ip1, port1
STOR fichier_de_1Go.dat

Et le second serveur se connecte au premier a notre place et envoie des donnees. C'etait un exemple de mise en pratique, evidemment simplfie... mais il me semble juste dans l'essentiel.

Mais le plus gros probleme se pose avec l'avenement du NAT.

* NAT

Ouais bon la on va faire vite parceque j'imagine que tout le monde voit a peu pres: il s'agit uniquement, pour un routeur, lorsqu'il envoie des paquet sur internet pour le compte d'une machine "derriere" le routeur en question, de remplacer l'adresse IP source de la machine (une ip interne comme 192.168.1.23), par son IP a lui, de facon a permettre au paquet de vivre sur internet, et permettre au serveur qui recevra le paquet de savoir a qui repondre (bah vi, ip privee tout ca...).

Le nat est plutot bien eprouve, dans ses differents modes (avec ou sans port translation etc etc)... tant que ca reste au niveau IP/TCP.

* NAT et FTP

Mais qu'en est-il des protocoles qui _contiennent_ des informations d'adresse comme le FTP ?

Dans le cas de l'actif, par exemple... le client va envoyer en toute bonne foi au serveur "PORT 192,168,1,23,56,43". Et le serveur va essayer, vu qu'il est de bonne volontee, de se connecter au 192.168.1.1, sur le port 14379. Sauf que bien evidemment, c'est une IP privee, donc il sait pas comment s'y connecter, il connait pas le chemin. Et meme s'il connaissait UN chemin, c'est probablement pas le bon ;-)

Les "gens" ont donc fait des routeurs / firewalls de plus en plus intelligents de facon a compenser la stupidite du FTP (stupide ? j'ai dit stupide, rhoooo c'est mal(tm)).

Des routeurs qui, quand ils nattent, ne s'arrettent pas a l'adresse IP source du paquet, mais aussi a l'adresse IP qui est DANS le paquet. C'est le cas d'a peu pres tous les routeurs de nos jours...

Et des firewalls, qui, quand ils voient passer du FTP d'un client "derriere" eux, demandant au serveur de se connecter en retour a leur IP sur le port 44444, qui OUVRENT dans leur regles une autorisation specifique autorisant ce serveur la a se connecter a ce port la.

Bref, dans le cas d'un modem/routeur/firewall, toutes ces fonctions sont integrees dans le meme equipement. Lequel equipement:

en actif, avec client derriere le modem/routeur:
- remplace l'IP source des paquets
- remplace le contenu du texte envoye au serveur FTP pour remplacer aussi l'IP de la commande PORT
- ouvre son firewall pour permettre au serveur FTP de se connecter en retour sur le port specifie dans la dommande PORT
- insere une regle de NAT supplementaire pour dire que toutes les donnees lui etant destine a lui, vers son IP, sur le port en question, doivent etres renvoyees a l'IP source du client.

Bref, il bosse. il bosse beaucoup moins en passif, puisque le client ne donne pas d'IP dans le texte qu'il envoie au serveur FTP.

Mais lorsque c'est le serveur qui est derriere un equipement qui NATe, on retrouve les memes problemes en passif... Puisque le routeur doit modifier la reponse du serveur FTP pour remplacer l'IP interne du serveur FTP par la sienne propre, enfin faire exactement tout ce qu'il fait pour un client en mode actif.

Tout ca pour finir par parler du Sagem et du FTP ;-)

* FTP et AliceBox Sagem

Lorsqu'on heberge un serveur FTP derriere une AliceBox Sagem, celle-ci "oublie" (bah vi, c'est triste... ca s'appelle un bug), lorsque le serveur reponds a la demande PASV d'un client, de remplacer l'IP source que le serveur envoie dans le TEXTE. Resultat:

[client] PASV
[serveur] 2xx Entering Passive mode (192,168,1,12,45,52)
-> le client essaie de se connecter au 192.168.1.12... qui n'est pas joignable sur internet.

Donc, pour heberger un serveur FTP derriere une alicebox sagem, il existe comme solution:

- forcer dans la configuration du serveur le mode ACTIF seulement.
- utiliser une IP fixe (en passant en MER) et configurer le serveur pour mettre dans le texte cette IP la.

La premiere solution peut se montrer genante si le client est derriere un modem/routeur bete...
La deuxieme peut obliger d'avoir en plus a dire au serveur de n'utiliser qu'un certain range de port pour le PASSIF, et de configurer ce range de port comme "accepte" dans le firewall du Sagem, et redirige vers le serveur (en effet, je n'ai pas teste le comportement du Sagem dans ce mode la, il oublie peut-etre aussi (grrrr) d'inserer la regle firewall autorisant la connexion data resultante, ainsi que la regle de NAT... si qqun se sent de tester...).

Eh ben voila, moi qui comptait faire un rapide tour de "le FTP actif en hebergant un serveur derriere un Sagem", voila que je me retrouve avec 200 lignes de verbiage infame, 1 ligne sur deux trop technique pour 1/2 des lecteurs, l'autre moitie trop "vulgarisante" pour l'autre 1/2 des lecteurs, c'est du propre, et le tout blinde de fautes et d'erreurs de frappe...

Enfin ca servira peut-etre a quelqu'un quand meme...

Si qqun veux en faire un tutoriel un vrai (un truc propre organise et tout et tout), qu'il se fasse plaisir ;-)

++

	Forum C- Alice - Le Cercle des Aliciens et des Freenautes - Index du Forum -> AliceBox V2 (Telecom Italia) (Lecture seule)	Toutes les heures sont au format GMT + 2 Heures
Page 1 sur 1