2 провайдера и зеркалирование трафика для надёжности

[denel]

Доброго всем дня!
Имеется 2 интернет-соединения к двум разным интернет-провайдерам (оба GSM, но не суть). Имеется хост географически в другой локации с openvpn сервером.
И в пятницу частенько начинаются разные цирковые представления с прохождением пакетов по этим интерфейсам. Через одного провайдера пакеты возвращаются в большей степени, чем через другого. НО ни через одного они не возвращаются в ПОЛНОМ составе, что-то, да утеряется. На любые хосты, хотя мне интересен конкретно единственный, содержащий openvpn серверы на борту. Вероятно это из-за обновления у людей современной винды по технологии p2p... Эта нагрузка на провайдеров исходит не от нас, мы потерпевшие.

Как сделать так, чтобы к openvpn серверу и обратно трафик ходил одинаковый по двум GSM провайдерам одновременно, с отличием лишь в исходящем, а за тем уже входящем IP адресе, а до openvpn сервера и openvpn клиента пакеты доходили лишь пришедшие первыми, но без нарушения последовательности чередования?

Не самая стандартная задача, но нужно для как можно более надёжного прохождения трафика. Проводной провайдер подключён быть не может. Кстати трафик желательно UDP, имеется доступ к управлению как Linux хостом-клиентом, так и Linux хостом-сервером. Gentoo.

[Hephaestus]

Задача сама по себе нетривиальная,
а вот это:

надёжного прохождения трафика

трафик желательно UDP

вообще взаимоисключающие вещи.

[s.xbatob]

А попробовать транспорт TCP? Когда по маршруту есть NAT, то openvpn поверх UDP так и работает.

[denel]

А попробовать транспорт TCP? Когда по маршруту есть NAT, то openvpn поверх UDP так и работает.

TCP я не использую так как это работает медленнее сразу, к тому же задержки в несколько секунд оно всё равно не преодолевает. А по предлагаемой мной схеме откуда пакет придёт первым, тот и берётся во внимание, и совершенно всё равно уже, придёт со второго интерфейса или нет. В конечном счёте если ни с одного не придёт, openvpn сервер пытается отправить снова, но такое ему придётся проделывать уже значительно реже, по теории вероятности...

[denel]

Задача сама по себе нетривиальная,
а вот это:

надёжного прохождения трафика

трафик желательно UDP

вообще взаимоисключающие вещи.

Да, TCP снова на уровне протокола пытается отправлять, но из-за нагрузки у провайдера в конечном счёте шансов у него не на много больше. Гораздо больше шансов получить заветный 1 пакет используя отправку сразу двумя маршрутами.

[Hephaestus]

А по предлагаемой мной схеме откуда пакет придёт первым

Это если вообще придёт.
Проблема в том, что UDP по определению не гарантирует доставку пакетов.
Долетел пакет до получателя или нет - понять невозможно.
То есть, пакеты-то конечно будут долетать, только вот гарантировать это нельзя.
С требованием "надежного прохождения трафика" это не сочетается просто вот никак.

[denel]

А по предлагаемой мной схеме откуда пакет придёт первым

Это если вообще придёт.
Проблема в том, что UDP по определению не гарантирует доставку пакетов.
Долетел пакет до получателя или нет - понять невозможно.
То есть, пакеты-то конечно будут долетать, только вот гарантировать это нельзя.
С требованием "надежного прохождения трафика" это не сочетается просто вот никак.

О повторных отправках, а именно так работает TCP, заботится сам openvpn. Я лишь уменьшаю ему количество раз, когда ему придётся запрашивать по-новой. Что надёжней: получить по TCP пакет в пике нагрузки у единственного провайдера или по UDP запрашивая снова только в том случае, если так ни один и не будет доставлен?... Вот мне почему-то думается, что пик нагрузки не может случаться у обоих провайдеров одновременно до миллисекунд...

[Hephaestus]

О повторных отправках, а именно так работает TCP

В случае UDP до повторных оправок ещё дожить надо. Я говорю не об этом.

