-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Esto es un mensaje de Maxwell Draven, que por algún motivo parece que no puede enviar a la lista y me ha pedido que se lo envíe yo. - ---------- Forwarded message ---------- Tengo el siguiente problemilla: Tengo un cortafuegos con una direccion IP publica y unos servidores (FTP, Correo, Web, etc) con direcciones IP privadas ... quiero que cuando alguien busque algun puerto/servicio desde la Internet, el servidor "interno" (segun sea) responda la peticion . Para ello (siguiendo manuales e instrucciones sobre iptables) tengo lo siguiente: iptables - t nat -A PREROUTING -d IP_PUBLICA -j DNAT -- to IP_PRIVADA iptables - t nat -A POSTROUTING -s IP_PRIVADA -j SNAT -- to IP_PRIVADA Luego: iptables -A FORWARD -d IP_PRIVADA Esto es lo que he dejado despues de muchos quita/pone de eth0 y eth1 que he hecho sin comprender bien su papel. Por cierto, eth0 es la que da el acceso a la Internet y eth1 tiene una IP interna Es el tercer dia que intento que esto me salga, en vista que no me ha funcionado, recurro a sus conocimientos. Quedo atento a sus respuestas/comentarios/sugerencias. Cordialmente, Cuervo Linuxero - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD3rlRtTMYHG2NR9URAtrwAJ9ILeDVxkY2nzKE1QRwbZpSBgj2WwCfa7bB PMfSkb7QYVqA3wUSdSfJR9s= =D20k -----END PGP SIGNATURE-----
El 30/01/06, Carlos E. R.<robin1.listas@tiscali.es> escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Esto es un mensaje de Maxwell Draven, que por algún motivo parece que no puede enviar a la lista y me ha pedido que se lo envíe yo.
- ---------- Forwarded message ----------
Tengo el siguiente problemilla: Tengo un cortafuegos con una direccion IP publica y unos servidores (FTP, Correo, Web, etc) con direcciones IP privadas ... quiero que cuando alguien busque algun puerto/servicio desde la Internet, el servidor "interno" (segun sea) responda la peticion .
Para ello (siguiendo manuales e instrucciones sobre iptables) tengo lo siguiente:
iptables - t nat -A PREROUTING -d IP_PUBLICA -j DNAT -- to IP_PRIVADA
malo....estas direccionando TODO el trafico que venga a vuestra IP_PUBLICA a un servidor con IP_PRIVADA. personalmente, haria el direcionamento solamente de los puertos que necesito, asi aumenta un poco la seguridad.. ;-D por ejemplo: #iptables -A FORWARD -p tcp -d IP_PRIVADA --dport 80 -j ACCEPT #iptables - t nat -A PREROUTING -d IP_PUBLICA -p tcp --dport 80 -j DNAT -- to-destination IP_PRIVADA el primero, habilita el paso de datos entre las distintas redes.. el segundo hace el redirecionamento en si de todos los datos que vengan a la IP-PUBLICA "y solamente" a la puerta 80 para el servidor interno. y para cada uno de los servicios, repetir la misma linea, cambiando el puerto/protocolo y direcciones IPs equivalentes.
iptables - t nat -A POSTROUTING -s IP_PRIVADA -j SNAT -- to IP_PRIVADA
malo .. estas haciendo que los paquetes que esten salindo de vuestra red, se enmascaren com la IP_PRIVADA !!! deberias de cambiar, para: #iptables - t nat -A POSTROUTING -s IP_PRIVADA -j SNAT -- to IP_PUBLICA
Luego:
iptables -A FORWARD -d IP_PRIVADA
Esto es lo que he dejado despues de muchos quita/pone de eth0 y eth1 que he hecho sin comprender bien su papel. Por cierto, eth0 es la que da el acceso a la Internet y eth1 tiene una IP interna
revisa un correo mio de hace unos 2 dias, mas o menos.. alla tiene varios enlaces para documentacion sobre iptables... los comandos que doy arriba no son ni de lejos recomendables, se no tomas otras medidas para configurar correctamente el servidor!!!
Es el tercer dia que intento que esto me salga, en vista que no me ha funcionado, recurro a sus conocimientos.
en principio todo es complicado, pero despues de entender su funcionamento, se tornar trivial.
Quedo atento a sus respuestas/comentarios/sugerencias.
RTFM. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
Hola Victor El día 30/01/06, Victor Hugo dos Santos escribió:
Tengo el siguiente problemilla: Tengo un cortafuegos con una direccion IP publica y unos servidores (FTP, Correo, Web, etc) con direcciones IP privadas ... quiero que cuando alguien busque algun puerto/servicio desde la Internet, el servidor "interno" (segun sea) responda la peticion .
Para ello (siguiendo manuales e instrucciones sobre iptables) tengo lo siguiente:
iptables - t nat -A PREROUTING -d IP_PUBLICA -j DNAT -- to IP_PRIVADA
malo....estas direccionando TODO el trafico que venga a vuestra IP_PUBLICA a un servidor con IP_PRIVADA.
personalmente, haria el direcionamento solamente de los puertos que necesito, asi aumenta un poco la seguridad.. ;-D
Es justo lo que necesito, necesito que al menos el servidor interno, responda un ping desde fuera, ya luego me ocupare de ir cerrando hasta que quede afinado, por ahora necesito saber que esta arriba y funcionando (Llevo varios dias intentando entrar mediante ssh, apuntando a la IP_PUBLICA, pero al parecer no alcanza al server interno ... que estoy haciendo mal, eh ?)
por ejemplo:
#iptables -A FORWARD -p tcp -d IP_PRIVADA --dport 80 -j ACCEPT #iptables - t nat -A PREROUTING -d IP_PUBLICA -p tcp --dport 80 -j DNAT -- to-destination IP_PRIVADA
el primero, habilita el paso de datos entre las distintas redes.. el segundo hace el redirecionamento en si de todos los datos que vengan a la IP-PUBLICA "y solamente" a la puerta 80 para el servidor interno.
y para cada uno de los servicios, repetir la misma linea, cambiando el puerto/protocolo y direcciones IPs equivalentes.
iptables - t nat -A POSTROUTING -s IP_PRIVADA -j SNAT -- to IP_PRIVADA
malo .. estas haciendo que los paquetes que esten salindo de vuestra red, se enmascaren com la IP_PRIVADA !!!
deberias de cambiar, para:
#iptables - t nat -A POSTROUTING -s IP_PRIVADA -j SNAT -- to IP_PUBLICA
Asi la tengo, escribi mal, producto del cansancio ... mis disculpas. Esta parte funciona siempre y cuando use la IP del cortafuegos, pero si me da por usar la que voy a colocar en el exterior para que enrute hacia el servidor interior, el servidor interno no sale a Internet (*&^%$#@!!!!!) Quedo a la espera de una indicacion que me ayude a resolver esto ... que ya se me va volviendo enigmatico. Cordialmente, Cuervo Linuxero -- Algunas personas ven más fácil sacarle provecho a los problemas que decidir resolverlos definitivamente. Hasta los usan como excusa para encargar responsabilidades a otros; pero, a la postre, no toman las decisiones necesarias para solucionarlos.
El 31/01/06, Maxwell Draven<correo.cuervo@gmail.com> escribió:
Hola Victor
El día 30/01/06, Victor Hugo dos Santos escribió:
Tengo el siguiente problemilla: Tengo un cortafuegos con una direccion IP publica y unos servidores (FTP, Correo, Web, etc) con direcciones IP privadas ... quiero que cuando alguien busque algun puerto/servicio desde la Internet, el servidor "interno" (segun sea) responda la peticion .
Para ello (siguiendo manuales e instrucciones sobre iptables) tengo lo siguiente:
iptables - t nat -A PREROUTING -d IP_PUBLICA -j DNAT -- to IP_PRIVADA
malo....estas direccionando TODO el trafico que venga a vuestra IP_PUBLICA a un servidor con IP_PRIVADA.
personalmente, haria el direcionamento solamente de los puertos que necesito, asi aumenta un poco la seguridad.. ;-D
Es justo lo que necesito, necesito que al menos el servidor interno, responda un ping desde fuera, ya luego me ocupare de ir cerrando hasta que quede afinado,
esta malo... el correcto es cerrar todo y abrir solamente el necesario !!! del contrario no tienes un cortafuegos !!!!
por ahora necesito saber que esta arriba y funcionando (Llevo varios dias intentando entrar mediante ssh, apuntando a la IP_PUBLICA, pero al parecer no alcanza al server interno ... que estoy haciendo mal, eh ?)
lo que estas haciendo mal, es no leer la documentacion y asi entender lo que estas haciendo !!!!
por ejemplo:
#iptables -A FORWARD -p tcp -d IP_PRIVADA --dport 80 -j ACCEPT #iptables - t nat -A PREROUTING -d IP_PUBLICA -p tcp --dport 80 -j DNAT -- to-destination IP_PRIVADA
el primero, habilita el paso de datos entre las distintas redes.. el segundo hace el redirecionamento en si de todos los datos que vengan a la IP-PUBLICA "y solamente" a la puerta 80 para el servidor interno.
y para cada uno de los servicios, repetir la misma linea, cambiando el puerto/protocolo y direcciones IPs equivalentes.
iptables - t nat -A POSTROUTING -s IP_PRIVADA -j SNAT -- to IP_PRIVADA
malo .. estas haciendo que los paquetes que esten salindo de vuestra red, se enmascaren com la IP_PRIVADA !!!
deberias de cambiar, para:
#iptables - t nat -A POSTROUTING -s IP_PRIVADA -j SNAT -- to IP_PUBLICA
Asi la tengo, escribi mal, producto del cansancio ... mis disculpas. Esta parte funciona siempre y cuando use la IP del cortafuegos, pero si me da por usar la que voy a colocar en el exterior para que enrute hacia el servidor interior, el servidor interno no sale a Internet (*&^%$#@!!!!!) Quedo a la espera de una indicacion que me ayude a resolver esto ... que ya se me va volviendo enigmatico.
envie para aqui exactamente (TODO) lo que estas haciendo !!! bye. -- -- Victor Hugo dos Santos Linux Counter #224399
Hola Victor: El 31/01/06, Victor Hugo dos Santos escribió:
envie para aqui exactamente (TODO) lo que estas haciendo !!!
A peticion del respetable y apreciado publico : Esto va asi: tengo 4 servidores con IP Privada, tipo A (10.0.0.0), detras de un cortafuegos que tiene 2 tarjetas de red, una de las cuales va a Internet (eth0) y la otra, tiene contacto con los servidores enunciados (eth1). Lo que quiero hacer, es que cuando alguien haga una peticion a una direccion de Internet (200.x.x.x) asignada por el ISP, dicha peticion sea reenviada por el cortafuegos al servidor interno que corresponda (10.x.x.x) y la peticion obtenga respuesta. Lo mismo que, cuando alguna peticion salga de alguno de los servidores internos hacia la Internet, no se vea la IP del servidor interno (10.x.x.x), ni tampoco la del cortafuegos, sino la IP Publica (200.x.x.x) que tiene correspondencia con la IP Privada (Segun lo explicado en el parrafo anterior). Esto es lo que he puesto en etc/rc.d/boot.local iptables -t nat -A PREROUTING -d IP_PUBLICA -i eth0 -j DNAT --to IP_PRIVADA iptables -t nat -A PREROUTING -s IP_PRIVADA -o eth0 -j SNAT --to IP_PUBLICA iptables -A FORWARD -i eth0 -o eth1 -d IP_PRIVADA -m state --state NEW -j ACCEPT iptables -A FORWARD -t filter -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -t filter -i eth0 -m state --state ESTABLISHED, RELATED -j ACCEPT Quedo a la espera de sus indicaciones / sugerencias / correcciones. Agradeciendo de antemano la atencion y la colaboracion prestadas. Cordialmente, Cuervo Linuxero -- Algunas personas ven más fácil sacarle provecho a los problemas que decidir resolverlos definitivamente. Hasta los usan como excusa para encargar responsabilidades a otros; pero, a la postre, no toman las decisiones necesarias para solucionarlos.
El Miércoles, 1 de Febrero de 2006 17:29, Maxwell Draven escribió:
Hola Victor:
El 31/01/06, Victor Hugo dos Santos escribió:
envie para aqui exactamente (TODO) lo que estas haciendo !!!
A peticion del respetable y apreciado publico :
Esto va asi: tengo 4 servidores con IP Privada, tipo A (10.0.0.0), detras de un cortafuegos que tiene 2 tarjetas de red, una de las cuales va a Internet (eth0) y la otra, tiene contacto con los servidores enunciados (eth1).
Lo que quiero hacer, es que cuando alguien haga una peticion a una direccion de Internet (200.x.x.x) asignada por el ISP, dicha peticion sea reenviada por el cortafuegos al servidor interno que corresponda (10.x.x.x) y la peticion obtenga respuesta.
* Peticion y obtener respuesta, son denominaciones genericas para los cientos de protocolos de comunicaciones, asi que me da la impresion que estas mezclando conceptos, creo que lo que necesitas es configurar un servidor DNS, con vistas (internas y externas)
Lo mismo que, cuando alguna peticion salga de alguno de los servidores internos hacia la Internet, no se vea la IP del servidor interno (10.x.x.x), ni tampoco la del cortafuegos, sino la IP Publica (200.x.x.x) que tiene correspondencia con la IP Privada (Segun lo explicado en el parrafo anterior).
* las ip's "privadas" no son ruteables en internet y las publicas no tienen correspondencias con privadas, al activar el enmascaramiento (la tabla nat almacena el origen (privado) de la peticion, para luego poder reenviarle/devolverle la respuesta, el que el destino detecte en la peticion una ip interna es irrelevante, la respuesta se la enviara a la publica (la privada no es alcanzable "per se"). * Esa cabecera privada (http generalmente) se puede suprimir/reescribir en un proxy intermedio, por ejemplo.
Hola Jose: No entendi muy bien lo que me dijiste, pero a ver si este esquema nos aclara a tod@s: # # +-----------------+ # | INTERNET | # +-----------------+ # | # | # +----------------+ # | ROUTER | # +----------------+ # | # | # | # |Eth0 # +----------------------+ # | FIREWALL | # | Eth0 200.x x.1 | # | Eth1 10.x.x.1 | +_____________+ # | # |Eth1 # | # +------------------------------------------------------+ # | R E D D E S E R V I D O R E S | # +------------------------------------------------------+ # | Servidor1 10.x.x.2 200.x.x.2 | # | Servidor2 10.x.x.3 200.x.x.3 | # | Servidor3 10.x.x.4 200.x.x.4 | # | Servidor4 10.x.x.5 200.x.x.5 | # | Servidor5 10.x.x.6 200.x.x.6 | # +------------------------------------------------------+ Asi las cosas ... cuando alguien quiere visualizar una pagina web asociada en el DNS con la IP 200.x.x.2 ... en realidad, es el servidor que tiene la IP 10.x.x.2, el que envia la informacion. Ahora, cuando envian un mensaje desde el Servidor6, la IP de origen no debe verse como 10.x.x.6, como tampoco 200.x.x.1 (IP del cortafuegos) sino debe verse como 200.x.x.6. Espero con esto, haber dado mas claridad a la solucion que busco poner en funcionamiento; con su colaboracion, ya que por mi parte, no doy una mas :( Quedo atento a sus indicaciones / comentarios /sugerencias. Cordialmente, Cuervo Linuxero -- Algunas personas ven más fácil sacarle provecho a los problemas que decidir resolverlos definitivamente. Hasta los usan como excusa para encargar responsabilidades a otros; pero, a la postre, no toman las decisiones necesarias para solucionarlos.
El Miércoles, 1 de Febrero de 2006 20:05, Maxwell Draven escribió:
# +-----------------+ # | INTERNET | # +-----------------+ # | # | # +----------------+ # | ROUTER | # +----------------+ # | # | # | # |Eth0 # +----------------------+ # | FIREWALL | # | Eth0 200.x x.1 | # | Eth1 10.x.x.1 | +_____________+ # | # |Eth1 # |
* A partir de aqui este esquema no lo veo claro, ni entiendo la utilidad, el pool de ip's publicas (ya tienen una pata en internet) no se necesita ni nat ni gaitas para ser alcanzables forward ruta directa) deberian estar pegadas "al menos" a un switch junto con eth0 del firewall, aguas arriba del firewall y detras del router, o en una DMZ. Estas ips alcanzables por el usuario desde fuera (vista externa en el dns) redirigirian la peticion a su correspondiente interna (no veo por que pero en fin, todo el pool puede estar en una maquina, forward_masq), a partir de aqui las peticiones internas (con vista interna) serian servidas por las internas. * En el firewall cuando ip interna 10.x.x.2 quiere enviar un correo (origen, cuyo destino sea cualquier direccion, puerto 25) el firewall lo enruta/dirige a 200.x.x.2 donde nat en esa maquina le dara salida con su ip o el servidor de correo a la escucha o un proxy smtp, vamos toda una odisea. * No se que hacen ip's publicas dentro de rangos privados.
# +------------------------------------------------------+ # | R E D D E S E R V I D O R E S | # +------------------------------------------------------+ # | Servidor1 10.x.x.2 200.x.x.2 | # | Servidor2 10.x.x.3 200.x.x.3 | # | Servidor3 10.x.x.4 200.x.x.4 | # | Servidor4 10.x.x.5 200.x.x.5 | # | Servidor5 10.x.x.6 200.x.x.6 | # +------------------------------------------------------+
El 1/02/06, jose maria<letrados@usernix.org> escribió:
El Miércoles, 1 de Febrero de 2006 20:05, Maxwell Draven escribió:
# +-----------------+ # | INTERNET | # +-----------------+ # | # | # +----------------+ # | ROUTER | # +----------------+ # | # | # | # |Eth0 # +----------------------+ # | FIREWALL | # | Eth0 200.x x.1 | # | Eth1 10.x.x.1 | +_____________+ # | # |Eth1 # |
* A partir de aqui este esquema no lo veo claro, ni entiendo la utilidad, el pool de ip's publicas (ya tienen una pata en internet) no se necesita ni nat ni gaitas para ser alcanzables forward ruta directa) deberian estar pegadas "al menos" a un switch junto con eth0 del firewall, aguas arriba del firewall y detras del router, o en una DMZ.
acredito que en el esquema de Maxwell, el router que el mencionas simplesmente entrega direcciones externas 200.200.200.X (por aca hay mucho de esto) y lo que el "tiene deseos" de hacer es la DMZ que vosotros mencionaste !!! separandola de la Internet por el firewall.
Estas ips alcanzables por el usuario desde fuera (vista externa en el dns) redirigirian la peticion a su correspondiente interna (no veo por que pero en fin, todo el pool puede estar en una maquina, forward_masq), a partir de aqui las peticiones internas (con vista interna) serian servidas por las internas.
* En el firewall cuando ip interna 10.x.x.2 quiere enviar un correo (origen, cuyo destino sea cualquier direccion, puerto 25) el firewall lo enruta/dirige a 200.x.x.2 donde nat en esa maquina le dara salida con su ip o el servidor de correo a la escucha o un proxy smtp, vamos toda una odisea.
hombre.. que ahora tu me enrollaste las neuronas !!! en teoria, lo que el desea hacer es simplesmente: envian un correo (porta 25) a "alguna" de sus direcciones externas (200.200.200.4) y el firewall de el, que tendras 6 direcciones IPs externas (200.200.200.2 hasta 200.200.200.7) y una internet (10.0.0.1), renviara el paquete al servidor de correos que esta siendo ejecutado en la IP 10.0.0.4 y en la puerta 25. #sysctl -w net.ipv4.ip_forward=1 #iptables -A FORWARD -i eth0 -d 10.0.0.4 -p tcp --dport 25 -j ACCEPT #iptables -t nat -A PREROUTING -d 200.200.200.4 -i eth0 -p tcp --dport 25 -j DNAT --to 10.0.0.4 estas deberian de ser las reglas necesarias para que esto funcionara, logicamente. existen otras mas, se deseas algo funcional/seguro.
* No se que hacen ip's publicas dentro de rangos privados.
no estan !!! al menos no las veo!! :-) salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
El Miércoles, 1 de Febrero de 2006 22:37, Victor Hugo dos Santos escribió:
# +-----------------+ # | INTERNET | # +-----------------+ # | # | # +----------------+ # | ROUTER | # +----------------+ # | # | # | # |Eth0 # +----------------------+ # | FIREWALL | # | Eth0 200.x x.1 | # | Eth1 10.x.x.1 | +_____________+
* Vamos a ver el cortafuegos tiene una ip pública, aqui yo si que no veo ninguna publica mas.
hombre.. que ahora tu me enrollaste las neuronas !!! en teoria, lo que el desea hacer es simplesmente:
envian un correo (porta 25) a "alguna" de sus direcciones externas (200.200.200.4) y el firewall de el, que tendras 6 direcciones IPs externas (200.200.200.2 hasta 200.200.200.7) y una internet (10.0.0.1), renviara el paquete al servidor de correos que esta siendo ejecutado en la IP 10.0.0.4 y en la puerta 25.
* Ese no es el esquema que ha puesto, ademas yo entiendo que en este caso lo que desea es que salga/envie con la publica correspondiente.
* No se que hacen ip's publicas dentro de rangos privados.
no estan !!! al menos no las veo!! :-)
# +------------------------------------------------------+ # | R E D D E S E R V I D O R E S | # +------------------------------------------------------+ # | Servidor1 10.x.x.2 200.x.x.2 | # | Servidor2 10.x.x.3 200.x.x.3 | # | Servidor3 10.x.x.4 200.x.x.4 | # | Servidor4 10.x.x.5 200.x.x.5 | # | Servidor5 10.x.x.6 200.x.x.6 | # +------------------------------------------------------+
* Aqui, o lo anterior es un deseo y no un esquema, ahora si hay que hecharle imaginacion .....
Hola Jose ... hola a tod@s Gracias por su colaboracion ... sin ella no desenrredo esta madeja ... :-) Continuando con el esquema, paso a explicar la subsiguiente parte: El 1/02/06, jose maria<letrados@usernix.org> escribió:
# +------------------------------------------------------+ # | R E D D E S E R V I D O R E S | # +------------------------------------------------------+ # | Servidor1 10.x.x.2 200.x.x.2 | # | Servidor2 10.x.x.3 200.x.x.3 | # | Servidor3 10.x.x.4 200.x.x.4 | # | Servidor4 10.x.x.5 200.x.x.5 | # | Servidor5 10.x.x.6 200.x.x.6 | # +------------------------------------------------------+
* Aqui, o lo anterior es un deseo y no un esquema, ahora si hay que hecharle imaginacion .....
Deja ver, que la he liado ... lo que he querido explicar con esto, es la correspondencia entre IPs que quiero lograr; en otras palabras: si alguien envia un correo a la direccion 200.x.x.2, dicho correo llegara al cortafuegos, pero como este no tiene ningun programa que gestione correo ni en modo cliente ni en modo servidor, enviara el susodicho a la maquina que tiene asignada la IP 10.x.x.2, la cual si esta provista de un gestor de correo. A su vez, cuando alguien envia un correo de la LAN que esta detras del Servidor1 (Que tiene Postfix, por decir algo), al llegar el mensaje al destinatario, no aparecera la IP de la maquina origen (192.168.x.x) ni la IP del Servidor1 (10.x.x2) sino la IP Externa relacionada (200.x.x.2). Lo mismo aplica para transacciones FTP, despachos/peticiones, enlaces SSH y demas ... como tambien para los otros servidores/IPs restantes. Siento que estoy a un pelin de lograr que quede andando esto, desde luego que seria de mi sin la colaboracion puntual de la Comunidad de la Lista. Gracias de nuevo por su orientacion, espero que esto contribuya a despejar un poco mas el enigma y pronto pueda comunicar la victoria. Quedo a la espera de sus orientaciones / indicaciones. Cordialmente, Cuervo Linuxero - Algunas personas ven más fácil sacarle provecho a los problemas que decidir resolverlos definitivamente. Hasta los usan como excusa para encargar responsabilidades a otros; pero, a la postre, no toman las decisiones necesarias para solucionarlos.
El Miércoles, 1 de Febrero de 2006 23:58, Maxwell Draven escribió:
A su vez, cuando alguien envia un correo de la LAN que esta detras del Servidor1 (Que tiene Postfix, por decir algo), al llegar el mensaje al destinatario, no aparecera la IP de la maquina origen (192.168.x.x) ni la IP del Servidor1 (10.x.x2) sino la IP Externa relacionada (200.x.x.2).
Lo mismo aplica para transacciones FTP, despachos/peticiones, enlaces SSH y demas ... como tambien para los otros servidores/IPs restantes.
* Bien eso es lo que intendi, para la salida y para que no se encamine por la ruta por defecto, yo lo haria para todos con enrutamiento avanzado por origen echo 202 la_202 >> /etc/iproute2/rt_tables ip rule add from 10.x.x.2 table la_202 echo 203 la_203 >> /etc/iproute2/rt_tables ip rule add from 10.x.x.3 table la_203 ip route add default via 200.x.x.2 dev eth0 table la_202 ip route add default via 200.x.x.3 dev eth0 table la_203 ip route flush cache etc, etc. * Tambien en prerouting , antes de enrutar podrias marcar cierto trafico segun su destino y encaminarlos (creando la tabla correspondiente) por la via que te interese (esto ultimo no parece ser lo que deseas), * lo que ocurre es que asi en frio (sin chuleta delante) se me ocurren algunos problemas posibles de configuracion. * Hacer alias (con ips dentro del mismo rango y mascara de la tarjeta de red) las interfaces se consideran secundarias de la principal (siendo el objetivo colocar servicios en esas ips publicas), te envio un ejemplo de este comportamiento por privado, otro seria que el posible trafico de vuelta se enrute por la pasarela por defecto, en fin prueba a ver con esto y audita el trafico a ver que pasa.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-01 a las 11:29 -0500, Maxwell Draven escribió:
Esto es lo que he puesto en etc/rc.d/boot.local
iptables -t nat -A PREROUTING -d IP_PUBLICA -i eth0 -j DNAT --to IP_PRIVADA
Eso no te va a funcionar, por la sencilla razón que la red no está levantada cuando se ejecuta etc/rc.d/boot.local. Tienes que hacerlo basandote en el método susero de hacer los scripts de arranque, y posteriormente al arranque de la red - fíjate en como lo hace el SuSEfirewall, si lo quieres substituir. Y si no, tienes que insertarlo entre las reglas "custom" del mismo. Por cierto, ¿no te vale lo que te dije el otro dia? FW_FORWARD_MASQ="0/0,10.x.x.2,tcp,80,80,200.x.x.2" - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD4RHitTMYHG2NR9URAsSSAKCN8gcNazYpciB1SLa+nWR0D17r8wCfXIcT QiFXR3Pg5TKgkpmfKUd55/8= =QtNI -----END PGP SIGNATURE-----
El Miércoles, 1 de Febrero de 2006 20:54, Carlos E. R. escribió:
El 2006-02-01 a las 11:29 -0500, Maxwell Draven escribió:
Esto es lo que he puesto en etc/rc.d/boot.local
iptables -t nat -A PREROUTING -d IP_PUBLICA -i eth0 -j DNAT --to IP_PRIVADA
Eso no te va a funcionar, por la sencilla razón que la red no está levantada cuando se ejecuta etc/rc.d/boot.local. Tienes que hacerlo basandote en el método susero de hacer los scripts de arranque, y posteriormente al arranque de la red - fíjate en como lo hace el SuSEfirewall, si lo quieres substituir. Y si no, tienes que insertarlo entre las reglas "custom" del mismo.
* Las reglas en memoria se aplican, de hecho un script de firewall deberia ser lo primero que se cargue, antes de cualquier cosa, por ejemplo desde boot.local.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-01 a las 22:48 +0100, jose maria escribió:
* Las reglas en memoria se aplican, de hecho un script de firewall deberia ser lo primero que se cargue, antes de cualquier cosa, por ejemplo desde boot.local.
¿Incluso aunque luego se levante la red y se incialice y ejecute el SuSEfirewall? - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD4UHVtTMYHG2NR9URAgBYAJ9V5biFOFfIVrXWJ4/3CPXxkw8BwQCcC5hd v9IXAyIbaNqfg/9YHOxT4lo= =C5d+ -----END PGP SIGNATURE-----
el SuSEfirewall ES un script de firewall, que yo sepa se inicia en 3 etapas, SuSEfirewall_init, donde elimina todas las reglas de iptables, setup aplica las reglas para las interfaces y el enmascaramiento y final donde aplica las reglas personalizadas... Saludos Fred Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2006-02-01 a las 22:48 +0100, jose maria escribió:
* Las reglas en memoria se aplican, de hecho un script de firewall deberia ser lo primero que se cargue, antes de cualquier cosa, por ejemplo desde boot.local.
¿Incluso aunque luego se levante la red y se incialice y ejecute el SuSEfirewall?
- -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76
iD8DBQFD4UHVtTMYHG2NR9URAgBYAJ9V5biFOFfIVrXWJ4/3CPXxkw8BwQCcC5hd v9IXAyIbaNqfg/9YHOxT4lo= =C5d+ -----END PGP SIGNATURE-----
------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.25/247 - Release Date: 31/01/2006
El 1/02/06, Carlos E. R.<robin1.listas@tiscali.es> escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2006-02-01 a las 22:48 +0100, jose maria escribió:
* Las reglas en memoria se aplican, de hecho un script de firewall deberia ser lo primero que se cargue, antes de cualquier cosa, por ejemplo desde boot.local.
¿Incluso aunque luego se levante la red
siii ... e como hablo jose maria, el mejor seria hacerlo asi.. llevantar las reglas del cortafuegos antes de la red !!! :-D en teoria, del momento en que se llevanta la red hasta que se ejecute el script del firewall, puede existir varios segundos entre ambos y durante este lapso, alguien podria acceder a vuestra red que no tiene un firewall activo. :-( el unico pero es quando utilizas DHCP (por ejemplo) donde no sabras que ip tendras, tienes que hacer vuestras reglas de manera mas ingeniosas !! :-D
y se incialice y ejecute el SuSEfirewall?
aca ya no te garantizo (nunca lo utilice y no se como funciona) ya que posiblemente este ejecute algun procedimento para elminar las reglas existentes (se es que hay) y restaurar los valores por defecto antes de aplicar las reglas echas atraves del susefirewall. bye -- -- Victor Hugo dos Santos Linux Counter #224399
El Jueves, 2 de Febrero de 2006 00:18, Carlos E. R. escribió:
* Las reglas en memoria se aplican, de hecho un script de firewall deberia ser lo primero que se cargue, antes de cualquier cosa, por ejemplo desde boot.local.
¿Incluso aunque luego se levante la red
* Si, las reglas de cortafuegos son independientes de los servicios se aplican siempre, aunque pares y rearranques la red, a menos que hagas un flush de las mismas.
y se incialice y ejecute el SuSEfirewall?
* Entonces esto serian dos scripts de Firewall o se usa uno u otro, SuSEfirewall, arranca en dos fases por razones meramente internas, automatismos, detecciones de servicios, vamos que SuSEfirewall es un front-end con unas caracteristicas y arranca, ejecuta e incluso crea reglas automaticamente segun el fichero de configuración.
El 1/02/06, Maxwell Draven<correo.cuervo@gmail.com> escribió:
Hola Victor:
El 31/01/06, Victor Hugo dos Santos escribió:
envie para aqui exactamente (TODO) lo que estas haciendo !!!
A peticion del respetable y apreciado publico :
Esto va asi: tengo 4 servidores con IP Privada, tipo A (10.0.0.0), detras de un cortafuegos que tiene 2 tarjetas de red, una de las cuales va a Internet (eth0) y la otra, tiene contacto con los servidores enunciados (eth1).
Lo que quiero hacer, es que cuando alguien haga una peticion a una direccion de Internet (200.x.x.x) asignada por el ISP, dicha peticion sea reenviada por el cortafuegos al servidor interno que corresponda (10.x.x.x) y la peticion obtenga respuesta.
hasta aca, ok.. no hay problema !!!
Lo mismo que, cuando alguna peticion salga de alguno de los servidores internos hacia la Internet, no se vea la IP del servidor interno (10.x.x.x),
imposible !!!! al menos en los routers bien configurados, deberian de ser bloqueados el ruteo para estas direcciones !!!
ni tampoco la del cortafuegos, sino la IP Publica (200.x.x.x) que tiene correspondencia con la IP Privada (Segun lo explicado en el parrafo anterior).
Esto es lo que he puesto en etc/rc.d/boot.local
malo lugar para ingresar cualquer cosa !!! para estos estan los scripts de arranque /etc/rc.d/* y de una mirada en como poder hacer el tuyo mismo , o copiar la estructura de uno !!! pero, acredito que el mas facil en estes casos es utilizar las herramentas iptables-save y iptables-restore para guadar/aplicar las reglas del cortafuegos y para activarlas/desactivarlas se puede utilizar las variables UP/DOWN en las configuraciones de las tarjetas de redes /etc/sysconfig/ifcfg-MAC-DE-LA-TARJETA !!!!
iptables -t nat -A PREROUTING -d IP_PUBLICA -i eth0 -j DNAT --to IP_PRIVADA
ok... aca, envias TODO que venga a la IP_PUBLICA para un unico SERVER interno.
iptables -t nat -A PREROUTING -s IP_PRIVADA -o eth0 -j SNAT --to IP_PUBLICA
aca esta malo ... deberia de ser POSTROUTING !!!
iptables -A FORWARD -i eth0 -o eth1 -d IP_PRIVADA -m state --state NEW -j ACCEPT iptables -A FORWARD -t filter -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -t filter -i eth0 -m state --state ESTABLISHED, RELATED -j ACCEPT
esto esta sobrando ... como te mencione antes, el que haces de redirigir TODO el trafico de la IP_PUBLICA para el servidor de la IP_PRIVADA, IMHO, es una gran estupidez... y de nada adelantas agregar estas reglas aca, para filtrar trafico !!!! se realmente deseas continuar con lo que haces de la manera que haces, simplesmente deja el forward con su politica por defecto en ACCEPT ... por cierto, en parte alguna, vi que habilitaste el el "forward" en el "super firewall".. debes de habilitarlo: sysctl -w net.ipv4.ip_forward=1 o editando directamente el archivo /etc/sysctl.conf.
Quedo a la espera de sus indicaciones / sugerencias / correcciones.
revisa lo que realmente esas haciendo !!!! hacer funcionar por funcionar no es la solucion ideal, al final vas acabar teniendo aun mas problemas !!!
Agradeciendo de antemano la atencion y la colaboracion prestadas.
suerte en vuestra aventura. -- -- Victor Hugo dos Santos Linux Counter #224399
Jefe... El error mas amenudo de contra fuegos, es un error en los malditos iptables scripts. Y eso es mas peligroso que deja un puerto abierto, por que no solo esta abierto, sino tambien uno piensa que esta cerado. Mi sugerencia: Baja y installa fwbuilder ( www.fwbuilder.org ) en un estation de trabajo. Alli puedes definir que quires de tu contra-fuegos "logicamente". Una ves definida, puedes generar un ip-tables script que te implementa la definition logica del contra-fuegos. El script se copia a tu contra-fuegos, y se corre. Si no sos experto en ip-tables, esto es mas seguro , porque el contra-fuegos te hara lo que quires, y no lo que le dijistes (que muchas veces es una cosa muy destinta)! Jerry On Tuesday 31 January 2006 02.11, Carlos E. R. wrote:
Esto es un mensaje de Maxwell Draven, que por algún motivo parece que no puede enviar a la lista y me ha pedido que se lo envíe yo.
---------- Forwarded message ----------
Tengo el siguiente problemilla: Tengo un cortafuegos con una direccion IP publica y unos servidores (FTP, Correo, Web, etc) con direcciones IP privadas ... quiero que cuando alguien busque algun puerto/servicio desde la Internet, el servidor "interno" (segun sea) responda la peticion .
Para ello (siguiendo manuales e instrucciones sobre iptables) tengo lo siguiente:
iptables - t nat -A PREROUTING -d IP_PUBLICA -j DNAT -- to IP_PRIVADA iptables - t nat -A POSTROUTING -s IP_PRIVADA -j SNAT -- to IP_PRIVADA
Luego:
iptables -A FORWARD -d IP_PRIVADA
Esto es lo que he dejado despues de muchos quita/pone de eth0 y eth1 que he hecho sin comprender bien su papel. Por cierto, eth0 es la que da el acceso a la Internet y eth1 tiene una IP interna
Es el tercer dia que intento que esto me salga, en vista que no me ha funcionado, recurro a sus conocimientos.
Quedo atento a sus respuestas/comentarios/sugerencias.
Cordialmente,
Cuervo Linuxero
participants (6)
-
Carlos E. R. -
Freddy Arteaga -
Jerry Westrick -
jose maria -
Maxwell Draven -
Victor Hugo dos Santos