@clausmeisel Я бы сказал, что практически никакой разницы между ними нет — это скорее вопрос удобства. Интерфейс Peplink немного облегчает настройку коротких времен переключения, да и встроено поле для указания управляющего IP-адреса, который смотрит на статистику Starlink. По производительности я разницы не заметил. Частично проблема стала менее острой, теперь, когда у Starlink больше спутников, да и я сдвинул антенну и подрезал деревья, чтобы действительно не было никаких преград. Тем не менее, иногда случаются короткие обрывы на пару секунд. Были и пару более продолжительных сбоев в сети — явно с их стороны. Поэтому пока оставляю моего беспроводного провайдера в качестве резервного варианта.

Peplink я изначально взял, чтобы протестировать их облачный SDWAN — Speedfusion, но лицензии на роутер довольно дорогие (у меня есть неквалифицированный роутер, который я купил очень дешево). В итоге сначала решил проверить саму идею с Speedify, запустив его на кастомной Linux-машине. Связь с агрегацией каналов отлично стабилизировала соединение — переключение происходило без проблем, но вот по производительности было не очень. Скорость никак не дотягивала до обычного подключения Starlink, да и пинги немного выросли из-за дополнительных переходов.

Я использую UDM с моим Starlink на порту 10 и Failover на порту 9. Я также переназначил Wan на порт 10 и Wan 2 на порт 9 (это потому что я использую Sfp-порт с оптоволоконным подключением, чтобы провести Starlink с задней части дома через медиаконвертер). В качестве пункта назначения использую 192.168.100.0/30, расстояние оставляю пустым, интерфейс — Wan.

Кстати, подводя итоги этой темы, мне всё-таки удалось это настроить, создав таблицу маршрутизации на базе политики (policy-based routing). Плохая новость в том, что правила PBR сбрасываются каждый раз, когда USG перепрошивается. Поэтому мне приходится вручную вводить их заново, чтобы статический маршрут Starlink работал. В любом случае, вот правила PBR, которые я использую. Всё отлично работает, как только я подключаюсь по SSH к роутеру и ввожу их.

> configure  
>> set protocols static table 6 interface-route 192.168.100.1/32 next-hop-interface eth2  
>> set firewall modify LOAD_BALANCE rule 2509 action modify  
>> set firewall modify LOAD_BALANCE rule 2509 modify table 6  
>> set firewall modify LOAD_BALANCE rule 2509 destination address 192.168.100.1/32  
>> set firewall modify LOAD_BALANCE rule 2509 protocol all  
>> commit ; save  
> exit

ПРИМЕЧАНИЕ: В указанной команде next-hop-interface предполагается, что кабель Starlink подключён к WAN1. Если подключить к WAN2 — будет eth3.

ПРИМЕЧАНИЕ: Эти команды были описаны в статье справки USG по ссылке ниже. Но Ubiquiti позже убрали эту страницу. Не понимаю, зачем, ведь она была очень полезна и помогла мне решить проблему.  
https://help.ubnt.com/hc/en-us/articles/360005460813-UniFi-USG-Advanced-Policy-Based-Routing

ПРИМЕЧАНИЕ: Я видел в других темах, что можно редактировать конфигурационный файл прямо на роутере, но я быстро запутался в этих всех особенностях кода. Поэтому пока что мне проще вручную вводить правила PBR время от времени. Если интересно, вот статья, где рассказывается, как сделать эти изменения постоянными:  
https://help.ui.com/hc/en-us/articles/215458888-UniFi-USG-Advanced-Configuration-Using-config-gateway-json

@rrussell1009 и @JosephSchulz63 Я протестировал настройку маршрута через SSH для сбора статистики Starlink с сохранением схемы переключения на резерв и уменьшением времени обнаружения сбоев. На самом деле это довольно просто (хотя у меня уже был putty). В основном, я следовал инструкции https://help.ui.com/hc/en-us/articles/218850057-Intro-to-Networking-How-to-Establish-a-Connection-Using-SSH Но это только временное решение, потому что конфигурации SSH, по-видимому, нестабильны. Для постоянного решения нужно использовать json-конфиг, как здесь: https://help.ui.com/hc/en-us/articles/215458888-UniFi-USG-Advanced-Configuration-Using-config-gateway-json Думаю, есть несколько постов с кодом, который можно скопировать и вставить. Однако... я пришёл к выводу, что этого всё ещё недостаточно. Режим отказа Starlink не «обычный» — это не редкий длительный сбой, а короткие перебои по несколько секунд несколько раз в час. Я заметил, что во время Zoom встреч, если время переключения короткое, связь не теряется, но всё равно бывает раздражающая потеря звука. Чтобы это обойти, нужна действительно SD-WAN bonded-сеть, вроде Speedify или Peplink SpeedFusion. Сейчас я тестирую маршрутизатор Peplink Balance с балансировкой нагрузки, который легче настраивать для быстрого переключения, чем мой USG, потому что всё доступно прямо через интерфейс (никакого json). Но если хотите SpeedFusion SD-WAN, выбор моделей ограничен, да и лицензии могут стоить весьма дорого. Думаю попробовать Speedify с Raspberry Pi в роли маршрутизатора, чтобы этого избежать.