по UDP запрашивая снова только в том случае, если так ни один и не будет доставлен?

Для этого нужно сначала понять, что он не доставлен.
А понять это невозможно, потому что в UDP это никак не отслеживается.
Если я правильно понял, смысл данной темы в том, что имеет место частичная потеря пакетов при передаче.
Так вот, для UPD это норма. То есть там в принципе не предусмотрена стопроцентная доставка.

[denel]

О повторных отправках, а именно так работает TCP

В случае UDP до повторных оправок ещё дожить надо. Я говорю не об этом.

по UDP запрашивая снова только в том случае, если так ни один и не будет доставлен?

Для этого нужно сначала понять, что он не доставлен.
А понять это невозможно, потому что в UDP это никак не отслеживается.
Если я правильно понял, смысл данной темы в том, что имеет место частичная потеря пакетов при передаче.
Так вот, для UPD это норма. То есть там в принципе не предусмотрена стопроцентная доставка.

openvpn это понимает и предпринимает сам попытку новой отправки. Да, это немного дольше, чем на самом TCP, но зато в основном это выйдет гораздо быстрей и в том числе надёжней, ибо используется 2 интерфейса двух разных GSM провайдеров. Я не ставил задачу определять, доставились UDP пакеты или нет, задача состоит в том, чтобы отдать openvpn именно первый из них, отбрасывая второй даже в случае его доставки.

Да, речь идёт о частичной недоставке пакетов, причём это частичное порой продолжается в течение нескольких секунд, до полуминуты. Нет смысла ждать, когда провайдер разродится, если можно использовать канал второго. Вот так вот, совершенно незаметно для конечного потребителя должны проходить лаги, так как речь не просто о http запросах, а о удалённом доступе и онлайн стримах без провалов. TCP это не способен обеспечить, провалы одного канала слишком велики!

[Hephaestus]

Да, речь идёт о частичной недоставке пакетов, причём это частичное порой продолжается в течение нескольких секунд, до полуминуты. Нет смысла ждать, когда провайдер разродится, если можно использовать канал второго.

А откуда известно, что причина недоставки пакетов в провайдере, а не в самом UDP?

[denel]

Да, речь идёт о частичной недоставке пакетов, причём это частичное порой продолжается в течение нескольких секунд, до полуминуты. Нет смысла ждать, когда провайдер разродится, если можно использовать канал второго.

А откуда известно, что причина недоставки пакетов в провайдере, а не в самом UDP?

Потому что имеется второй VPN канал (TCP), который ощутимо медленней и тоже не справляющийся в эти моменты.

[Hephaestus]

Потому что имеется второй VPN канал (TCP), который ощутимо медленней и тоже не справляющийся в эти моменты.

Понятно.

оба GSM, но не суть

На самом деле, это важно. Мобильное соединение в принципе менее устойчиво, чем проводное.

Однако в Вашем случае

Проводной провайдер подключён быть не может

поэтому обходимся тем, что есть.

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

Что я бы попробовал сделать на уровне своих (контролируемых мной) устройств.
Во-первых, дать им нормальную вентиляцию (нормальное охлаждение) - они порой довольно сильно нагреваются и начинают тупить. То есть сами устройства создают проблему.
Во-вторых, обеспечить их (модемы) автономным питанием. При недостаточном питании модемы в произвольные моменты начинают отваливаться, переподключаться и т.д. Это никак не способствует надежной передаче данных, сами понимаете. Но вопрос с питанием у Вас, вероятно, уже решен.
В-третьих, организовать работу двух устройств в максимально разных режимах.
Насколько я понял, одно соединение у Вас основное, второе резервное, страхующее.
Тогда основное устройство может работать в 4G, а резервное, скажем, в 3G (или даже в 2G).
Да, это медленнее, но надежнее, меньше нагрузка, и если речь идет именно о доставке/недоставке отдельных пакетов (потерянных, скажем так), то вполне может оказаться подходящим вариантом.

