Marcelo Goias
Também gostaria de ler sua opinião para saber porque não aconselha essa solução.
Versão Imprimível
Marcelo Goias
Também gostaria de ler sua opinião para saber porque não aconselha essa solução.
Bom dia,
o problema maior de links de operadoras diferentes é que eles usam gatewaies diferentes, rotas diferentes e DNS diferentes (menos importante, mas influi). Exemplo bem simples: se você for fazer uma viagem e escolher um intinerário diferente da primeira viagem você encontrará coisas diferentes e pessoas diferentes no novo caminho. Isso ocorre com trafégo de dados: rotas diferentes dá "desencontro" de pacotes e aumentará o tráfego na rede, além de problema de latência, pois no procotolo TC/IP há reenvio de pacotes quando os anteriores são perdidos. Em bancos principalmente em que há mudanças de portas (da 80 para a 443, por exemplo) isso é muito problemático, pois o requisito segurança dos bancos poderá desconectar o navegador por interpretar tentativas na capturas de dados e informações sigilosas. Um "racker" pega uma conexão que é de outro, um proxy mal configurado por exemplo, e tenta furar sistemas de seguranças, pois se as suas tentativas forem descobertas o internauta invadido poderá ser identificado como o invasor, enquanto que o verdadeiro invasor geralmente sai "ileso" da tentativa, pois não foi descoberto por estar usando a identidade de outro.
Por esse motivo os sistemas dos bancos desconectam navegadores que mudam de rotas e de IPs, pois links diferentes tem rotas, gateway e IPs diferentes.
Links de duas ou operadoras são recomendáveis quando se quer dar ou ter garantia de 100% de funcionamento 24hs por dia, 365 dias por ano, etc.
Resumindo: pega-se dois links, 1 como principal e o outro como secundário. Caso um caia o outro segurará até que o principal volte, ou seja, uma espécie de reserva ou sombra. Para somar links e ter incremento de velocidade jamais funcionará corretamente. Serviço como esse não pode ser vendido a terceiros, pois não há garantia de funcionamento.
Compreensível a explicação, mas não quer dizer que não deve ser estudada e implementada.
Como você bem disse, na primeira mensagem, tem que ser muito bem estruturada e implementada, prevendo-se rotas fixas para esses casos (bancos, etc).
Se for fazer um balanceamento por rota fixa (e separando clientes para usar determinada rota) e não por NTH, creio que os problemas podem ser maiores.
Ainda indico esse tipo de balanceamento, que ao meu ver, é suficientemente eficiente.
Não é a solução 100% ideal, mas diante do que o MK oferece, é ótimo.
Ola MarceloGOIAS,
OBRIGADO pela sua resposta.
Mas... no contexto do topico apresentado... qual sua opiniao (digo: continuidade no seu raciocinio inicial).
-------------------------
Com respeito a comunicação TCP/IP (2way-handshake)... NORMAL. E isso permite que pacotes fluam em rotas diferentes... e é por isso que existem sequence-numbers em cada sentido da comunicação/conexão.
Com respeito a site de bancos... o IP é verificado para cada conexão/protocolo. Ou seja: conexão na porta 443... um IP source fixo. Isso para garantir que a conexão está partindo do mesmo usuario/cliente do banco. OK.
--------------------------
Não entendi mesmo foi o raciocinio referente ao POST iniciado por "Luciana-Martins". Se puder dar continuidade... OBRIGADO.
Abraços,
Agora corrigi, é que havia dado um export, mas as regras estavam desabilitadas pq não funcionaram!
O que ocorre é que não gera trafego nas regras de nat, e na mangle, quase nada! Resumindo, não há navegação!
Lembrando que minha interface dos clientes é um concentrador PPPOE, sem endereçamento!!
Obrigada