Ah, ok, ya tenemos algo mas conciso entonces. (escibe a la lista, mejor, o te mando la factura :)
> Yo creo que es el firewall, porque en la red interna donde mi servidor > tiene dos ips una que es 192.168.0.1 y otra que es 24.232.212.155 > Si desde una maquina de la red interna conecto al ftp > ftp 192.168.0.1 10021 > me pide usuario, contraseņa y anda perfecto. ok, coincido, el ftpd se ve bien. > ahora si desde el exterior intento conectarme > 24.232.212.155 sale para autenticar, pero no ingresa. A ver, entiendo que tienes una conexion a internet con una IP real, y la estas compartiendo con una red local con un NAT (enmascarador) que a su vez la hace de firewall (en este caso es dificil separar estas funciones), correcto? Y tu servidor FTP esta en una maquina en la red local, o esta en el mismo ruteador? > yo creo que viene por el lado de las conexiones pasivas, o algo asi > hay algo en los puertos. Por esto le atribuyo la culpa al firewall. En efecto, el FTP es un protocolo algo "tricky". En modo activo (default) el cliente inicializa una conexion "de comandos" hacia el servidor, y cada que hace falta el servidor inicializa una conexion "de datos" hacia el cliente, para eso el cliente le dice en que IP y en que puerto va a escuchar. En modo pasivo ambas conexiones se originan por iniciativa del cliente. Si tu servidor y/o tu cliente esta atras de un NAT, se vuele un tanto dificil, ya que alguno de los dos no es contactable directamente por tener una IP privada. Se la pueden comunicar a la otra parte, pero no le sirve de nada, ya que no se rutea. La conexion de datos se usa no solo para transferir archivos como tal, sino al desplegar el listado de directorios, y creo que para otras cosas tambien. El hecho es que si no es posible establecer conexion de datos, no puedes hacer nada con el servidor ftp, salvo exploitearlo en algunos casos :) Afortunadamente, existen modulos para el kernel para "reescribir" estos datos. Son ip_nat_ftp y ip_conntrack_ftp (asegurate de compilarlos y hacer referencia a ellos en /etc/modules o en tu script de firewall, de preferencia lo primero) Asi cuando se manda info sobre a que IP y a que puerto se debe de mandar la conexion de datos, si es nesesario (dependiendo del mode de ftp) el ruteador sustituye la IP por la suya, y escucha en el puerto apropiado para pasarle el trafico al cliente FTP (o servidor, si se usa modo pasivo). Muy util el asunto. Ahora al grano: $IPTABLES -A INPUT -p tcp --dport 10019:11000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT $IPTABLES -A OUTPUT -p tcp --dport 10019:11000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT No se que tan funcional sea esto si se trata de un ftpd en la misma maquina (es mas, de donde sacaste esas reglas?), en tal caso basta que aceptes y dejes salir conexiones en el rano de puertos deseado, pero si el servidor esta en la LAN y quieres accesarlo desde afuera, lo conveniente es incertar en el kernel los modulos mencionados y hacer una sola regla de tipo: iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 21 -j DNAT --to 10.10.1.20 donde la ppp0 es la interfase que ve al mundo y tiene una IP real y 10.10.1.20 es la IP destino en la red local. El numero del puerto de la maquina en la LAN por default es el mismo que el original, si quieres especificar explicitamente un puerto de la maquina en la LAN, puedes hacerlo por anotacion estandar: 10.10.1.20:10021. Hacer referencia a la interface externa (no a la IP externa) es particularmente util si se trata de una conexion con IP dinamica. Ahora, debes tener algo de consideraicon en cuanto a las demas reglas, de tal forma que dejes pasar las conexiones de datos. La regla general, es no poner ninguna regla cuyo significado, nesecidad y funcionamiento no te sean claros. Por lo general, no nesecitas nada adicional a las reglas que enmascaran y hacen el forward en un firewall, la simple naturaleza del NAT protege tus maquinas, salvo que no solo quieras proteger a tus usuarios del mundo, sino al mundo de tus usuarios (bloqueando ciertas conexiones salientes, a reconocidos servidores porno, por ejemplo, o a smtp's esternos si hay uno interno y no quieres que tus usuarios envien virus o spameen). Solo cuida de no hablitar hacia afuera ningun servicio que no desees dar (pop, smpt, etc.). Es mas sano hacer que los demonios dejen de escuchar en la interface externa, que bloquearlos explicitamente por un firewall (que tal si pasa algo y tu script de firewall no se corre?). Calro, una solucion burda en efeco es bloquear todo y dejar entrar solo lo que nesecitas, pero quieremos hacer algo elegante, no? > Ademas, acabo de probarlo yo mismo, y si no deshabilito el firewall ni > veo la autenticacion... (el que hacia la prueba desde otro lado me dijo > cualquier cosa). O sea, dejas de enmascarar y hacer forward, supongo. Bueno, es el sintoma mas logico. Tambien toma en cuenta, que usando la manera de exponer servicios que te he sugerido, no pordras accederlos desde la LAN usando la IP externa, no se porque, no me he tomado la molestia de averiguarlo a falta de nesecidad. :) Tal vez si en la regla en vez de decir "todo lo que venda en esta interface" dices "todo lo que venga a esta IP", podras hacerlo, falta que lo nesecites y pruebes, la sintaxis te la dejo de tarea. > Te agradeceria cualquier ayuda np.
