Pourquoi le mode passif FTP nécessite-t-il une plage de ports plutôt qu'un seul port?

J'ai du mal à comprendre pourquoi tous les serveurs FTP nécessitent l'utilisation d'une plage de ports pour les canaux de données en mode passif, par opposition à l'utilisation d'un seul port de données pour toutes les connexions de canaux de données entrantes.

Les serveurs FTP gèrent de nombreux clients connectés simultanément sur le port 21. Les serveurs Web gèrent de nombreux clients connectés simultanément sur le port 80. Etc.

Dans ce cas, pourquoi un serveur FTP ne peut-il pas utiliser un seul port de canal de données pour toutes les connexions de données passives entrantes (tout en pouvant gérer de nombreux clients connectés simultanément sur ce port, par exemple le port 1024)?

Ou peut-il?

Je suis intéressé à connaître les détails techniques pour expliquer pourquoi cela n'est pas possible ou non recommandé.

Une explication claire et technique concernant le problème des multiples sessions FTP simultanées lors du verrouillage du port de données sur un seul port est ce que je souhaite le plus connaître en profondeur. Quand cela peut-il fonctionner, quand ne fonctionnera-t-il pas, pourquoi cela peut ne pas être recommandé, etc.

Comme ce n’est pas le cas, vous devriez l’essayer vous-même et voir s’il ya d’autres problèmes que j'ai peut-être manqués.

Je suppose que vous pouvez limiter la plage de ports passifs à un seul port . En fait, vous pouvez voir dans cette question que de petites plages de ports sont utilisées dans la pratique . Théoriquement, pour prendre en charge plusieurs connexions simultanées, vous n'avez besoin que des 4 valeurs suivantes: IP local, port local, IP distant, port distant. soient uniques. C’est ainsi que vous discernez entre différentes connexions.

Si vous verrouillez le port de votre serveur sur une valeur unique, la seule variable restante est le port utilisé par le client. Ce n'est pas un problème, tant que le client dispose d'un assez grand nombre de ports éphémères libres . À moins que vous ne fassiez du NAT lourd, vous n'avez pas à vous en préoccuper. Maintenant, soyez averti que ce sera purement théorique : si vous utilisiez plusieurs ports sur votre serveur, vous pourriez multiplier le nombre de connexions simultanées hypothétiques en activantnumber of ports in range connexions pour un port côté client. Mais cela ne se produira pas dans la pratique, car je doute qu'il existe une implémentation d'un client FTP qui le supporte (car cela n'a pas beaucoup de sens). De plus, si le client doit partager ses ports éphémères de cette manière et ne peut pas en ouvrir un nouveau, il a des problèmes beaucoup plus graves à traiter. Donc, de ce point de vue, vous devriez être totalement sûr d’utiliser un seul port.

Pensons pourquoi un seul port peut ne pas suffire .

Tout d’abord, je pourrais arriver à une situation dans laquelle une implémentation de serveur FTP très problématique emploie uniquement le numéro de port local comme moyen d’identifier le transfert de données du client. Encore une fois, je ne pense pas qu'un FTPd décent ferait cela.

Le vrai problème ( oui, vous pouvez ignorer tout ce qui précède comme une digression majeure ;-)) est que la plage de ports passifs se situe dans une plage non privilégiée .

Cela signifie que le numéro de port que vous avez sélectionné n'est pas réservé en tant que tel . En fait, tout processus utilisateur (ne nécessite pas de privilèges root ) peut le récupérer avant votre serveur FTP. Si vous avez un grand nombre de ports à sélectionner, vous devez en choisir un libre. Si vous êtes obligé d'utiliser le seul et qu'il est déjà utilisé, vous ne pourrez pas gérer les transferts correctement.

Désolé, si la réponse semble un peu trop spéculative. Pour être honnête, j'ai tout fait pour trouver la raison pour laquelle vous ne devriez pas utiliser un seul port et, mis à part le dernier point, je ne pouvais penser à aucune preuve tangible à ce sujet. Néanmoins, vous posez une question intéressante et stimulante.

FTP repose sur deux connexions distinctes, une pour le flux de contrôle ou de commande et une pour la transmission des fichiers de données et d'autres informations telles que les listes de répertoires. Le flux de contrôle est acheminé via une connexion TCP traditionnelle. Le client se lie à un port sans privilège élevé et envoie une demande de connexion au serveur FTP, qui est lié au port 21. Cette connexion est utilisée pour transmettre des commandes.

En mode Port ou en mode actif, le client indique au serveur le port secondaire non privilégié sur lequel il va écouter. Le serveur initie ensuite la connexion de données du port 20 au port non privilégié spécifié par le client.

Le mode passif, mécanisme plus récent, est le mode par défaut lorsque le client est un navigateur Web. Au lieu d'être lié au port 20, le serveur indique au client le port haut à utiliser pour le transfert de données. Les données sont ensuite transmises sur des ports non privilégiés entre le client et le serveur.

Pour plus de détails, veuillez consulter:

http://tools.ietf.org/html/rfc959

MODIFIER

