VPN bonding на OpenWRT для отказоустойчивого интернета

А есть поднять два тоннеля с разными адресами в них и просто добавить два маршрута до нужной сети с разными метриками? Тебе ведь failover нужен, а не load balancing?

OpenVPN хорошо работает на плохих каналах с TCP. С UDP что OpenVPN, что L2TP равнозначно. Для потокового вещания лучше использовать TINC v1.1, у него задержки меньше, т.к.реже переключается kernel-user_space

Забыл добовить. Если шифрование не нужно проще поднять IP-IP или GRE туннели, будет еще быстрее.

Оно будет работать на уровне подключений?

Погуглив по теме я нашел multiwan для openwrt. Это не совсем то, что хотелось бы, потому что он работает на уровне подключений, т.е. раскидывает сетевые подключения между провайдерами, а хотелось бы, чтобы работало на уровне пакетов. Если провайдер упадет, будет рваться соединение, а через второго провайдера подключение пойдет только когда стриминговый софт переконнектится, и непонятно сколько на это времени уйдет, особенно если провайдер не полностью упадет, а будет сильно тупить.

У меня TCP. За TINC спасибо.

Оно будет работать на уровне подключений?

Не уверен, надо тестировать. Как мне кажется если там будет простая маршрутизация (не NAT) то всё должно быть прозрачно, просто после падения одного из каналов будет задержка перед доставкой нескольких пакетов. Но это не наверняка. Проверь. Делов-то — на пять минут

2. Макрировка каждого 2-го пакета в iptables и маршрутизация по метки пакета. В каждой таблице маршрутизации по два маршрута через разные тунели с разной метрикой. Правда не знаю, есть ли в openwrt у iptables модуль statistic.

3. Пишут, что у openvpn можно указать ″cipher none″ для отключения шифрации.

1. Переопределение WAN зависит от железа роутера, в tl-wr841n(d) драйвера поддерживают 802.1q (VLAN) на коммутаторе LAN портов, так что разделить проблемы нет. Чтобы понимать о чём речь - роутер состоит из непосредственно host-системы (проц, память, флешка) и периферии. Это всё может быть запаковано в один чип, но суть не меняется. На SoC обычно один или два ethernet порта. Если два, то один напрямую выводится как WAN, а второй смотрит в чип коммутатора (обычно 5 портов), дальше уже зависит от коммутатора, что он умеет (в вашем случае должен уметь тегировать пакеты по 802.1q).

2. MPTCP больше полезен для load-balance, чем для fault-tolerance. Тут полезной пилюли нет, придётся перебирать.

3. Для VPN на роутере лучше брать то, что имеет kernel-space реализацию. Для обычных компов и серверов проблемы с нагрузкой особо не стоит и там используют openvpn, но на роутере проц слабый и гонять трафик по пути

interface -> (net-driver, socket) kernel-space -> (socket, VPN, socket) user-space -> (socket, tun/tap, net-driver, socket) kernel-space -> (socket, app) user-space 

interface -> (net-driver, VPN, net-driver, socket) kernel-space -> (socket, app) user-space

Tinc и OpenVPN может работать как коммутатор на TAP интерфейсах. TAP в bond запихать. Режим работы bonding - балансировка, несколько режимов active-backup. Linux Bonding. Bond все будет сам. Работа любого VPN только доставлять гарантированно пакеты.

Интернет сеть построенная на каналах негарантированной полосы и работоспособности. Поэтому, фраза, что VPN что-то там гарантирует мне непонятна.

Как я понял, ТС не хочет переключения каналов с потерей пачки пакетов во время обнаружения проблем. Он считает, что важнее доставлять каждый второй пакет. Режим active-backup под это условие не подходит.

ТС хочет, чтобы VPN работал по tcp, насколько хорошо будет работать ARP monitor bond интерфейса при drop-ах пакетов у провайдера и повторных передачах на уровне tcp?

Нормально работает. Главное присвоить уникальные MAC адреса и не поднимать ARP proxy. При дублировании любой VPN (OpenVPN, L2TP, ...) перекашивает.

Спасибо. Реальный айпишник есть только на стороне сервера.

Как я понял, ТС не хочет переключения каналов с потерей пачки пакетов во время обнаружения проблем. Он считает, что важнее доставлять каждый второй пакет.

Нет, потеря пакетов будет нормально, если потом следующие пройдут по резервному каналу. Есть решения, когда на резервный канал переключится только если полностью разорвется соединение (например multiwan в OpenWRT), я не хочу вот это. Оно будет плохо, если упадет скорость, стриминговый софт в этом случае не будет рвать соединение, и ничего не переключится.