если не брать скриптовые методы ...
я как-то поднимал два тунеля сразу,
соответственно по 2 маршрута с разными метриками на каждом шлюзе.
если падает 1 канал, то трафик бежит через второй. при большой загрузки канала это вообще не заметно.
только у меня еще интерфейсы был объединены и по 2 IP висело на виртуальном интерфейсе.
у способа есть на мой взгляд только 1 существенный недостаток - сложно отследить момент появления проблемы.
из плюсов:
если у провайдера идет "дребезг" т.е. канал то есть, то нет - то два канала, это выход.
потому, как если проблема у одного провайдера (допустим у основного) пропадает связь - то ВПН-канал прервется, но из-за метрики трафик пойдет сразу же по второму каналу... что как-бы в нашем случае хорошо.
еще на некоторых *nix системах, раньше была возможность программно агрегировать виртуальные интерфейсы,
это вообще крутотень, ибо работает даже быстрее чем метрики.
еще можно поднять 1 канал, но в настройках указать 2 IP сервера
и в дополнение прописать соответственно по 2 маршрута к нему с разной метрикой
в случае проблемы с каналом связи - произойдет разрыв ВПН, и он тут-же попробует переконектиться...
ну этот способ мне не нравиться, уж слишком долгое переключение... пока переподключится.
зато по логам сразу видно что стряслось...