Если, скажем, использовать схему "два соединения+роутер с openwrt",
то получается следующее:
более надежное из двух соединений является основным, работает на более высокой скорости (4G) и ему отдается большая часть трафика, менее надежное является дополнительным, работает на низкой скорости (3G) и на него приходится меньшая часть трафика.

Вообще, я сомневаюсь, что это даст какой-то результат, но попробовать можно.

[denel]

Ну, поскольку Вы не указали, какие у Вас устройства (вероятно, usb-модемы)

Верно

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

Причём здесь один внешний айпи? Важно то, что это висит на одном внешнем интерфейсе, на котором могут висеть и миллионы айпи... Но в работе с GSM даже не это важно, а то, что это большие объёмы трафика прокачиваются через радиоканалы оператора...

Во-первых, дать им нормальную вентиляцию (нормальное охлаждение) - они порой довольно сильно нагреваются и начинают тупить. То есть сами устройства создают проблему.

Модемы висят в открытом воздухе, сейчас температура этого воздуха +13...

Во-вторых, обеспечить их (модемы) автономным питанием. При недостаточном питании модемы в произвольные моменты начинают отваливаться, переподключаться и т.д. Это никак не способствует надежной передаче данных, сами понимаете. Но вопрос с питанием у Вас, вероятно, уже решен.

Ничего не отваливается. Проблемы с питанием я пока не могу прикрутить к пятницам...

В-третьих, организовать работу двух устройств в максимально разных режимах.
Насколько я понял, одно соединение у Вас основное, второе резервное, страхующее.
Тогда основное устройство может работать в 4G, а резервное, скажем, в 3G (или даже в 2G).

Какой фактический в этом смысл, если используются каналы совершенно разных провайдеров, разных вышек?

Вообще, я сомневаюсь, что это даст какой-то результат, но попробовать можно.

Да, это когда совершенно упираешься в потолок идейный и начинаешь делать хотя бы что-нибудь.

Я, когда всё становится ужасно, добавляю маршрут до vpn хоста через резервный GSM канал (интерфейс) и дышать становится можно, но работает связь через резервный провайдер не так хорошо, как через основной, хотя бы работает. Пакеты тоже теряются, но таких серьёзных провалов уже нет. Поэтому я и поднимаю вопрос о том, чтобы зеркалировать трафик по двум каналам, а на хосте с впн сервером уже отбрасывать пакеты, которые пришли позже и наоборот тоже самое делать на хосте впн клиенте. Уже будет совершенно насрать, что происходит на конкретном GSM провайдере, один из пакетов всё равно дойдёт. Здесь нехватает лишь знаний. Например если openvpn сервер или клиент получит пакеты в неправильной очерёдности, он это нормально переварит? У входящего пакета есть уникальный ID, чтобы можно было понять системе, что этот пакет уже был получен ранее?... Или может openvpn сам откинет эти лишние пакеты, если ему дать этот трафик в удвоенном виде?

Да, вот ещё важный момент: в любом случае речь должна идти о прохождении трафика именно через openvpn туннель.

[Hephaestus]

Проблемы с питанием я пока не могу прикрутить к пятницам...

Моя мысль не в том, что они прикручены к пятницам,
а в том, чтобы максимально устранить негативные факторы "на нашей стороне".

Какой фактический в этом смысл, если используются каналы совершенно разных провайдеров, разных вышек?

Тот факт, что это разные вышки, каким-либо образом облегчает работу по пятницам? Похоже, что нет.
Значит, исходим из того, что пятничная нагрузка в той или иной степени имеет место у всех провайдеров.
Тогда нужны какие-то дополнительные способы.
Один из таких способов - использовать другой режим работы.
Например, использовать менее нагруженное, хотя и менее быстрое соединение.

Если эти действия представляются Вам бесполезными, ну, значит, оставляйте всё, как есть.
Нагрузка у провайдера - это внешний фактор, Вы на него повлиять не можете.
Единственное, что реально поможет - это воспользоваться услугами другого провайдера, у которого либо ресурсов больше, либо нагрузки меньше.

