Question Connexions OpenVPN redondantes avec routage Linux avancé sur un réseau peu fiable


Je vis actuellement dans un pays qui bloque de nombreux sites Web et dispose de connexions réseau non fiables avec le monde extérieur. J'ai deux points de terminaison OpenVPN (par exemple: vpn1 et vpn2) sur des serveurs Linux que j'utilise pour contourner le pare-feu. J'ai un accès complet à ces serveurs. Cela fonctionne très bien, sauf pour la perte de paquets élevée sur mes connexions VPN. Cette perte de paquets varie entre 1% et 30% en fonction du temps et semble avoir une faible corrélation, la plupart du temps elle semble aléatoire.

Je songe à configurer un routeur domestique (également sous Linux) qui maintienne les connexions OpenVPN vers les deux points de terminaison et envoie tous les paquets deux fois, aux deux points de terminaison. vpn2 enverrait tous les paquets de la maison à vpn1. Le trafic de retour serait envoyé à la fois directement de vpn1 à la maison, et également via vpn2.

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

Pour plus de clarté, tous les paquets entre le proxy local et le proxy HTTP seront dupliqués et envoyés sur des chemins différents, pour augmenter les chances que l'un d'entre eux arrive. Si les deux arrivent, la première seconde peut être ignorée en silence.

L'utilisation de la bande passante n'est pas un problème, à la fois du côté maison et du point final. vpn1 et vpn2 sont proches (ping 3ms) et ont une connexion fiable.

Des indications sur la manière dont cela pourrait être réalisé à l'aide des stratégies de routage avancées disponibles sous Linux?


9
2018-03-01 10:28


origine




Réponses:


Utilisez l'infrastructure de liaison des côtés «home» et «vpn1», et plus précisément avec le paramètre mode = 3 qui diffuse le trafic sur toutes les interfaces appartenant à une liaison.

Pour plus d'informations sur la configuration du collage, voir l'excellent manuel à l'adresse http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.37.y.git;a=blob;f=Documentation/networking/bonding.txt; = HEAD


8
2018-03-01 12:16



J'ai testé cette configuration et cela fonctionne à merveille. La perte de paquets est réduite d'environ 5% à 0,0-0,1% avec une connexion redondante à un seul serveur! - konrad


J'ai utilisé la réponse fournie par @ user48116 et cela fonctionne à merveille. La configuration est en fait assez facile!

REMARQUE: Je l'ai implémenté avec deux connexions à un seul serveur, car cela résout déjà le problème pour moi. Si vous souhaitez essayer une configuration avec deux serveurs, le moyen le plus simple consiste probablement à utiliser la redirection de port pour transférer le port UDP du deuxième serveur vers le premier et à utiliser la même recette, comme décrit ici. Je n'ai cependant pas testé cela moi-même.

Tout d’abord, assurez-vous que vous avez un noyau 2.6 prenant en charge la liaison (par défaut dans toutes les distributions modernes) et que ifenslave est installé.

Ensuite, mettez ceci dans votre /etc/rc.local ou dans tout autre endroit que vous préférez, mais assurez-vous qu'il soit exécuté avant openvpn est lancé (car il essaiera de se lier à bond0):

Client:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.2 netmask 255.255.255.0 up

Vous pouvez ajouter un peu de routage si nécessaire ici, mais assurez-vous de faire le bon routage de l’autre côté.

route add -net 10.7.0.0/24 gw 10.10.0.1

Serveur:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.1 netmask 255.255.255.0 up

Créez un script /etc/openvpn/tap-up.sh (et n'oubliez pas de le marquer comme exécutable avec 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"

Ensuite, ajoutez un bridge0a.conf et un bridge0b.conf à / etc / openvpn / avec une clé partagée. Les fichiers sont les mêmes pour a et b, sauf pour un port différent (par exemple, utilisez 3002 pour b). Remplacez 11.22.33.44 par l’adresse IP publique de votre serveur.

Client:

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

Serveur:

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'oubliez pas de modifier / etc / defaults / openvpn pour vous assurer que vos nouvelles configurations VPN sont démarrées. Redémarrez vos machines ou chargez rc.local et redémarrez openvpn manuellement.

Vous êtes maintenant prêt à tester votre configuration:

# 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

Si tout se passe bien et que la ligne est bonne, vous verrez quatre réponses pour chaque package ICMP: vos packages sont dupliqués du côté local et les réponses à ces deux packages sont dupliquées de nouveau du côté distant. Ce ne sera pas un problème pour les connexions TCP, car TCP ignorera simplement tous les doublons.

Ceci est un problème pour les paquets UDP, car il appartient au logiciel de gérer les doublons. Par exemple, une requête DNS donnera quatre réponses au lieu des deux attendues (et utilisera quatre fois la bande passante normale de la réponse au lieu de deux fois):

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

Bonne chance!


7
2018-03-15 06:15