Un sistema multihomed es un sistema con múltiples interfaces IP. Estas interfaces pueden estar en la misma o en diferentes subredes. Hoy quiero considerar protocolos como FTP y NDMP. En ambos protocolos el servidor acepta una conexión del cliente y luego hace una nueva conexión de vuelta al cliente. En un sistema multihomed es esta nueva conexión la que causa todos los problemas.
En ambos protocolos la dirección IP de origen NO se basa en la dirección IP a la que el cliente se conectó originalmente. En cambio se basa en la interfaz asociada a la puerta de enlace que se utiliza para volver al cliente.
Por ejemplo, dadas las siguientes interfaces y tabla de rutas
ifconfig -all
Number of interface(s) under IP: 5
%phx_vos#loop.m16: <UP, LOOPBACK, RUNNING> 127.0.0.1 netmask 0xff000000
%phx_vos#enetA: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> 172.16.1.50 netmask 0xffffff00 broadcast 172.16.1.255
%phx_vos#enetZ: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> 192.168.77.50 netmask 0xffffff00 broadcast 164.152.77.255
ready 15:33:51
route print
Default Gateway: 192.168.77.1ready 15:33:57Un cliente con la dirección IP de 10.1.1.1 se conecta al 172.16.1.50, llama a esta conexión "A". Para enviar paquetes a 10.1.1.1, el módulo debe utilizar la pasarela por defecto que se encuentra en la red 192.168.77.0/24 y, por lo tanto, utiliza la interfaz 192.168.77.50. Utiliza esta interfaz para TODO el tráfico hacia 10.1.1.1 para la conexión "A"; pero la dirección IP en el encabezado TCP será 172.16.1.50, porque es la dirección IP a la que se conecta el cliente en la conexión A . Sin embargo, cuando el módulo crea una nueva conexión a 10.1.1.1, conexión "B", STCP elegirá por defecto 192.168.77.50 como la dirección IP de origen. Lo hace porque esa es la interfaz a la que también está conectada la pasarela. La aplicación puede anular esto pero ni FTP ni NDMP lo hacen.
La principal consideración es la configuración de los cortafuegos y las listas de acceso en los enrutadores. Si el cortafuegos del cliente o las ACLs del enrutador están configuradas para permitir sólo conexiones desde 172.16.1.50 la conexión desde 192.168.1.50 fallará. La solución es crear una ruta a 10.1.1.1 utilizando un enrutador en la subred 172.16.1.0/24 (por supuesto, el enrutador seleccionado debe ser capaz de llegar a 10.1.1.1) o las listas de acceso del cortafuegos y del enrutador, pero deben ser reconfiguradas para permitir 192.168.1.50.
Puedes probar esto con el siguiente guión
stcp_callssocketconnect -name 10.1.1.1 -port Nsocketbind -name 172.16.1.50 -port 0connect -name 10.1.1.1 -port NPor supuesto, debe reemplazar 10.1.1.1 con la dirección IP real del cliente y 172.16.1.50 con la dirección IP que el cliente también conecta. El puerto N debe ser algún puerto que esté abierto en el cliente y que esté permitido por los cortafuegos y las ACLs del router.
La primera conexión usará la dirección IP por defecto, la segunda conexión usará 172.16.1.50. Si la primera conexión caduca (tardará un minuto más o menos) o regresa inmediatamente con un error de conexión rechazada PERO la segunda conexión funciona (todo lo que verá es el aviso "stcp:") puede estar seguro de que hay un problema de ACL del cortafuegos o del router que tendrá que ser resuelto.
Empresa