On 04/27/2011 12:09 AM, carlopmart wrote:
On 04/26/2011 10:59 PM, Camaleón wrote:
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,
Todo ok, pero hay una pega. Estás asginando ip aliases "al modo antiguo". Si asignas las ip alias con la suite iproute2 (que creo que debian lo puede hacer), el invento no funciona.
Mira, te pongo de ejemplo otro host que tengo utilizando ip alias con iproute2:
[root@prodclunode05 ~]# ip addr 1: lo:
mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:50:56:0c:86:0a brd ff:ff:ff:ff:ff:ff inet 172.25.100.4/28 scope global eth0 inet6 fe80::250:56ff:fe0c:860a/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:50:56:28:c8:dc brd ff:ff:ff:ff:ff:ff inet 172.25.50.15/27 brd 172.25.50.31 scope global eth1 inet 172.25.50.22/27 scope global secondary eth1 inet 172.25.50.24/27 scope global secondary eth1 inet 172.25.50.16/27 scope global secondary eth1 inet6 fe80::250:56ff:fe28:c8dc/64 scope link valid_lft forever preferred_lft forever ... y la salida del comando ifconfig:
[root@prodclunode05 ~]# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:56:0C:86:0A inet addr:172.25.100.4 Bcast:0.0.0.0 Mask:255.255.255.240 inet6 addr: fe80::250:56ff:fe0c:860a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:27956 errors:0 dropped:0 overruns:0 frame:0 TX packets:18278 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:71128036 (67.8 MiB) TX bytes:6875844 (6.5 MiB)
eth1 Link encap:Ethernet HWaddr 00:50:56:28:C8:DC inet addr:172.25.50.15 Bcast:172.25.50.31 Mask:255.255.255.224 inet6 addr: fe80::250:56ff:fe28:c8dc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:863 errors:0 dropped:0 overruns:0 frame:0 TX packets:1028 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:88650 (86.5 KiB) TX bytes:174562 (170.4 KiB)
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:4060 errors:0 dropped:0 overruns:0 frame:0 TX packets:4060 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:546184 (533.3 KiB) TX bytes:546184 (533.3 KiB)
Las ip alias, en el caso de usar el comando ifconfig, ni aparecen, y no, no es un error ... (Las ips de eth0 no entran en juego, porque acceden a una cabina iSCSI).
Como verás lo que has probado, no funcionará porque cualquier ruta que insertes apuntará al default gateway de eth0 con salida de tráfico la propia eth0, no existen ni eth0:1 ni eth0:2, etc. He ahí el problema.
¿Y porque es así en mi caso? Porque tanto en el host que indico en el email como el que os pongo de ejemplo, es un cluster de 4 nodos cada uno. Para prestar el servicio, se utilizan las "ip flotantes" y estas se asignan via iproute2, no se generan interfaces eth0:X ya que no se utiliza el comando ifconfig. Si pruebas, verás que con iproute2 no podrás generar esas interfaces.
De todas formas, la solución que he indicado no me ha servido de gran cosa, porque hoy mismo he tenido que añadir otro servicio al cluster basado en mysql y como podrás ver todo se me va al traste.
¿Solución? He modificado las ACLs del host mysql e insertado las ip primarias de todos y cada uno de los nodos del cluster como ips de acceso (en el ejemplo esa ip primaria es la 172.25.50.15). Aparte he añadido dicha regla iptables a todos los nodos para forzar siempre la misma ip de salida cuando se ejecuta el comando mysql.
El "invento" sirve para cualquier comando/servicio, etc que no sea capaz de bindar a una ip específica.
Saludos.
Perdón, substituye todo lo que digo de eth0 por eth1, par ajustarme al ejemplo. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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