El 20/10/11 18:46, Jorge Toro escribió: > > > El 20 de octubre de 2011 11:34, Juan Antonio <push...@limbo.ari.es > <mailto:push...@limbo.ari.es>> escribió: > > El 20/10/11 18:27, Jorge Toro escribió: >> Cordial saludo lista, >> >> Tengo el siguiente problema: >> >> Resulta que tengo un Firewall/Proxy con la IP publica >> 190.28.122.250 <tel:190.28.122.250>(eth0) y la 10.0.4.150 (eth1), >> dentro de mi red tengo dos equipos 10.0.4.17 donde funciona mi >> servidor mail y en 10.0.4.19 donde tengo un servidor con dos >> aplicativos web uno por el puerto 80 y otro por el puerto 8890. >> Para que los aplicativos fueran publicos cree una interfaz de red >> virtual con la IP publica 190.28.122.253 >> <tel:190.28.122.253>(eth0:0), pero cuando redirijo los paquetes >> con iptables: >> >> iptables -A PREROUTING -d 190.28.122.253 <tel:190.28.122.253> -p >> tcp -m tcp --dport 80 -j DNAT --to-destination *10.0.4.19*:80 >> >> No me funciona me dice que el host remoto no contesta. Pero si >> hago pruebas cambiando el PC de destino a el *.17* si funciona, >> si me redirige los paquetes. >> >> iptables -A PREROUTING -d 190.28.122.253 <tel:190.28.122.253> -p >> tcp -m tcp --dport 80 -j DNAT --to-destination *10.0.4.17*:80 >> >> El PC 10.0.4.19 esta accesible y funciona desde la LAN. >> >> Alguien tiene alguna idea de que pueda ser el problema, de >> antemano muchas gracias. >> >> -- >> Jolth >> http://jolthgs.wordpress.com/ >> devmicrosystem.com <http://devmicrosystem.com/> >> -------------------------------------------------------------- >> Powered By Debian. >> Developer Bullix GNU/Linux. >> -------------------------------------------------------------- >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iD8DBQBIWWH6q7mzdgTzI5ARAkX5AJ9TR6hL2ocLMOUDRfhts8DlVl+jpwCeNw5x >> p4+4FNUHPDUx1lU9F8WSKCA= >> =zRhQ >> -----END PGP SIGNATURE----- >> Este correo esta protegido bajo los términos de la Licencia >> Atribución-Compartir Obras Derivadas Igual a 2.5 Colombia de >> Creative Commons. Observé la licencia visitando este >> sitio http://creativecommons.org/licenses/by-sa/2.5/co/. > > > ummm > > ¿Que tienes en filter FORWARD? En 10.0.4.19:80 > <http://10.0.4.19:80> ¿Hay algo escuchando? ¿Las puertas de enlace > por defecto de ambos servidores son la misma? En caso que no sea > el cortafuegos la puerta de enlace ¿Enmascaras el tráfico que > llega a los servidores? > > En todo caso puedes usar tcpdump, por ejemplo, para confirmar si > el tráfico se queda en el cortafuegos o si llega al servidor final > y si este vuelve por donde debe. > > Un saludo. > > > > Hola Juan Antonio: > > ¿Que tienes en filter FORWARD? > > -A FORWARD -s 10.0.4.17 -j ACCEPT > -A FORWARD -s 10.0.4.19 -j ACCEPT > > ¿Hay algo escuchando? > > # netstat -punta | grep :80 > tcp 0 0 0.0.0.0:80 <http://0.0.0.0:80> > 0.0.0.0:* LISTEN - > tcp 0 0 10.0.4.19:8093 <http://10.0.4.19:8093> > 0.0.0.0:* LISTEN - > tcp 0 0 10.0.4.19:80 <http://10.0.4.19:80> > 10.0.4.137:2215 <http://10.0.4.137:2215> ESTABLISHED - > tcp 0 0 10.0.4.19:80 <http://10.0.4.19:80> > 10.0.4.150:35463 <http://10.0.4.150:35463> TIME_WAIT - > tcp 0 0 10.0.4.19:80 <http://10.0.4.19:80> > 10.0.4.160:49928 <http://10.0.4.160:49928> FIN_WAIT2 - > tcp 0 0 10.0.4.19:80 <http://10.0.4.19:80> > 10.0.4.150:35387 <http://10.0.4.150:35387> TIME_WAIT - > tcp 0 0 10.0.4.19:80 <http://10.0.4.19:80> > 10.0.4.138:3665 <http://10.0.4.138:3665> FIN_WAIT2 - > tcp 0 0 10.0.4.19:80 <http://10.0.4.19:80> > 10.0.4.136:54091 <http://10.0.4.136:54091> ESTABLISHED - > tcp 0 0 10.0.4.19:80 <http://10.0.4.19:80> > 10.0.4.136:54089 <http://10.0.4.136:54089> ESTABLISHED - > tcp 0 0 10.0.4.19:80 <http://10.0.4.19:80> > 10.0.4.136:54086 <http://10.0.4.136:54086> TIME_WAIT - > tcp 0 0 10.0.4.19:80 <http://10.0.4.19:80> > 10.0.4.136:54084 <http://10.0.4.136:54084> TIME_WAIT - > > ¿Las puertas de enlace por defecto de ambos servidores son la misma? > > [root@mail ~]# route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref > Use Iface > 10.0.4.0 * 255.255.255.0 U 0 0 > 0 eth0 > 10.0.4.0 * 255.255.255.0 U 0 0 > 0 eth1 > 169.254.0.0 * 255.255.0.0 U 0 0 > 0 eth1 > default enlinea.coopcaf 0.0.0.0 UG 0 0 > 0 eth0 > > [root@web ~]# route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref > Use Iface > 10.0.4.0 * 255.255.255.0 U 0 0 > 0 eth0 > link-local * 255.255.0.0 U 0 0 > 0 eth0 > loopback * 255.0.0.0 U 0 0 0 lo > default 10.0.4.30 0.0.0.0 UG 0 0 > 0 eth0 > > el 10.0.4.30 es un router. > > Como puede en mascarar el trafico que llega a los servidores? ya he > realizado algo como: > iptables -A POSTROUTING -s 10.0.4.19 -j MASQUERADE > > Como puedo usar: "tcpdump, por ejemplo, para confirmar si el tráfico > se queda en el cortafuegos o si llega al servidor final y si este > vuelve por donde debe"? > > Saludos, > > > -- > Jolth > http://jolthgs.wordpress.com/ > devmicrosystem.com <http://devmicrosystem.com/> > -------------------------------------------------------------- > Powered By Debian. > Developer Bullix GNU/Linux. > -------------------------------------------------------------- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQBIWWH6q7mzdgTzI5ARAkX5AJ9TR6hL2ocLMOUDRfhts8DlVl+jpwCeNw5x > p4+4FNUHPDUx1lU9F8WSKCA= > =zRhQ > -----END PGP SIGNATURE----- > Este correo esta protegido bajo los términos de la Licencia > Atribución-Compartir Obras Derivadas Igual a 2.5 Colombia de Creative > Commons. Observé la licencia visitando este > sitio http://creativecommons.org/licenses/by-sa/2.5/co/.
Por partes. Si tienes reglas en FORWARD supongo que es porque tienes la policy a DROP o REJECT, entonces tienes que añadir dos reglas -A FORWARD -d 10.0.4.17 -j ACCEPT -A FORWARD -d 10.0.4.19 -j ACCEPT para que el tráfico que reenvies se acepte. Las puertas de enlace son diferentes y no parecen ser el mismo cortafuegos, asi que añade iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE en el cortafuegos para que el tráfico que se envíe a los servidores vuelva por el y pueda hacer el camino contrario. Un saludo.
