Conexões Redundantes do OpenVPN com o roteamento avançado do Linux em uma rede não confiável

Question

Atualmente, estou vivendo em um país que bloqueia muitos sites e possui conexões de rede não confiáveis para o mundo externo. Eu tenho dois pontos de extremidade OpenVPN (digamos: vpn1 e vpn2) em servidores Linux que eu uso para contornar o firewall. Eu tenho acesso total a esses servidores. Isso funciona muito bem, exceto pela alta perda de pacotes nas minhas conexões VPN. Esta 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 mantém conexões OpenVPN para os dois pontos de extremidade e envia todos os pacotes duas vezes para os dois pontos de extremidade. A vpn2 enviaria todos os pacotes de casa para a vpn1. O retorno do tráfego seria enviado diretamente da vpn1 para a casa, e também através da vpn2.

       +------------+
       |    home    |
       +------------+
        |          |
        | OpenVPN  |
        |  links   |
        |          |
     ~~~~~~~~~~~~~~~~~~ unreliable connection
        |          |
+----------+   +----------+
|   vpn1   |---|   vpn2   |
+----------+   +----------+
        |
       +------------+
       | HTTP proxy |
       +------------+
             |
         (internet)

Para maior clareza: todos os pacotes entre casa e o proxy HTTP serão duplicados e enviados por diferentes caminhos, para aumentar as chances de um deles chegar. Se ambos chegarem, o primeiro segundo pode ser descartado silenciosamente.

O uso de largura de banda não é um problema, tanto no lado da residência quanto no lado do terminal. A vpn1 e a vpn2 estão próximas umas das outras (3ms ping) e possuem uma conexão confiável.

Quaisquer sugestões sobre como isso poderia ser alcançado usando as políticas de roteamento avançadas disponíveis no Linux?

    

Answer 1

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 único servidor, já que 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 não testei isso sozinho.

Primeiro, verifique se você tem um kernel 2.6 com suporte de ligação (padrão em todas as distribuições modernas) e se o ifenslave está instalado.

Em seguida, coloque isso em seu /etc/rc.local ou em qualquer outro lugar que preferir, mas certifique-se de que ele é executado antes que o openvpn seja iniciado (porque ele tentará se vincular ao bond0):

Cliente:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.2 netmask 255.255.255.0 up

Você poderia adicionar algum roteamento se necessário aqui, mas certifique-se de fazer todo o roteamento adequado do outro lado.

route add -net 10.7.0.0/24 gw 10.10.0.1

Servidor:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.1 netmask 255.255.255.0 up

Crie um script /etc/openvpn/tap-up.sh (e não esqueça de marcá-lo como executável com chmod a + x tap-up.sh):

#!/bin/sh
# called as: cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask [ init | restart ]
ifenslave bond0 "$1"

Em seguida, adicione um bridge0a.conf e o bridge0b.conf ao / etc / openvpn / junto com uma chave compartilhada. Os arquivos são os mesmos para aeb, exceto por uma porta diferente (por exemplo, use 3002 para b). Substitua 11.22.33.44 pelo IP público do seu servidor.

Cliente:

remote 11.22.33.44
dev tap
port 3001
rport 3001
secret bridge.key
comp-lzo
verb 4
nobind
persist-tun
persist-key
script-security 2
up /etc/openvpn/tap-up.sh

Servidor:

local 11.22.33.44
dev tap
port 3001
lport 3001
secret bridge.key
comp-lzo
verb 4
script-security 2
up /etc/openvpn/tap-up.sh

Não se esqueça de editar o arquivo / etc / defaults / openvpn para garantir que suas novas configurações de VPN sejam iniciadas. Reinicie suas máquinas, ou carregue o rc.local e reinicie o openvpn manualmente.

Agora você está pronto para testar sua configuração:

# ping 10.10.0.1
PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data.
64 bytes from 10.10.0.1: icmp_req=1 ttl=64 time=50.4 ms
64 bytes from 10.10.0.1: icmp_req=1 ttl=64 time=51.1 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=1 ttl=64 time=51.1 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=1 ttl=64 time=51.1 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=2 ttl=64 time=52.0 ms
64 bytes from 10.10.0.1: icmp_req=2 ttl=64 time=52.2 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=2 ttl=64 time=53.0 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=2 ttl=64 time=53.1 ms (DUP!)
--- 10.10.0.1 ping statistics ---
2 packets transmitted, 2 received, +6 duplicates, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 50.428/51.786/53.160/0.955 ms

Se tudo correr bem e a linha estiver 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 em o lado remoto. Isso não será um problema para conexões TCP, porque o TCP simplesmente ignorará todas as duplicatas.

Este é um problema para os pacotes UDP, pois 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):

# tcpdump -i bond0 -n port 53
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:30:39.870740 IP 10.10.0.2.59330 > 10.7.0.1.53: 59577+ A? serverfault.com. (33)
13:30:40.174281 IP 10.7.0.1.53 > 10.10.0.2.59330: 59577 1/0/0 A 64.34.119.12 (49)
13:30:40.174471 IP 10.7.0.1.53 > 10.10.0.2.59330: 59577 1/0/0 A 64.34.119.12 (49)
13:30:40.186664 IP 10.7.0.1.53 > 10.10.0.2.59330: 59577 1/0/0 A 64.34.119.12 (49)
13:30:40.187030 IP 10.7.0.1.53 > 10.10.0.2.59330: 59577 1/0/0 A 64.34.119.12 (49)

Boa sorte!

    

Answer 2

Use a infraestrutura de ligação no lado 'home' e 'vpn1' e, especificamente, com a configuração mode = 3 que difunde o tráfego em todas as interfaces que pertencem a uma ligação.

Para mais informações sobre como configurar a ligação, veja o excelente manual em link