Collegamenti OpenVPN ridondanti con routing Linux avanzato su una networking non affidabile

Attualmente vivo in un paese che blocca molti siti web e ha connessioni di networking non affidabili al mondo esterno. Ho due endpoint OpenVPN (ad esempio: vpn1 e vpn2) sui server Linux che utilizzo per aggirare il firewall. Ho accesso completo a questi server. Questo funziona abbastanza bene, ad exception dell'elevata perdita di pacchetti sulle connessioni VPN. Questa perdita di pacchetti varia tra l'1% e il 30% a seconda del tempo e sembra avere una correlazione bassa, la maggior parte del tempo sembra random.

Sto pensando ad impostare un router di casa (anche su Linux) che mantiene le connessioni OpenVPN a entrambi gli endpoint e invia tutti i pacchetti due volte a entrambi gli endpoint. vpn2 invierebbe tutti i pacchetti da casa a vpn1. Il traffico di return verrà inviato sia direttamente da vpn1 a casa, sia anche tramite vpn2.

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

Per la chiarezza: tutti i pacchetti tra la casa e il proxy HTTP verranno duplicati e inviati su routes diversi, per aumentare le probabilità che uno di loro arriverà. Se entrambi arrivano, il primo secondo può essere scartato in silenzio.

L'utilizzo della width di banda non è un problema, sia sul lato domestico che sull'endpoint. vpn1 e vpn2 sono vicini tra loro (3ms ping) e hanno una connessione affidabile.

Qualche indicazione su come questo possa essere ottenuto utilizzando le politiche di routing avanzate disponibili in Linux?

  • I nuovi ospiti KVM non possono accedere all'esterno della LAN
  • Specificare un path preferito quando ci sono più collegamenti alla stessa networking
  • 3 WAN e un router Cisco - PBR, QOS, Load-Balancing
  • Può un Router di Linksys essere la causa di cattive velocità su un collegamento di 1,5 mbps?
  • Diversi indirizzi IP all'interno della stessa substring sullo stesso host
  • Metodo di ristrutturazione di networking per la networking Double-NAT
  • La tabella di routing di Internet interrompe 512.000 routes
  • Può un server DHCP di Windows offrire un ambito di cui non fa parte?
  • 2 Solutions collect form web for “Collegamenti OpenVPN ridondanti con routing Linux avanzato su una networking non affidabile”

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

    Per ulteriori informazioni su come configurare l'incollaggio, vedere l'eccellente manuale all'indirizzo 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 fascino. L'installazione è in realtà abbastanza facile!

    NOTA : ho implementato questo con due connessioni a un solo server, perché questo mi ha già risolto il problema. Se si desidera provare un'installazione con due server, il modo più semplice è probabilmente utilizzare l'inoltro di port per inoltrare la port UDP dal secondo server al primo e utilizzare la stessa ricetta come descritto qui. Non l'ho ancora testato.

    Innanzitutto, assicurati di avere un kernel 2.6 con il supporto di incollaggio (predefinito in tutte le distribuzioni moderne) e se avete installato.

    Quindi, metta questo nel tuo /etc/rc.local o in qualsiasi altro posto preferito, ma assicuratevi che sia eseguito prima che vengano avviati openvpn (perché cercherà di bind a bond0):

    Cliente:

     modprobe bonding mode=broadcast ifconfig bond0 10.10.0.2 netmask 255.255.255.0 up 

    Potresti aggiungere un po 'di routing se necessario, assicuratevi di fare tutto il routing corretto dall'altro lato.

     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 

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

    Successivamente, aggiungere un bridge0a.conf e bridge0b.conf a / etc / openvpn / insieme a una chiave condivisa. I file sono gli stessi per a e b, ad exception di una port diversa (ad esempio, utilizzare 3002 per b). Sostituisci 11.22.33.44 dal pubblico pubblico IP 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 assicurarsi che le nuove configurazioni VPN siano avviate. Riavviare le macchine o caricare rc.local e riavviare manualmente openvpn.

    Ora sei pronto a provare il tuo setup:

     # 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 each pacchetto ICMP: i pacchetti sono duplicati sul lato locale e le risposte a questi due pacchetti vengono duplicati nuovamente sul lato remoto. Questo non sarà un problema per le connessioni TCP, perché TCP ignorerà semplicemente tutti i duplicati.

    Questo è un problema per i pacchetti UDP, in quanto è il software per gestire duplicati. Ad esempio, una query DNS produrrà quattro risposte invece dei due attesi (e usa quattro volte la width 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!

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.