[denel]

Тот факт, что это разные вышки, каким-либо образом облегчает работу по пятницам? Похоже, что нет.

Проблемы по пятницам очевидно возникают не от LTE, а от большой нагрузки на вышки, каждый клиент связывается с вышкой через этот LTE. Да, если частотный спектр LTE исчерпывается, а не канал интернета у вышки, тогда действительно имеет смысл пробовать 3g. Но это маловероятно... По 3G вообще, честно говоря, работать невозможно (речь о RDP). Поэтому я не рассматриваю это, тем более 2G. Напомню, ещё должен идти медиа поток, битрейт 256 кбит/с, + копируются снимки камер видеонаблюдения раз в 20 секунд. Нет, нельзя 3g, 2g. вопрос решается маршрутом через резервный GSM, но с погрешностями.

Значит, исходим из того, что пятничная нагрузка в той или иной степени имеет место у всех провайдеров.

Да, у всех, но с такими мощными провалами только у основного. Если у провайдеров тяжело с этим так и не понятно, как решает вопрос снижение стандарта...

Тогда нужны какие-то дополнительные способы.
Один из таких способов - использовать другой режим работы.

Да мы невольно пробовали, модем однажды переключался на "пониженную", повеситься оставалось. Когда в LTE лаги, тогда в 3G вообще делать нечего

Например, использовать менее нагруженное, хотя и менее быстрое соединение.

Соединение может быть действительно менее нагруженное, то есть частотный спектр, да вот только канал у вышки в интернет с того не расширяется, а чисто беря во внимание диалектический материализм... становится понятно, что канал у вышки никто никогда не сделает шире, чем вообще может когда-нибудь понадобиться, это будет не рационально.

Если эти действия представляются Вам бесполезными, ну, значит, оставляйте всё, как есть.
[тогда]Единственное, что реально поможет - это воспользоваться услугами другого провайдера, у которого либо ресурсов больше, либо нагрузки меньше.

Если у меня не удастся реализовать предложенное мною, то единственная альтернатива сейчас - это да, скакать переключением между провайдерами, не используя потенциал одновременно обоих. А учитывая то, что это всё равно не удовлетворяет потребностям, тогда надеюсь когда нибууудь удастся провести туда оптику.

[Hephaestus]

Напомню, ещё должен идти медиа поток, битрейт 256 кбит/с, + копируются снимки камер видеонаблюдения раз в 20 секунд.

В исходном описании проблемы Вы этого не указывали.
Вы говорили лишь о протоколе UDP и о частичной потере пакетов.
А поскольку контроль доставки пакетов в случае UPD должен обеспечиваться приложением,
то лично у меня было полное впечатление, что речь идет о каком-то своём приложении.
То есть Вы пишете/отлаживаете какую-то свою программу и хотите повысить её эффективность.

Да, у всех, но с такими мощными провалами только у основного.

Тогда в полном соответствии с анекдотом про Сталина и синоптиков,
поменяйте провайдеров местами.

[denel]

В исходном описании проблемы Вы этого не указывали.
Вы говорили лишь о протоколе UDP и о частичной потере пакетов.

В исходном действительно, я же не ждал альтернатив моему решению...)))
Вот потом в ветке было упомянуто "онлайн стримах"

поменяйте провайдеров местами.

Этого я не могу сделать по двум причинам:
1. Запасной провайдер постоянно работает "немного подтупливая" почему-то, я симки в модемах правда местами менять не пробовал, да и смысла в этом немного, учитывая причину №2
2. У запасного провайдера органичение трафика 50 ГБ за 28 дней, а мы используем порой под 300.

Да, то есть даже предложенное мною решение не предполагается использовать постоянно, а лишь тогда, когда начинают обнаруживаться крутые провалы в работе основного провайдера, но это уже не имеет отношения к сути реализации решения.

