9 votos

Redundante OpenVPN conexiones con advanced Linux enrutamiento a través de una red no confiable

Actualmente estoy viviendo en un país que bloquea muchos sitios web y fiable de la red de conexiones con el mundo exterior. Tengo dos OpenVPN extremos (es decir: vpn1 y vpn2) en servidores Linux que uso para eludir el firewall. Tengo acceso completo a estos servidores. Esto funciona bastante bien, salvo por el alto paquete de pérdida en mis conexiones VPN. Esta pérdida de paquetes varía entre el 1% y el 30% dependiendo de la hora y parece tener una correlación baja, la mayoría del tiempo parece aleatorio.

Estoy pensando acerca de la configuración de un router en casa (también en Linux) que mantiene OpenVPN conexiones a ambos extremos y envía todos los paquetes de dos veces, a ambos extremos. vpn2 iba a enviar todos los paquetes de la casa a la vpn1. Volver trafic sería enviar directamente desde vpn1 de casa, y también a través de vpn2.

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

Para mayor claridad: todos los paquetes entre el hogar y el HTTP proxy se duplican y se envían a través de diferentes caminos, para aumentar las posibilidades de que uno de ellos va a llegar. Si ambos llegan, el primer segundo, uno puede ser descartan.

Uso de ancho de banda no es un problema, tanto en la casa del lado y extremo del lado. vpn1 y vpn2 están cerca el uno del otro (3ms ping) y una conexión fiable.

Alguna sugerencia sobre cómo esto podría lograrse mediante el enrutamiento avanzado políticas disponibles en Linux?

8voto

jap Puntos 118

El uso de la vinculación de la infraestructura en la 'home' y 'vpn1 lado, y specifcally con el modo=3 configuración que difunde el tráfico en todas las interfaces que pertenecen a un bono.

Para obtener más información sobre cómo configurar la vinculación, véase el excelente manual en 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=HEAD

7voto

konrad Puntos 348

He utilizado la respuesta proporcionada por @user48116 y funciona como un encanto. La instalación es realmente fácil!

NOTA: he implementado esta con dos conexiones a un solo servidor, ya esta solucionado ya el problema para mí. Si quieres probar una configuración con dos servidores, la forma más sencilla es probablemente el uso de reenvío de puerto para reenviar el puerto UDP desde el segundo servidor a la primera, y usar la misma receta y como se describe aquí. No he probado a mí mismo aunque.

En primer lugar, asegúrese de que tiene un kernel 2.6, con la vinculación de apoyo (por defecto en todas las distribuciones) y tiene ifenslave instalado.

A continuación, poner esto en tu /etc/rc.local o en cualquier otro lugar que usted prefiera, pero asegúrese de que se ejecuta antes de openvpn se inicia (porque se intenta enlazar a bond0):

Cliente:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.2 netmask 255.255.255.0 up

Usted puede agregar algunos de enrutamiento si es necesario aquí, asegúrese de que usted haga todo el enrutamiento adecuado desde el otro lado también, aunque.

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

Crear una /etc/openvpn/tap-up.sh script (y no te olvides de marcar ejecutable 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"

A continuación, agregue un bridge0a.conf y bridge0b.conf a /etc/openvpn/ junto con una clave compartida. Los archivos son los mismos para a y b, excepto por un puerto diferente (por ejemplo, el uso 3002 b). Reemplazar 11.22.33.44 por su servidor IP pública.

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

No se olvide de editar /etc/defaults/openvpn para asegurarse de que su nueva configuraciones de VPN se han iniciado. Reinicio de las máquinas, o de carga rc.locales y reiniciar openvpn manualmente.

Ahora estás listo para probar su configuración:

# 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 todo va bien y la línea es buena, verá cuatro respuestas para cada paquete ICMP: los paquetes se duplican en el lado local, y las respuestas a estos dos paquetes son duplicados de nuevo en el lado remoto. Esto no será un problema para las conexiones TCP, debido a que TCP simplemente ignorar todos los duplicados.

Este es un problema para los paquetes UDP, como es el software para manejar los duplicados. Por ejemplo, una consulta de DNS producirá cuatro respuestas en lugar de esperar dos (y el uso de cuatro veces el ancho de banda normal de la respuesta en lugar de dos veces):

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

Buena suerte!

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: