Re: Interfaces virtuales requieren puerta de enlace tambien?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 PedroTron wrote: saludos. Estoy tratando de implementar un firewall con shorewall como tengo 3 direcciones publicas disponibles, deseo hacer uso de las mismas. Ya tengo todas las IPs asignadas a mis servidor usando dispositivos virtuales eth0= 200.1.2.2 eth0:0 = 200.1.2.3 eth0:1 = 200.1.2.4 Desde internet puedo acceder por cualquiera de las tres direcciones. auto eth0 iface eth0 inet static address 200.1.2.2 netmask 255.255.255.248 gateway 200.1.2.1 auto eth0:0 iface eth0:0 inet static address 200.1.2.3 netmask 255.255.255.248 #gateway 200.1.2.1 auto eth0:1 iface eth0:1 inet static address 200.1.2.4 netmask 255.255.255.248 #gateway 200.1.2.1 Mi problema esta cuando intento publicar algun servicio de un servidor detras del firewall usando una IP publica de las virtuales Con la siguiente regla de shorewall busco publicar el escritorio remoto de un equipo de mi red local usando la segunda ip publica disponible (200.1.2.3) pero no funciona. Analizando con snort encuentro que el paquete si llega la estacion destino, pero no regresa. DNAT:infoallLAN:172.16.10.6tcp3389-200.1.2.3 Si uso la misma regla sin indicar la IP publica, funciona correctamente pues accede por la primera ip publica 200.1.2.2 Lo unico que encuentro distinto en las configuraciones de red, es que solo la primera ip publica tiene declarada la puerta de enlace, mientras que las otras no. Inicialmente tenia todas tres con la puerta de enlace (que es la misma), pero cuando el servidor se reinicio por problemas electricos ya no podiamos acceder a internet. Comente las puertas de enlace de las dos interfaces virtuales (eth0:0 y eth0:1) y nuevamente funciono el acceso a internet. Puede ser esa falta de puerta de enlace en las virtuales lo que me falta? no se supone que si no tienen puerta de enlace usaran la predeterminada (o sea la de eth0)? Si las activo, puedo quedar sin internet; si no las activo, no puedo reenviar nada con las otras IPs. La única vez que tuve el mismo escenario que el tuyo me encontré conque por mas virtuales que sean las interfaces que levantas con ifconfig, las reglas NAT sólo aplican a eth0, no a las eth0:X. Yo uso Firehol para administrar iptables (nunca aprendí iptables), y no tuve mas alternativa que utilizar iproute para declarar las distintas IPs públicas sin depender de las interfaces virtuales de ifconfig. Tienes el sitio oficial [0] en donde encontrarás la documentación oficial de iproute, tambien tienes un pdf traducido al español [1] y por supuesto, seguir buscando en internet. Te sugiero compres el libro Encaminamiento regulado con Linux [2], lo mejor que he leido para aprender iproute. Saludos [0] http://lartc.org/ [1] http://www.gulic.org/almacen/lartc/lartc.pdf [2] http://www.agapea.com/libros/Encaminamiento-regulado-con-Linux-isbn-8420530174-i.htm - -- La Voluntad es el único motor de nuestros logros http://ngen.com.ar/blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkwFRKsACgkQN6aCDIWi44B4ogCfT5uT6sZxrKtfArjaYtOmRwee lYcAoM64Q6AoHEvh3IyOx1Dza9p22evH =jhR5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c0544ab.50...@ngen.com.ar
Interfaces virtuales requieren puerta de enlace tambien?
saludos. Estoy tratando de implementar un firewall con shorewall como tengo 3 direcciones publicas disponibles, deseo hacer uso de las mismas. Ya tengo todas las IPs asignadas a mis servidor usando dispositivos virtuales eth0= 200.1.2.2 eth0:0 = 200.1.2.3 eth0:1 = 200.1.2.4 Desde internet puedo acceder por cualquiera de las tres direcciones. auto eth0 iface eth0 inet static address 200.1.2.2 netmask 255.255.255.248 gateway 200.1.2.1 auto eth0:0 iface eth0:0 inet static address 200.1.2.3 netmask 255.255.255.248 #gateway 200.1.2.1 auto eth0:1 iface eth0:1 inet static address 200.1.2.4 netmask 255.255.255.248 #gateway 200.1.2.1 Mi problema esta cuando intento publicar algun servicio de un servidor detras del firewall usando una IP publica de las virtuales Con la siguiente regla de shorewall busco publicar el escritorio remoto de un equipo de mi red local usando la segunda ip publica disponible (200.1.2.3) pero no funciona. Analizando con snort encuentro que el paquete si llega la estacion destino, pero no regresa. DNAT:infoallLAN:172.16.10.6tcp3389-200.1.2.3 Si uso la misma regla sin indicar la IP publica, funciona correctamente pues accede por la primera ip publica 200.1.2.2 Lo unico que encuentro distinto en las configuraciones de red, es que solo la primera ip publica tiene declarada la puerta de enlace, mientras que las otras no. Inicialmente tenia todas tres con la puerta de enlace (que es la misma), pero cuando el servidor se reinicio por problemas electricos ya no podiamos acceder a internet. Comente las puertas de enlace de las dos interfaces virtuales (eth0:0 y eth0:1) y nuevamente funciono el acceso a internet. Puede ser esa falta de puerta de enlace en las virtuales lo que me falta? no se supone que si no tienen puerta de enlace usaran la predeterminada (o sea la de eth0)? Si las activo, puedo quedar sin internet; si no las activo, no puedo reenviar nada con las otras IPs. Como han manejado ustedes casos como este? Muchas gracias por su paciencia y ayuda. Hasta pronto.
Re: Interfaces virtuales requieren puerta de enlace tambien?
El 29 de mayo de 2010 08:33, PedroTron porsiunc...@gmail.com escribió: saludos. Estoy tratando de implementar un firewall con shorewall como tengo 3 direcciones publicas disponibles, deseo hacer uso de las mismas. Ya tengo todas las IPs asignadas a mis servidor usando dispositivos virtuales eth0= 200.1.2.2 eth0:0 = 200.1.2.3 eth0:1 = 200.1.2.4 Desde internet puedo acceder por cualquiera de las tres direcciones. auto eth0 iface eth0 inet static address 200.1.2.2 netmask 255.255.255.248 gateway 200.1.2.1 auto eth0:0 iface eth0:0 inet static address 200.1.2.3 netmask 255.255.255.248 #gateway 200.1.2.1 auto eth0:1 iface eth0:1 inet static address 200.1.2.4 netmask 255.255.255.248 #gateway 200.1.2.1 Mi problema esta cuando intento publicar algun servicio de un servidor detras del firewall usando una IP publica de las virtuales Con la siguiente regla de shorewall busco publicar el escritorio remoto de un equipo de mi red local usando la segunda ip publica disponible (200.1.2.3) pero no funciona. Analizando con snort encuentro que el paquete si llega la estacion destino, pero no regresa. DNAT:infoallLAN:172.16.10.6tcp3389-200.1.2.3 Si uso la misma regla sin indicar la IP publica, funciona correctamente pues accede por la primera ip publica 200.1.2.2 Lo unico que encuentro distinto en las configuraciones de red, es que solo la primera ip publica tiene declarada la puerta de enlace, mientras que las otras no. Inicialmente tenia todas tres con la puerta de enlace (que es la misma), pero cuando el servidor se reinicio por problemas electricos ya no podiamos acceder a internet. Comente las puertas de enlace de las dos interfaces virtuales (eth0:0 y eth0:1) y nuevamente funciono el acceso a internet. Puede ser esa falta de puerta de enlace en las virtuales lo que me falta? no se supone que si no tienen puerta de enlace usaran la predeterminada (o sea la de eth0)? Si las activo, puedo quedar sin internet; si no las activo, no puedo reenviar nada con las otras IPs. Como han manejado ustedes casos como este? Muchas gracias por su paciencia y ayuda. Hasta pronto. que mas, mira yo no uso shorewall yo uso iptables y lo que tenes que hacer si estas intentando que una IP privada salga a una IP publica es enmascaramiento. seria algo así: todo lo que venga a la IP 200.1.2.3 al puerto 5900(VNC) enviarlo a la ip 172.16.10.6 iptables -A PREROUTING -t NAT -i eth0 -d 200.1.2.3/24 -p tcp --dport 5900 -j DNAT --to-destination 172.16.10.6:puerto iptables -A POSRUTING -t NAT -i eth1 -j MASQUERADE supongo que tu eth1 es tu interfaz LAN y no importa la puerta de enlace ya que esta es única para el kernel. $netstat -rn lo que podes hacer es agregar las rutas para las interfaces $route add -net 200.1.2.0 dev eth0 $route add -host 200.1.2.2 dev eth0 $route add -host 200.1.2.3 dev eth0:0 $route add -host 200.1.2.4 dev eth0:1 podes mirar la tabla de enrutamiento con netstat -rm pa' que veas que todos tienen la misma puerta de enlace. saludo, -- Jorge A. Toro Hoyos Ing. Telemático. CumbiaTIC, Dir. División de Informática COR, Ing. NOC Anditel (Proyecto COMPARTEL). Esp. GNU/Linux. Esp. Desarrollo de Software. -- 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/.
