А есть в природе mikrotik с двумя USB-гнёздами, чтобы воткнуть в них два свистка и балансировать нагрузку?

1. USB хаб
2. https://wiki.mikrotik.com/wiki/Supported_Hardware#4G_LTE_cards_and_modems
3. «две СИМки с бесплатным безлимитным тырнетом на 64 кбит/с хочу объединить в виртуальный канал 128 кбит/с» - так просто ты не объединишь 2 канала. Либо failover, либо разным клиентам разные каныл, либо велосипеды с агрегацией канала через сторонний сервер/сервис

https://mikrotik.com/product/hap_ac3_lte6_kit#fndtn-specifications - 1 модем внутри, второй в usb
https://mikrotik.com/product/ltap_lte6_kit - один в наличии, на сколько помню в него можно второй модем mini-pci воткнуть
https://mikrotik.com/product/rbm33g - сюда можно 2 minipci модема воткнуть
https://mikrotik.com/product/wap_lte_kit - купить 2 wap lte и один свитч, на wap'ах настроить vrrp и скриптами гасить активный если пропал инет (ну или к hex их подключить в качестве можемов)

либо разным клиентам разные каныл, либо велосипеды с агрегацией канала через сторонний сервер/сервис

А в чём тогда заключается балансировка трафика, которую, по слухам, умеет микротик? В торрентах я получу удвоение скорости?

Или, тупо, две СИМки с бесплатным безлимитным тырнетом на 64 кбит/с хочу объединить в виртуальный канал 128 кбит/с.

Прям «объединить» это так просто не выйдет, был такой случай, но там 3 l2 vpn (вроде openvpn) по разным sim поднимали в сторону 1 микрота и потом агрегировали, но это явно не твой случай.

А так, ну можешь «раскидать» коннекты с различных внутренних ip по разным sim

Дык это и linux умеет. Делаешь две таблицы маршрутизации, потом в fw маркируешь что 50% коннекшенов буду с меткой a1, другие 50% с меткой a2 и отсылаешь коннекшены с a1 по одной таблице, с a2 по другой. С торрентами может прокатить.

Дык это и linux умеет. Делаешь две таблицы маршрутизации, потом в fw маркируешь что 50% коннекшенов буду с меткой a1, другие 50% с меткой a2 и отсылаешь коннекшены с a1 по одной таблице, с a2 по другой. С торрентами может прокатить.

Нет, как мне здесь отвечали, не прокатит, в том смысле, что в линуксе есть кэширование. Если, скажем, браузер лез в а1, а торрент - в а2 (ну, грубо говоря), то браузер продолжит лезть в а1, даже если его пропускная способность упала в 10 раз, а а2 свободный. Ибо запоминается выбор.

Кеш есть, но он сбрасывается каждые 30 (вроде) секунд. Там скорее сайты будут к тебе подозрительно относиться, что постоянно месяется ip (nat жеж) с которого приходят запросы.

Поэтому лучше разграничивать по source ip (жестко задавать таблицы маршрутизации)

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

Либо failover, либо разным клиентам разные каныл, либо велосипеды с агрегацией канала через сторонний сервер/сервис

на разные IP вполне себе будет работать агрегация, хоть и костыльно (round-robin маршрут). как минимум под линем лет с 15 назад такое делал, а в некротике линь под капотом, хоть и испохабленый кривыми лапками индусов/китайцев/прочих аутсорсеров.

но - да, динамически балансироваться это все не будет.

да не нужно таких костылей. просто miltipath роут. через какой гейт (и интерфефйс соответственно) пакет пробежал - через тот гейт и другие из єтого коннекта полезут…

кеш вроде не так часто сбрасывается. но сайты любят перекидывать на разные IP (либо резервирование на 2 и более серверах, либо сабдомен на друго хосте), и потому сорс ип будет меняться даже без сброса кеша. и если большинству сайтов пох, то файлопомойкам например совсем не пох…

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

Допустим, нет никакой страницы подтверждения

да не нужно таких костылей. просто miltipath роут. через какой гейт (и интерфефйс соответственно) пакет пробежал - через тот гейт и другие из єтого коннекта полезут…

Оно хорошо работает в условиях отсутствия NAT. Когда есть nat, то получается ситуация что раз в 10 минут (да, с 30сек ошибся, это arp так часто дропается) есть вероятность в 50% (для двух роутов), что запросы пойдут по другому каналу и будут иметь другой внешний ip. Тот-же паранаидальный gmail может прифигеть, онт того что каждые 10 минут адрес меняется и может начать возбухать.

ну и я об этом) поэтому лучше раскидать клиентские ПК по разным таблицам

которую, по слухам, умеет микротик

Микротик тупой как дрова, и сам по себе ничего не умеет. А ещё он очень глючный и склонен к kernel panic-ам.
Все хотелки настраиваются руками, а то, что нельзя настроить - прикостыливается на скриптах.
Единственный плюс микротика, по сравнению с openwrt - более дружелюбный интерфейс командной строки, хотя после нормального линукса очень непривычный. Во всем остальном он либо хуже, либо требует не менее красноглазой настройки. Wifi почти всегда хуже, т.к. из-за велосипедостроения латыши не смогли портировать дрова под новое железо.

да относительно нормально работает и в присутствии ната. да и гмэйлу вроде как пофиг на меняющийся сорс ип.

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

а все остальное - да, очень печально, и баги в изобилии. с вафлей (с которой раньше все было замечательно) стало все совсем уныло и печально, почему и по цене некротик - дно рынка «типа профессиональных» решений.

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

Ну по моему опыту в лучшем случае gmail будет постоянно авторизацию просить, а потом залочится и не будет работать без подтверждения по телефону.