ZaRRaZZa, да вроде вышел: один и тот же дистрибутив, разные варианты/ключи установки. Ну, я так понял. Качал официальный образ, с левой сборкой не стал даже пытаться.

а лучше sha256 контрольную сумму исошника

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

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

Баланисировка нагрузки "в лоб" работать не будет или создаст проблемы (то есть если в таблице маршрутизации роутера будут два равновесных маршрута через двух разных провайдеров). Такая конфигурация в теории позволит отправлять пакеты одного и того же соединения поочередно через два маршрута, что приведет почти в 100% случаев к нарушению порядка пакетов (длина маршрутов к одному и тому же пункту назначения будет априори разная через разные сети двух независимых провайдеров). Практически все соединения будут нарушены, что TCP, что UDP. Короче ECMP здесь не применим.

Самое простое резервирование Active/Standby можно задать путем увеличения метрики для маршрута по-умолчанию через резервного провайдера.
В номинальной ситуации, из двух маршрутов по-умолчанию (от провайдеров А и Б), только лучший маршрут (с лучшей метрикой) будет установлен в таблицу маршрутизации. Если связь с основним провайдером А будет потеряна (точнее шлюз для этого маршрута перестанет быть доступен), то текущий маршрут будет удален из таблицы и его место займет менее приоритетный маршрут, то есть через провайдера Б.
Проблема в том, что без применения протоколов динамической маршрутизации (которые не предусмотрены провайдерами для публичных клиентов) это (обнаружение пропажи шлюза) работает только если пропадает само физическое соединение к этому шлюзу (то есть упадет соответствующий локальный интерфейс роутера) - ибо раз нет физического соединения, то сегмент сети (включая шлюз) не доступен. Однако если линия остается поднятой, но сам шлюз не отвечает или обрыв произошел не между твоим роутером и концентратором доступа провайдера, а между концентратором и шлюзом где-то внутри сети провайдера, то твой роутер не в состоянии обнаружить недоступность маршрута чтобы убрать этот маршрут из таблицы.
Такая ситуация решается, если роутер поддерживает IP SLA. Роутер делает регулярные проверки некого ресурса (адреса шлюза, сервер в интернете, и т. п.) отдельно через шлюз каждого из провайдеров по ICMP или UDP, например, каждые 10 секунд. Каждая проверка связана с одним из маршрутов по умолчанию. Если проверка проваливается (например нет ответа на 5 последовательных пакетов), то соответствующий маршрут удаляется из таблицы и его заменяет запасной. Это позволяет установить если маршрутизация через данного провайдера недоступна, даже если соединение с этим провайдером по-прежнему бузупречно. Позволяет так же установить когда в целом маршрутизация работает, но деградировала (например нет ответа на 5 любых пакетов (не обязательно последовательных) из 20 последних). Вообще IP SLA позволяет весьма гибко настраивать политику маршрутизации.

Вообще реализовать разделение трафика между провайдерами можно, но муторно. Можно применять тот или иной шлюз в зависимости от IP адреса источника. Например, все устройства детей – через провайдера А, сам и умный дом - через провайдера Б. Называется это Policy Based Routing (PBR), фича стандартная, хотя в серьезных сетях не популярна, но для домашней сети вполне приемлима.

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

Можно балансировать по протоколам, это тоже PBR, но при нынешнем засилии http(s)/2/quick, это не эффективно. Особенно если номера портов нестандартизированы или случайны – как у битторрента. Тем не менее я решал такую проблему путем установки прокси сервера – клиет битторрента настраивался использовать прокси, а уже для адреса прокси-сервера я создавал на роутере PBR идти через провайдера Б, в то время как весть прочий трафик шел по-умолчанию через провайдера А.

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

Все вышесказанное справедливо для IPv4 и во многом для IPv6 тоже, но резервирование доступа извне до домашнего сервера по IPv6 несколько и проще и сложнее одновременно, с одной стороны из-за отсутсвия NAT, с другой из разных делегируемых префиков от каждого из провайдеров.

Блин, VMcS, я надеюсь, ты это не сам писал, а скопипастил? Столько текста, а для меня либо не ново, либо бесполезно У меня Mikrotik, который конечно умеет все. И стучаться снаружи вовнутрь надо, да, именно потому у меня на каждом провайдере заказан за дополнительную плату статический IP (и есть доменные имена, которые я могу к ним привязывать).
На входе снаружи после роутера стоит nginx proxy manager, с помощью которого я тоже могу рулить какие входящие запросы куда маршрутизировать внутри сети, но сначала мне надо маркировку пакетов в роутере сделать (чтобы ответы улетали тому провайдеру, с которого поступил запрос), а это только в роутере.

Витя, привет.
Сколько зим.

IPv6 PD провайдеры тоже дают?

Очень в этом сомневаюсь, VMcS, не видел, но я и не уточнял. Сомневаюсь, что через наших колхозных провайдеров снаружи можно домой по IPv6 достучаться. Интересно, а домены к ним дают привязать? Посмотрел на reg.ru - не предлагают такого варианта.

VMcS, спасибо, не знал. Посмотрю, что там мои провайдеры говорят про выдачу IPv6 при случае.