Connessioni OpenVPN ridondanti con routing Linux avanzato su una rete inaffidabile

Attualmente vivo in un paese che blocca molti siti Web e ha connessioni di rete inaffidabili con il mondo esterno. Ho due endpoint OpenVPN (diciamo: vpn1 e vpn2) su server Linux che utilizzo per aggirare il firewall. Ho pieno accesso a questi server. Funziona abbastanza bene, ad eccezione dell'elevata perdita di pacchetti sulle mie connessioni VPN. Questa perdita di pacchetti varia tra l'1% e il 30% a seconda del tempo e sembra avere una bassa correlazione, il più delle volte sembra casuale.

Sto pensando di configurare un router di casa (anche su Linux) che mantenga le connessioni OpenVPN a entrambi gli endpoint e invii due pacchetti tutti i due, a entrambi gli endpoint. vpn2 invierebbe tutti i pacchetti da casa a vpn1. Il traffico di ritorno verrebbe inviato sia direttamente da vpn1 a casa, sia tramite vpn2.

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

Per chiarezza: tutti i pacchetti tra home e il proxy HTTP saranno duplicati e inviati su percorsi diversi, per aumentare le probabilità che uno di essi arrivi. Se arrivano entrambi, il primo secondo può essere scartato silenziosamente.

L'uso della larghezza di banda non è un problema, sia sul lato home che sul lato endpoint. vpn1 e vpn2 sono vicini l'uno all'altro (ping 3ms) e hanno una connessione affidabile.

Qualche suggerimento su come raggiungere questo obiettivo utilizzando le politiche di routing avanzate disponibili in Linux?

Utilizzare l'infrastruttura di collegamento sul lato "home" e "vpn1" e in particolare con l'impostazione mode = 3 che trasmette il traffico su tutte le interfacce che appartengono a un legame.

Per ulteriori informazioni su come configurare il bonding, consultare l'ottimo manuale su http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.37.y.git;a=blob;f = Documentation / networking / bonding.txt; h = 5dc638791d975116bf1a1e590fdfc44a6ae5c33c; hb = TESTA

Ho usato la risposta fornita da @ user48116 e funziona come un incantesimo. L'installazione è in realtà abbastanza semplice!

NOTA : ho implementato questo con due connessioni a un solo server, poiché questo ha già risolto il problema per me. Se si desidera provare una configurazione con due server, il modo più semplice è probabilmente quello di utilizzare il port forwarding per inoltrare la porta UDP dal secondo server al primo e utilizzare la stessa ricetta descritta qui. Non l'ho provato io stesso però.

Innanzitutto, assicurati di avere un kernel 2.6 con supporto di bonding (predefinito in tutte le distribuzioni moderne) e di avere ifenslave installato.

Quindi, inseriscilo nel tuo /etc/rc.local o in qualsiasi altro posto che preferisci, ma assicurati che venga eseguito prima che openvpn venga avviato (perché tenterà di legare a bond0):

Cliente:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.2 netmask 255.255.255.0 up

Puoi aggiungere un po 'di routing se necessario qui, assicurati di fare anche tutto il routing corretto dall'altra parte.

route add -net 10.7.0.0/24 gw 10.10.0.1

Server:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.1 netmask 255.255.255.0 up

Crea uno script /etc/openvpn/tap-up.sh (e non dimenticare di contrassegnarlo come eseguibile con 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"

Quindi, aggiungi un bridge0a.conf e un bridge0b.conf a / etc / openvpn / insieme a una chiave condivisa. I file sono gli stessi per aeb, ad eccezione di una porta diversa (ad esempio, utilizzare 3002 per b). Sostituisci 11.22.33.44 con l'IP pubblico del tuo server.

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

Server:

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

Non dimenticare di modificare / etc / defaults / openvpn per assicurarti che le tue nuove configurazioni VPN siano avviate. Riavvia i computer o carica rc.local e riavvia openvpn manualmente.

Ora sei pronto per testare la tua configurazione:

# 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 tutto va bene e la linea è buona, vedrai quattro risposte per ogni pacchetto ICMP: i tuoi pacchetti vengono duplicati sul lato locale e le risposte a questi due pacchetti vengono nuovamente duplicate sul lato remoto. Questo non sarà un problema per le connessioni TCP, poiché TCP ignorerà semplicemente tutti i duplicati.

Questo è un problema per i pacchetti UDP, poiché spetta al software gestire i duplicati. Ad esempio, una query DNS produrrà quattro risposte anziché le due previste (e utilizzerà quattro volte la larghezza di banda normale per la risposta anziché due volte):

# 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)

In bocca al lupo!