Um sistema multihomed é um sistema com múltiplas interfaces IP. Estas interfaces podem estar na mesma ou em sub-redes diferentes. Hoje eu quero considerar protocolos como FTP e NDMP. Em ambos os protocolos, o servidor aceita uma conexão do cliente e então faz uma nova conexão de volta para o cliente. Em um sistema multihomed, é esta nova conexão que causa todos os problemas.
Em ambos os protocolos, o endereço IP de origem NÃO se baseia no endereço IP ao qual o cliente se conectou originalmente. Em vez disso, ele se baseia na interface associada ao gateway que é usado para voltar para o cliente.
Por exemplo, dadas as seguintes interfaces e tabela de roteamento
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:57Um cliente com o endereço IP 10.1.1.1.1 se conecta a 172.16.1.50, chama esta conexão de "A". Para enviar pacotes para 10.1.1.1.1 o módulo deve utilizar o gateway padrão que está na rede 192.168.77.0/24 e, portanto, utiliza a interface 192.168.77.50. Ele usa esta interface para TODO o tráfego até 10.1.1.1 para a conexão "A"; mas o endereço IP no cabeçalho TCP será 172.16.1.50, porque este é o endereço IP ao qual o cliente está conectado na conexão A . Entretanto, quando o módulo cria uma nova conexão para 10.1.1.1.1, conexão "B", STCP escolherá por padrão 192.168.77.50 como o endereço IP de origem. Ele faz isto porque esta é a interface que o gateway também está anexado. A aplicação pode anular isto, mas nem o FTP nem o NDMP o fazem.
A principal consideração é a configuração de firewalls e listas de acesso em roteadores. Se o firewall do cliente ou as ACLs do roteador estiver configurado para permitir somente conexões a partir de 172.16.1.50, a conexão a partir de 192.168.1.50 irá falhar. A solução é criar uma rota para 10.1.1.1 usando um roteador na sub-rede 172.16.1.0/24 (claro que o roteador selecionado deve ser capaz de alcançar 10.1.1.1) ou o firewall e as listas de acesso do roteador, mas ser reconfigurado para permitir 192.168.1.50.
Você pode testar isso com o seguinte roteiro
stcp_callssocketconnect -name 10.1.1.1 -port Nsocketbind -name 172.16.1.50 -port 0connect -name 10.1.1.1 -port NÉ claro que o cliente deve substituir 10.1.1.1 pelo endereço IP real do cliente e 172.16.1.50 pelo endereço IP que o cliente também conecta. A porta N deve ser alguma porta aberta no cliente e permitida pelos firewalls e roteadores ACLs.
A primeira conexão usará o endereço IP padrão, a segunda conexão usará 172.16.1.50. Se o primeiro tempo de conexão terminar (levará cerca de um minuto) ou retornar imediatamente com um erro de conexão recusado MAS a segunda conexão funcionar (tudo que você verá é o prompt "stcp:") você pode ter certeza de que existe um firewall ou roteador ACL problema que precisará ser resolvido.