Не беспокойтесь Вы, я до этого и 3G пробовал и без связи оставался указывая принудительно 4G... И такой объём трафика здесь по GSM предоставляет только 1 провайдер. Поэтому нет возможности просто поменять основного провайдера. Точка с хостом-клиентом находится географически в горах, в лесу, туда подведён под землёй только силовой электрический кабель и всё, далее оттуда и туда всё по радио связи.

И раз уж немного раскрыл карты, то скажу, что полностью решает проблему wi-fi канал 5ГГц на Rocket M5+DASH 30dbi, но для этого необходимо разрешение, как его пробить, какие сроки... Если это и возможно, полагаю это не быстро. Хотя вот в этом плане уже приветствуется высказывание подробностей по этому альтернативному решению.

[denel]

Намеренно начал тестировать одновременно 2 свободных openvpn туннеля на одном и том же интерфейсе gsm одного и того же провайдера с тем лишь отличием, что первый туннель организован через TCP, а второй через UDP. Так вот, вышеупомянутые доводы о том, что TCP сам всё порешает - почему-то не работают. Медиапоток HTTP через TCP туннель теряет гораздо больше данных, чем через UDP. Ну нам же неважно, чтобы сам по себе openvpn жил, нам важно, чтобы конечная цель достигалась, а лучше она достигается именно через UDP. И на это указывает практическое применение. Итого остаётся в силе вопрос о том, как можно зеркалировать трафик UDP через двух разных провайдеров?

[denel]

Зеркалирование трафика через разные интерфейсы сделал:

Код: Выделить всё

iptables -t mangle -A OUTPUT -p udp -d $destHost --dport $destPort -j MARK --set-mark 0x20
iptables -t mangle -A POSTROUTING -m mark --mark 0x20 -j TEE --gateway $destHost
iptables -t nat -A POSTROUTING -m mark --mark 0x20 -j SNAT --to-source $newSourceIP
ip route add $destHost dev $newGSM table 250
ip rule add fwmark 0x20/0x20 lookup 250

Итоги: openvpn сам не отбрасывает дублирующиеся пакеты. Как сделать отбрасывание дубликатов - пока не выяснено.

[denel]

Короче пока сделал отдельно 2 OpenVPN туннеля ВСЁ ЖЕ с транспортным протоколом TCP, При TCP ошибки происходят крупные, при UDP похоже по-мельче, при использовании UDP с зеркалированием мелкие ошибки оставались, при TCP их нет, а с зеркалированием пока и крупных не было. Внутри них пустил RTP поток на Unicast адрес $destHost:$destPort. Далее с помощью правил выше этот поток перенаправляется через $dev1 + создаётся копия этих UDP пакетов, которая отправляется по системному, основному маршруту, которым является второй туннель OpenVPN с транспортным протоколом TCP, Таким образом через 2 разных провайдера доставляются одни и те же UDP пакеты RTP. Далее принимающая сторона в лице VLC эффективно откидывает шелуху (дубли) превращая поток в локальный udp multicast, с которого уже может поток приниматься всеми плеерами локальной сети. Уже испробовал, при переподключении одного из туннелей или даже провайдеров - никаких огрехов не происходит. Осталось дождаться жёстких провалов GSM провайдеров. В общем тестирую дальше.

Кстати с одной из сторон используется проводной, единственный провайдер. Поэтому трафик второго туннеля идёт на тот же адрес, но на другой порт, то есть соседний openvpn сервис. На соседний сервис трафик перенаправляется почти теми же правилами:

Код: Выделить всё

iptables -t mangle -A OUTPUT -p tcp -d $destHost --dport $destPort -j MARK --set-mark 0x21
iptables -t nat -A POSTROUTING -m mark --mark 0x21 -j SNAT --to-source $newSourceIP
ip route add $destHost dev $dev1 table 251
ip rule add fwmark 0x21/0x21 lookup 251

Интересно, прокатит ли подобный RTP фокус с L2TP? Пока что попробовал зеркалировать пинги внутри туннелей L2TP, в итоге возвращаются пинги с дубликатами. То есть зеркалировался именно трафик L2TP. Но без ipsec. Хотя вроде именно в самом L2TP предусмотрены Secuence Number