Надлишки OpenVPN-з'єднань з розширеною маршрутизацією Linux через ненадійну мережу

Зараз я живу в країні, яка блокує багато веб-сайтів і має ненадійні мережеві зв’язки із зовнішнім світом. У мене є дві кінцеві точки OpenVPN (скажімо: vpn1 і vpn2) на серверах Linux, які я використовую для обходу брандмауера. Я маю повний доступ до цих серверів. Це працює досить добре, за винятком великих втрат пакету на моїх VPN-з'єднаннях. Ця втрата пакету коливається в межах від 1% до 30% залежно від часу і, здається, має низьку кореляцію, більшість часу вона здається випадковою.

Я думаю про створення домашнього маршрутизатора (також на Linux), який підтримує підключення OpenVPN до обох кінцевих точок і посилає всі пакети двічі до обох кінцевих точок. vpn2 надсилатиме всі пакети з дому до vpn1. Трафік повернення буде надсилатися як безпосередньо з vpn1 додому, так і через vpn2.

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

Для наочності: всі пакети між домашнім та HTTP-проксі дублюються та надсилаються через різні шляхи, щоб збільшити шанси, що один з них надійде. Якщо обидва прибули, першу секунду можна буде мовчки відкинути.

Використання пропускної здатності не є проблемою як на домашній, так і на кінцевій точці. vpn1 і vpn2 близькі один до одного (3ms ping) і мають надійне з'єднання.

Будь-які вказівки на те, як цього можна досягти, використовуючи розширені політики маршрутизації, доступні в Linux?

Використовуйте інфраструктуру зв’язку з боку 'home' та 'vpn1' і, зокрема, з параметром mode = 3, який транслює трафік на всіх інтерфейсах, що належать до облігації.

Для отримання додаткової інформації про те, як налаштувати зв’язок, дивіться чудовий посібник на веб- сторінці http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.37.y.git;a=blob;f = Документація / мережа / bonding.txt; h = 5dc638791d975116bf1a1e590fdfc44a6ae5c33c; hb = HEAD

Я використав відповідь, яку надав @ 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)

Удачі!