En ce qui concerne le verrouillage du serveur sur un seul port, cela peut être possible sur certains serveurs. Par exemple, dans vsftpd, vous disposez des options de configuration suivantes.

   pasv_max_port
          The maximum port to allocate for PASV style data connections. Can be used to specify a narrow port range to assist firewalling.

          Default: 0 (use any port)

   pasv_min_port
          The minimum port to allocate for PASV style data connections. Can be used to specify a narrow port range to assist firewalling.

          Default: 0 (use any port)

Si vous définissez les deux ports sur le même, par exemple, pasv_max_port = 12345, pasv_min_port = 12345, vous pourrez peut-être obtenir ce que vous cherchez. Je pense que cela limitera le nombre de sessions FTP simultanées prises en charge par votre serveur. S'il vous plaît tester pour être sûr.

Un serveur FTP peut peut- être faire correspondre la connexion du port de données du client à sa connexion de contrôle-port en fonction de l'adresse IP source uniquement, plutôt qu'en fonction du numéro de port utilisé.

Cela casserait FXP (ce qui n’est peut-être pas une mauvaise chose) lorsque le client se connecte à deux serveurs (un en mode passif), puis, après avoir reçu les informations PORT du serveur passif, le transmet au serveur en mode actif sous la forme d'une commande PORT Le mode serveur se connecte au serveur en mode passif.

Je soupçonne que de nombreux serveurs ne créent pas le socket de données tant que le client n'a pas demandé le mode passif. Dans ce cas, si deux clients demandent le mode passif en même temps, les sockets créés auront besoin de numéros de port uniques.

EDIT : Pensez à une autre raison pour laquelle les serveurs FTP ne font pas cela: le serveur ne pouvait pas distinguer plusieurs utilisateurs ayant la même adresse IP.

Sur les ports 21 ou 80 (comme sur tous les ports bien connus), il existe un protocole défini que le client utilise pour indiquer ce qu'il veut. De cette façon, le serveur sait pourquoi vous vous connectez. Sur le port de connexion de données, il n'y a pas de protocole. Tout ce que le serveur sait - la seule chose qui soit unique à propos de cette connexion - est le numéro de port auquel vous vous connectez.

Si vous vous connectiez au même port à chaque fois, le serveur ne serait pas en mesure de dire pour quel fichier vous vous connectez. Le numéro de port sert de lien entre une demande de transfert sur la connexion de contrôle et une connexion de données.

Si deux clients devaient demander un transfert en même temps, lorsque le serveur accepte une connexion sur un seul port, le serveur ne serait pas en mesure d'indiquer le fichier à transférer. Bien entendu, le serveur pourrait utiliser une adresse IP client pour prendre cette décision (de nombreux serveurs FTP valident en réalité que l’adresse IP du client correspond à l’adresse IP utilisée sur la connexion de contrôle, pour des raisons de sécurité).

Mais cela ne fonctionnerait pas pour:

• Plusieurs connexions à partir du même ordinateur (la plupart des clients FTP prennent en charge les transferts / files d'attente parallèles).
• Connexion à partir de différentes machines au sein du même réseau (d'entreprise), car celles-ci ont la même adresse IP externe.

Voir aussi Réutilisation des connexions de données FTP .

Je n'ai pas vu cela mentionné ici, donc je vais le jeter dedans. L'attribution de la plage de ports était censée être une sorte de fonction de sécurité, où vous ne pouviez pas surveiller un port pour le trafic de données, les données ont été envoyées sur un port aléatoire dans la gamme, qui ne pouvait pas être facilement déterminée. La sécurité à travers l'obscurité.

On dirait que vous connaissez déjà les ports de contrôle et les ports de données, alors je vais droit au but. Les ports de contrôle sont par nature des communications éclatées, tout comme le port 80 des sites Web. ils peuvent traiter de nombreuses demandes différentes (pas simultanément, mais presque car ils sont si rapides à traiter). Les ports de données, d’autre part, sont l’endroit où la magie opère avec FTP. Si vous vous limitez à un seul port de données, un seul transfert de données est effectué à la fois. envisager un transfert de fichiers volumineux. Avec un seul port de données ouvert, aucune autre donnée ne peut être déplacée avant la fin du transfert. Cela signifie que lors du transfert, un deuxième utilisateur ne pourra même pas lister le contenu du répertoire du dossier ftp. Bien sûr, ils pourront se connecter avec succès, mais leur comportement sera le même que si les ports de données n'étaient pas ouverts du tout. Si ça vous va, un seul port fonctionnera très bien pour vous. Gardez à l'esprit que certains clients ftp (par exemple, un client) configurent par défaut plusieurs connexions au cours d'une même session pour le téléchargement. Ainsi, pour ce client, dans un scénario à un seul port, envisagez un transfert par lots d'un fichier volumineux et de 4 petits fichiers.

Le client initie le transfert pour le premier fichier volumineux, qui est totalement ennuyeux. Ensuite, pendant le transfert, un deuxième fichier est créé. Pas de dé. Puis le troisième, également zilch (terme technique). En fin de compte, le journal devrait indiquer 1 transfert réussi et 4 transferts échoués. La solution consiste à limiter le client à une seule connexion par session et vous seriez prêt à partir (en supposant que quelqu'un d'autre ne soit pas rentré dans la porte, la toute microseconde un transfert est terminé et un autre n'a pas encore commencé. )