Coisas a considerar em um Módulo Multihomed OpenVOS

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

Um 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

É 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.