El Mon, 25 Apr 2011 20:37:14 +0200, carlopmart escribió:
On 04/25/2011 07:12 PM, carlopmart wrote:
(...)
Hum... ¿Y definiendo una ruta para interfaz, sería factible?
Algo del tipo "el tráfico que vaya hacia 172.17.3.3 que salga por eth0:1"
Lo que comentas es utilizar iproute2 + iptables. Sí, eso es factible, pero corro el riesgo de complicar y mucho la estructura de ese servidor, y puede que no me valga la pena ... pero lo puedo mirar.
Bueno, pues al final ha sido algo tan "chorras" como poner esta regla única de iptables (no he necesitado iproute2 para nada):
iptables -t nat -A POSTROUTING -o eth1 -d 172.17.3.3 -p tcp --dport 3306 -j SNAT --to-source 172.21.2.2
Pues listo. Ahora comprobaré varios servicios y otros scripts para comprobar que no he "roto" nada.
En realidad me refería a algo más "mundano", manipulando la tabla de rutas. Ya sé que tu caso puede ser más complicado porque entran en juego otros factores pero esto no es tanto una respuesta para ti sino para mí, para comprobar que se puede forzar la salida del tráfico de red hacia un determinado host por la interfaz origen que se quiera, en lugar de la predeterminada. Pongo un ejemplo práctico (nota: esto es en una Debian por lo que los comandos o las salidas pueden diferir de las vuestras): Dadas las interfaces: root@debian:~# ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.163 Bcast:172.16.0.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe54:f3a2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4434 errors:0 dropped:0 overruns:0 frame:0 TX packets:3884 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2575081 (2.4 MiB) TX bytes:508718 (496.7 KiB) eth0:0 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.200 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth0:1 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.201 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:868 (868.0 B) TX bytes:868 (868.0 B) Y la tabla de rutas predeterminada: root@debian:~# ip ro 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0 Si ejecutamos un simple ping a cualquier equipo de la red, el tráfico sale por eth0 (con el parámetro -B podemos forzar el uso de una interfaz determinada, lo cual me viene muy bien para este ejemplo porque me permite ver cuál es la que está usando en cada momento): root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.163 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.354 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.402 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.407 ms --- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.354/0.387/0.407/0.032 ms Bien, si por lo que sea queremos que el ping (o cualquier otro comando) salga por una interfaz distinta (eth0:0, eth0:1, ethx, ethx:x...) podemos modificar la tabla de rutas para que cualquier paquete con destino al host especificado (en este caso 172.168.0.150) utilice la interfaz que nosotros queramos: root@debian:~# route add -host 172.16.0.150 dev eth0:0 root@debian:~# ip ro 172.16.0.150 dev eth0 scope link src 172.16.0.200 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0 Y al ejecutar el ping (y con la ayuda de -B) vemos que se ejecuta por la interfaz seleccionada (eth0:0): root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.200 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.516 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.137 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.415 ms --- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.137/0.356/0.516/0.160 ms Mola :-P La ventaja que tiene este sistema es que las rutas son dinámicas y se pueden crear/eliminar al vuelo y a conveniencia para que no altere el funcionamiento habitual de la red por lo que al terminar lo que sea que tengamos que hacer que requiera salir por una interfaz determinada para alcanzar un equipo concreto, sólo tenemos que eliminar la ruta: root@debian:~# route del -host 172.16.0.150 dev eth0:0 Y todo vuelve a la normalidad: root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.163 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.061 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.457 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.237 ms --- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 0.061/0.251/0.457/0.163 ms root@debian:~# ip ro 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0 Esa era la idea que tenía en mente y por lo que veo parece factible :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org