Sé que no puedo hacerlo. Lo he probado varias veces y lo he leído otras tantas. Pero, alguien me podría explicar la razón en términos de redes TCP/IP? Es decir una explicación técnica y no una tipo "es que el router se hace un lío..." ¿Pasa solamente con redes tras router NAT o con una única IP pública tb pasa?
Ahí queda el reto para el que le apetezca pensar o ya lo sepa. Gracias.
Salu2.
El protocolo FTP usa dos canales TCP: uno de control, que se abre desde un puerto efímero del cliente (llamémosle TCP/xxxx) hacia el puerto TCP/21 del servidor, y uno de datos, que por defecto se abre desde el puerto TCP/20 del servidor hacia el cliente, al mismo puerto efímero (TCP/xxxx) .
Normalmente con el canal de control no hay problemas: puedes abrir conexión y lanzar comandos.
El problema del FTP con el NAT y con los firewall viene a la hora de abrir el canal de datos (por donde se transmite un fichero, y tb. por donde se transmite un DIR).
El protocolo FTP tiene dos comandos, PORT y PASV, que no son de uso obligado, pero la mayoría de clientes FTP envía sin participación del usuario. En ambos comandos (en un caso en el paquete de ida, y en el otro en la respuesta), se comunica al interlocutor la dirección IP de la máquina y un puerto escogido aleatoriamente, para abrir el canal de datos. Ya no se usa por tanto el puerto TCP/20. Esto puede ser un problema para los firewall's, porque no saben, en un momento dado, que puerto deben abrir para un canal de datos.
El problema del NAT está en que los mecanismos de NAT traducen direcciones de la cabecera IP, pero no miran dentro del paquete. Si como hemos dicho, los comandos PORT y PASV comunican una dirección IP, ésta será una IP privada, previa al NAT, y llegará al otro extremo sin traducir, por lo que este otro extremo intentará abrir el canal de datos contra una IP equivocada.
Por lo general, en routers y firewalls buenos, estos problemas se solucionan con ALG's (Application Level Gateway), que son capaces de reconocer tráfico FTP (entre otros), buscar dentro de los paquetes los comandos PORT y PASV, abrir el puerto que ahí se diga, y traducir convenientemente la dirección IP. De esta forma, sí funcionará el FTP en entornos donde hay firewalls y NAT's.
¿Queda suficientemente claro?
Un saludo
Según lo entiendo, eso resultaría un problema para conectarse también en modo pasivo a un servidor externo, ya que en ese caso mi router tampoco corregiría las ips de los datos de aplicación. Sin embargo, puedo conectarme a servidores externos tanto en modo pasivo como activo. No veo cuál es la diferencia con mi propio servidor... :-P
Salu2.
Cuando eres tú el que realiza la conexión, el router sabe que debe recibir datos para una petición que tú has iniciado. Si tú inicias una conexión al 21 del otro equipo, a la vez le habilitas un puerto para que te conteste por ahí. En el transcurso de la negociación, te manda por PASV otro puerto adicional que él abre para la comunicación FTP-DATA (no el 20, sino otro aleatorio). En ese momento eres tú quien realizas una segunda conexión a ese puerto, habilitando a su vez otro aleatorio para que te conteste.
Si tú no hubieses abierto esos dos puertos aleatorios como parámetro añadido a una conexión TCP/IP de 3 vías, el router creería que son llamadas entrantes y las hubiese bloqueado. Supongo que todos los routers decentes de hoy en día realizan este tipo de "stateful packet inspection", ¿no?
Saludos.
Perdón por el segundo post. Me había hecho un lío estúpido y estaba considerando el problema como si fuese el cliente quien envía la respuesta PASV... :-P, cuando es el servidor detrás de NAT el que responde. Ha sido un lapsus. De hecho casi escribo otro post discutiendo las respuestas, jajajaja. A veces puedo ser muy cabezón. Lo dicho, muchas gracias!
Ya que estamos... ¿conocéis algún servidor que tenga la opción de detectar la IP pública DINAMICA, para así poder construir correctamente estos paquetes?
Salu2.
Editado: Ya lo he encontrado yo! Mi querido war ftp se puede configurar de tal manera que un servidor externo detecte la IP pública en todo momento. Genial!
Para quién le interese: dynip.jgaa.com/index.php?cmd=show_articl…t=yes&menu=1
He leido tu explicacion acerca del funcionamiento del ftp.
Sin embargo me ha surgido una duda sobretodo despues de leer el articulo publicado en:(link roto)
La duda mia es que hablas de los comando PORT y PASV como si se usaran en el mismo modo ftp. Ademas no me queda claro de cuando es que se abre el puerto efimero, si lo abre primero el cliente o el servidor
Disculpa pero no tengo una gran experinecia en esto del ftp.
Espero tus comentarios
mepefe
No me extraña que te surjan dudas, acabo de leerme ese artículo, y se explica como un libro cerrado. Aparte de algunas incorrecciones (por no llamarlas mentiras directamente).
Lo que sé del FTP lo saqué directamente de la RFC-959 (la tienes aquí), que lo define. La lectura puede ser un poco farragosa, de hecho te recomiendo que lo imprimas y lo leas tranquilamente sin prisas. Por suerte, algunos capítulos los puedes leer por encima y centrarte en los más útiles.
Antes de nada, esos comandos no es que tú los escribas. Normalmente usarás un cliente FTP que tendrá sus propios comandos, o ningún comando como el Internet Explorer. Luego es el cliente el que lo traduce a los comandos del protocolo. Para jugar, ponte algún cliente que te de opción a teclear comandos, del tipo CuteFTP y otros mil, y fíjate en la ventana de respuestas.
Respecto a los modos, los define el comando que se use: el comando PORT hace que entres en modo activo; y el comando PASV hace que entres en modo pasivo. Y puedes saltar de uno a otro con solo dar el comando correspondiente. Ni el comando PORT ni el comando PASV son obligatorios, puedes tener una sesión completa FTP sin usar ninguno. En este caso el protocolo funciona en modo activo, y sólo en este caso es cuando el servidor usa el puerto TCP/20, a diferencia de lo que dice ese artículo de Mocosoft. Otra cosa es que los clientes FTP más típicos lo usen sin darte otra opción.
Respecto a los puertos efímeros, quién hace qué primero ... léete la RFC.
Editado: He actualizado la referencia RFC, que se me había quedado obsoleta. Había dicho la 765, y ahora digo 959.
Ya estoy desquiciado con el servidor FTP
Yo he intentando humildemente explicar en ese post lo que he sacado de conclusión después de romperme la cabeza con el tema. Si alguien tiene algo que corregir que lo diga, y lo edito. Espero que te ayude.
Salu2.
¡ Correcto total !
Sólo un par de matices.
1.- No es que esté muy seguro, pero creo que la conexión de datos en modo activo NO TIENE QUE VENIR NECESARIAMENTE DEL PUERTO TCP/20. Creo recordar que la norma lo deja abierto a cualquier puerto. Sólo hay un caso en que se concreta más. En modos activos, cuando no se usan los comandos PORT ni PASV, el canal de datos se abre desde el puerto TCP/20 del servidor al TCP/21 del cliente.
2.- Decías que no entendías porqué el servidor contesta al comando PASV dando una dirección IP, si ésta ya está en la cabecera (lo mismo se podría decir del comando PORT). Efectivamente, comunicar una IP en el campo de datos es una jodienda para el NAT, pero hay una explicación. El protocolo FTP ha sido diseñado no sólo para mover ficheros entre un cliente y un servidor, sino también entre 2 servidores, bajo el control de un cliente: a un servidor se le envía el comando PASV, y con la respuesta se envía un comando PORT al otro servidor; se da la orden de transferir y entonces se crea el canal de datos entre 2 servidores. Otra cosa distinta es que la mayoría de la gente no encuentre utilidad a esta funcionalidad del protocolo.
Un saludo
