Я использовал ответ, предоставленный @ user48116, и он работает как шарм. Настройка на самом деле довольно проста!
ПРИМЕЧАНИЕ : я реализовал это с двумя подключениями только к одному серверу, так как это уже решило проблему для меня. Если вы хотите попробовать установку с двумя серверами, возможно, самый простой способ - это использовать переадресацию портов для пересылки UDP-порта со второго сервера на первый и использовать тот же рецепт, как описано здесь. Я не проверял это сам, хотя.
Во-первых, убедитесь, что у вас есть ядро 2.6 с поддержкой связывания (по умолчанию во всех современных дистрибутивах) и у вас установлен ifenslave.
Затем поместите это в ваш /etc/rc.local или любое другое место, которое вы предпочитаете, но убедитесь, что он запускается до запуска openvpn (потому что он попытается привязаться к bond0):
Клиент:
modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.2 netmask 255.255.255.0 up
Вы можете добавить некоторую маршрутизацию, если это необходимо, убедитесь, что вы делаете все правильные маршруты с другой стороны, хотя.
route add -net 10.7.0.0/24 gw 10.10.0.1
Сервер:
modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.1 netmask 255.255.255.0 up
Создайте скрипт /etc/openvpn/tap-up.sh (и не забудьте пометить его исполняемым с помощью 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"
Затем добавьте bridge0a.conf и bridge0b.conf в / etc / openvpn / вместе с общим ключом. Файлы одинаковы для a и b, за исключением другого порта (например, используйте 3002 для b). Замените 11.22.33.44 на публичный IP вашего сервера.
Клиент:
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
Сервер:
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
Не забудьте отредактировать / etc / defaults / openvpn, чтобы убедиться, что ваши новые конфигурации VPN запущены. Перезагрузите ваши машины или загрузите rc.local и перезапустите openvpn вручную.
Теперь вы готовы проверить свои настройки:
# 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
Если все идет хорошо и линия хорошая, вы увидите четыре ответа для каждого пакета ICMP: ваши пакеты дублируются на локальной стороне, а ответы на эти два пакета снова дублируются на удаленной стороне. Это не будет проблемой для TCP-соединений, потому что TCP будет просто игнорировать все дубликаты.
Это проблема для пакетов UDP, так как это зависит от программного обеспечения для обработки дубликатов. Например, DNS-запрос даст четыре ответа вместо ожидаемых двух (и использует ответ в четыре раза больше нормальной полосы пропускания вместо двух раз):
# 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)
Удачи!