@DavidPostill Désolé, je n'étais vraiment intéressé que par PASV vs EPSV.
CGCampbell
Réponses:
20
La seule différence est qu'ils PORT/PASVsont limités à IPv4 , tout en EPRT/EPSVfonctionnant avec n'importe quel protocole réseau (bien que seul IPv6 soit utilisé dans la pratique).
Les commandes standard PORT(actives) et PASV(passives) du protocole de contrôle FTP échangent des informations d'adresse et de port sous forme de six décimales de 1 octet , à partir desquelles l'autre extrémité doit reconstruire une adresse IP de quatre octets et un numéro de port TCP de deux octets.
PORT <address[4]>,<port[2]>
PORT 132,235,1,2,24,131
Mais d'autres protocoles ont commencé à apparaître. IPv4 était sur le point d'être remplacé par "IPng", qui contenait un certain nombre de propositions de remplacement concurrentes (OSI CLNP, TUBA, SIP, SIPP, CATNIP - à différentes époques de l'histoire), certaines avec des tailles d'adresse d'hôte plus courtes, plus longues et même variables , jusqu'à ce que IPv6 avec des adresses de 16 octets soit finalement défini.
L'envoi de plus d'octets n'aurait pas fonctionné - les serveurs et les clients ne pouvaient pas s'attendre à connaître le bon protocole uniquement en fonction de la longueur de l'adresse. (Par exemple, que faire si vous avez un protocole avec une adresse de 16 octets + un port de 4 octets, un autre avec une adresse de 12 octets + un port de 12 octets?)
En outre - même si cela était moins important il y a 20 ans - de nos jours, il y a des millions de périphériques NAT sur Internet, qui inspectent et gèrent les connexions de contrôle FTP afin que l'hôte "extérieur" ne voit que les adresses IPv4 globales même si "l'intérieur" l'hôte a envoyé un RFC1918 local. Même sans NAT, les pare-feu dynamiques surveillent souvent les commandes de contrôle pour autoriser automatiquement une connexion de données sans règles manuelles.
Cela signifie essentiellement que l'envoi de plusieurs numéros avec PORTou PASVest garanti pour de nombreuses personnes. Peut-être que certains pare-feu mal interpréteraient tranquillement certains octets d'adresse comme le port et élimineraient tranquillement le reste; d'autres pourraient interrompre la connexion ou simplement planter.
Pour éviter divers problèmes comme ci-dessus, de nouvelles commandes ont dû être introduites pour la prise en charge multi-protocoles dans FTP.
En 1993, la RFC 1639 (à l'origine RFC 1545 ) a introduit la "longue adresse" LPRTet lesLPSV commandes, qui étaient comme PORT& PASVmais avec une longueur d'adresse variable ; ils comprenaient également l'identifiant du type de protocole. (Cela n'a cependant pas changé la syntaxe - adresse IPv6: le port serait simplement envoyé sous la forme de 21 chiffres plutôt que de six.)
Cependant, cela n'a toujours pas résolu certains problèmes, comme demander à un serveur d'utiliser un protocole différent de celui de la connexion de contrôle. Le RFC est également rapidement devenu obsolète; lorsque IPv6 est sorti un an plus tard, il ne pouvait pas être utilisé avec LPRT car aucun identifiant de protocole LPRT ne lui était attribué (uniquement pour les diverses premières propositions).
Pour résoudre ce problème, la RFC 2428 en 1998 a ajouté EPRTet EPSV, alias "port étendu" et "passif étendu" , qui avait également une méthode pour négocier un protocole que les deux extrémités prennent en charge. Les commandes "étendues" envoient également des adresses sous une forme lisible par l'homme - pour IPv6, cela signifie utiliser la notation hexadécimale et deux points, plutôt qu'une série de nombres décimaux séparés.
Wow, tous les sites que j'ai lus et qui n'ont pas cliqué avant celui-ci. Merci pour ça. Je l'accepterai (probablement) dans une heure ou deux, je veux voir si quelqu'un d'autre le fait différemment. De plus, la raison pour laquelle j'ai également demandé Active était qu'en raison du balisage fonctionnant bien avec Google, cette question / réponse se retrouvera dans les recherches. Si personne n'ajoute à la réponse (ce qui la rend plus complète pour une réponse Google), je modifierai ma question et mon corps d'origine pour refléter le contenu de votre réponse, en adaptant essentiellement ma question à votre réponse.
CGCampbell
3
Une autre différence est que la EPSVréponse n'inclut pas l'adresse IP (quelle PASVréponse fait). C'est pour éviter un problème courant lorsque le serveur FTP situé derrière un NAT ne sait pas que c'est une adresse IP externe et confond le client FTP en lui envoyant son adresse interne.
Martin Prikryl
Pour ajouter à ce que dit @MartinPrikryl, une autre raison est lors de l'utilisation de FTP sur TLS, le pare-feu / NAT ne peut pas intercepter l'adresse IP dans la commande PASV pour la réécrire (au moins sans MITMing la connexion de contrôle). Les utilisateurs du monde Unix utilisent généralement SFTP au lieu de FTP sur TLS, FTP sur TLS est couramment utilisé avec les ordinateurs centraux IBM, car FTP prend en charge les fichiers orientés enregistrements (STRU R, MODE B), tandis que SFTP prend uniquement en charge les flux orientés Fichiers
Simon Kissane
1
On a déjà répondu à la différence entre actif et passif. Le passif étendu (EPSV) est juste passif avec IPv4 et IPv6, car la syntaxe de la réponse à PASV était spécifique à IPv4 et donc une nouvelle commande était nécessaire pour IPv6. Idem avec EPTR vs PORT en mode actif. Il y a un comportement légèrement différent avec EPRT et EPSV dans la mesure où ils ne peuvent contenir que le port, pas IP et le port comme PORT et PASV. Ainsi, le transfert de données ne peut être effectué qu'entre les systèmes qui ont la connexion de contrôle. Avec PORT et PASV, il est possible de créer une connexion de données entre d'autres systèmes (bien que cela soit aujourd'hui considéré comme une mauvaise conception et un risque pour la sécurité).
C'était le genre de réponse que je ne voulais pas. Cela me dit exactement autant que je pourrais trouver ailleurs, c'est que EPSV a été créé pour IPv6, mais sans expliquer pourquoi. (c'est-à-dire que je n'accepte pas votre raison comme une explication suffisante) Je vous le dis dans l'espoir que vous améliorerez peut-être votre réponse.
CGCampbell
Réponse modifiée pour indiquer clairement que la réponse à la commande PASV pour ne pas prendre en charge IPv6 et donc une nouvelle commande était nécessaire.
Réponses:
La seule différence est qu'ils
PORT/PASV
sont limités à IPv4 , tout enEPRT/EPSV
fonctionnant avec n'importe quel protocole réseau (bien que seul IPv6 soit utilisé dans la pratique).Les commandes standard
PORT
(actives) etPASV
(passives) du protocole de contrôle FTP échangent des informations d'adresse et de port sous forme de six décimales de 1 octet , à partir desquelles l'autre extrémité doit reconstruire une adresse IP de quatre octets et un numéro de port TCP de deux octets.Mais d'autres protocoles ont commencé à apparaître. IPv4 était sur le point d'être remplacé par "IPng", qui contenait un certain nombre de propositions de remplacement concurrentes (OSI CLNP, TUBA, SIP, SIPP, CATNIP - à différentes époques de l'histoire), certaines avec des tailles d'adresse d'hôte plus courtes, plus longues et même variables , jusqu'à ce que IPv6 avec des adresses de 16 octets soit finalement défini.
L'envoi de plus d'octets n'aurait pas fonctionné - les serveurs et les clients ne pouvaient pas s'attendre à connaître le bon protocole uniquement en fonction de la longueur de l'adresse. (Par exemple, que faire si vous avez un protocole avec une adresse de 16 octets + un port de 4 octets, un autre avec une adresse de 12 octets + un port de 12 octets?)
En outre - même si cela était moins important il y a 20 ans - de nos jours, il y a des millions de périphériques NAT sur Internet, qui inspectent et gèrent les connexions de contrôle FTP afin que l'hôte "extérieur" ne voit que les adresses IPv4 globales même si "l'intérieur" l'hôte a envoyé un RFC1918 local. Même sans NAT, les pare-feu dynamiques surveillent souvent les commandes de contrôle pour autoriser automatiquement une connexion de données sans règles manuelles.
Cela signifie essentiellement que l'envoi de plusieurs numéros avec
PORT
ouPASV
est garanti pour de nombreuses personnes. Peut-être que certains pare-feu mal interpréteraient tranquillement certains octets d'adresse comme le port et élimineraient tranquillement le reste; d'autres pourraient interrompre la connexion ou simplement planter.Pour éviter divers problèmes comme ci-dessus, de nouvelles commandes ont dû être introduites pour la prise en charge multi-protocoles dans FTP.
En 1993, la RFC 1639 (à l'origine RFC 1545 ) a introduit la "longue adresse"
LPRT
et lesLPSV
commandes, qui étaient commePORT
&PASV
mais avec une longueur d'adresse variable ; ils comprenaient également l'identifiant du type de protocole. (Cela n'a cependant pas changé la syntaxe - adresse IPv6: le port serait simplement envoyé sous la forme de 21 chiffres plutôt que de six.)Cependant, cela n'a toujours pas résolu certains problèmes, comme demander à un serveur d'utiliser un protocole différent de celui de la connexion de contrôle. Le RFC est également rapidement devenu obsolète; lorsque IPv6 est sorti un an plus tard, il ne pouvait pas être utilisé avec LPRT car aucun identifiant de protocole LPRT ne lui était attribué (uniquement pour les diverses premières propositions).
Pour résoudre ce problème, la RFC 2428 en 1998 a ajouté
EPRT
etEPSV
, alias "port étendu" et "passif étendu" , qui avait également une méthode pour négocier un protocole que les deux extrémités prennent en charge. Les commandes "étendues" envoient également des adresses sous une forme lisible par l'homme - pour IPv6, cela signifie utiliser la notation hexadécimale et deux points, plutôt qu'une série de nombres décimaux séparés.En conclusion, le support IPv6 est la seule différence.
la source
EPSV
réponse n'inclut pas l'adresse IP (quellePASV
réponse fait). C'est pour éviter un problème courant lorsque le serveur FTP situé derrière un NAT ne sait pas que c'est une adresse IP externe et confond le client FTP en lui envoyant son adresse interne.On a déjà répondu à la différence entre actif et passif. Le passif étendu (EPSV) est juste passif avec IPv4 et IPv6, car la syntaxe de la réponse à PASV était spécifique à IPv4 et donc une nouvelle commande était nécessaire pour IPv6. Idem avec EPTR vs PORT en mode actif. Il y a un comportement légèrement différent avec EPRT et EPSV dans la mesure où ils ne peuvent contenir que le port, pas IP et le port comme PORT et PASV. Ainsi, le transfert de données ne peut être effectué qu'entre les systèmes qui ont la connexion de contrôle. Avec PORT et PASV, il est possible de créer une connexion de données entre d'autres systèmes (bien que cela soit aujourd'hui considéré comme une mauvaise conception et un risque pour la sécurité).
la source