Atualmente, moro em um país que bloqueia muitos sites e possui conexões de rede não confiáveis com o mundo exterior. Eu tenho dois pontos de extremidade OpenVPN (digamos: vpn1 e vpn2) nos servidores Linux que eu uso para contornar o firewall. Eu tenho acesso total a esses servidores. Isso funciona muito bem, exceto pela grande perda de pacotes nas minhas conexões VPN. Essa perda de pacotes varia entre 1% e 30%, dependendo do tempo e parece ter uma baixa correlação, na maioria das vezes parece aleatória.
Estou pensando em configurar um roteador doméstico (também no Linux) que mantenha conexões OpenVPN para os dois pontos finais e envie todos os pacotes duas vezes, para os dois pontos finais. O vpn2 enviaria todos os pacotes de casa para o vpn1. O tráfego de retorno seria enviado diretamente do vpn1 para casa e também pelo vpn2.
+------------+
| home |
+------------+
| |
| OpenVPN |
| links |
| |
~~~~~~~~~~~~~~~~~~ unreliable connection
| |
+----------+ +----------+
| vpn1 |---| vpn2 |
+----------+ +----------+
|
+------------+
| HTTP proxy |
+------------+
|
(internet)
Para maior clareza: todos os pacotes entre o servidor doméstico e o proxy HTTP serão duplicados e enviados por caminhos diferentes, para aumentar as chances de um deles chegar. Se os dois chegarem, o primeiro segundo poderá ser descartado silenciosamente.
O uso da largura de banda não é um problema, tanto no lado inicial quanto no terminal. vpn1 e vpn2 estão próximos um do outro (ping de 3ms) e possuem uma conexão confiável.
Alguma dica de como isso pode ser alcançado usando as políticas de roteamento avançadas disponíveis no Linux?
fonte
Eu usei a resposta fornecida pelo @ user48116 e funciona como um encanto. A configuração é realmente muito fácil!
NOTA : Eu implementei isso com duas conexões para apenas um servidor, pois isso já resolveu o problema para mim. Se você quiser tentar uma configuração com dois servidores, a maneira mais fácil é provavelmente usar o encaminhamento de porta para encaminhar a porta UDP do segundo servidor para o primeiro e usar a mesma receita descrita aqui. Eu ainda não testei isso.
Primeiro, verifique se você possui um kernel 2.6 com suporte para ligação (padrão em todas as distribuições modernas) e se o ifenslave está instalado.
Em seguida, coloque isso no seu /etc/rc.local ou em qualquer outro lugar que você preferir, mas certifique-se de que seja executado antes do openvpn ser iniciado (porque ele tentará vincular ao bond0):
Cliente:
Você pode adicionar algum roteamento, se necessário, aqui; certifique-se de fazer todo o roteamento adequado do outro lado também.
Servidor:
Crie um script /etc/openvpn/tap-up.sh (e não se esqueça de marcá-lo como executável com chmod a + x tap-up.sh):
Em seguida, adicione bridge0a.conf e bridge0b.conf em / etc / openvpn / junto com uma chave compartilhada. Os arquivos são os mesmos para aeb, exceto para uma porta diferente (por exemplo, use 3002 para b). Substitua 11.22.33.44 pelo IP público do seu servidor.
Cliente:
Servidor:
Não se esqueça de editar / etc / defaults / openvpn para garantir que suas novas configurações de VPN sejam iniciadas. Reinicialize suas máquinas ou carregue o rc.local e reinicie o openvpn manualmente.
Agora você está pronto para testar sua configuração:
Se tudo correr bem e a linha for boa, você verá quatro respostas para cada pacote ICMP: seus pacotes são duplicados no lado local e as respostas a esses dois pacotes são duplicadas novamente no lado remoto. Isso não será um problema para conexões TCP, porque o TCP simplesmente ignorará todas as duplicatas.
Esse é um problema para os pacotes UDP, já que cabe ao software lidar com duplicatas. Por exemplo, uma consulta DNS produzirá quatro respostas em vez das duas esperadas (e usará quatro vezes a largura de banda normal para a resposta em vez de duas vezes):
Boa sorte!
fonte