Aspectos a considerar em um módulo OpenVOS com múltiplas conexões

Um sistema multihomed é um sistema com várias interfaces IP. Essas interfaces podem estar na mesma sub-rede ou em sub-redes diferentes. Hoje, gostaria de abordar protocolos como o FTP e o NDMP. Em ambos os protocolos, o servidor aceita uma conexão do cliente e, em seguida, estabelece uma nova conexão de volta com o cliente. Em um sistema multihomed, é essa 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 utilizado para retornar ao cliente.

Por exemplo, considerando as seguintes interfaces e tabela de roteamento

Um cliente com o endereço IP 10.1.1.1 se conecta a 172.16.1.50; chamemos essa conexão de “A”. Para enviar pacotes para 10.1.1.1, o módulo deve usar o gateway padrão, que está na rede 192.168.77.0/24 e, portanto, utiliza a interface 192.168.77.50. Ele usa essa interface para TODO o tráfego destinado a 10.1.1.1 na conexão “A”; mas o endereço IP no cabeçalho TCP será 172.16.1.50, pois esse é o endereço IP ao qual o cliente está conectado na conexão A. No entanto, quando o módulo cria uma nova conexão com 10.1.1.1, a conexão “B”, o STCP escolherá, por padrão, 192.168.77.50 como o endereço IP de origem. Ele faz isso porque essa é a interface à qual o gateway está conectado. O aplicativo pode substituir essa configuração, mas nem o FTP nem o NDMP o fazem.

A principal consideração é a configuração dos firewalls e das listas de acesso nos roteadores. Se o firewall do cliente ou as ACLs do roteador estiverem configurados para permitir apenas conexões provenientes de 172.16.1.50, a conexão proveniente de 192.168.1.50 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 reconfigurar o firewall e as listas de acesso do roteador para permitir 192.168.1.50.

Você pode testar isso com o seguinte script

É claro que você deve substituir 10.1.1.1 pelo endereço IP real do cliente e 172.16.1.50 pelo endereço IP ao qual o cliente se conecta. A porta N deve ser uma porta que esteja aberta no cliente e seja permitida pelos firewalls e pelas listas de controle de acesso (ACLs) do roteador.

A primeira tentativa de conexão utilizará o endereço IP padrão; a segunda utilizará 172.16.1.50. Se a primeira tentativa de conexão atingir o tempo limite (o que levará cerca de um minuto) ou retornar imediatamente com um erro de conexão recusada, MAS a segunda tentativa funcionar (tudo o que você verá será o prompt “stcp:”), você pode ter certeza de que há um problema com o firewall ou com a lista de controle de acesso (ACL) do roteador que precisará ser resolvido.