То что Windows исторически может использовать несколько default gateway на одном сетевом адаптере - это скорее историческая особенность, нежели киллерфича.Итак, допустим вы проставили 2 default gateway на одном и том же сетевом адаптере. Это предполагает, что как минимум они оба есть и оба существуют в сети и даже работают, что уже жутко странно...
Исторический замысел был в том, что все гейтвеи пишутся в список. Один главный, а остальные - запасные. Типа если умер первый гейтвей, то нужно пустить пакеты по второму. В теории может оно и нормально звучит, но на практике там есть жуткое ограничение: живость и мёртвость гейтвея определяется через протокол TCP. Windows посчитает, что пора переключаться, если достигнет половины значения TcpMaxDataRetransmissions (то есть по молчанию на 3-ю пересылку ACK). А теперь подумайте, что это всё значит, сколько будет ложных переключений, что делать если вы шлёте исходящие UDP, как вернуться назад, когда первый гейтвей "ожил" и какие временные рамки такого переключения. Это всё технологии времен Windows 2000, а то и раньше. Короче, всё очень плохо.
В современном мире в рамках корпоративной сети довольно сложно представить 2 гейтвея с разными IP внутри одной сети. Если их делали ради отказоустойчивости, то имеет смысл объявить мост внутри которого есть VRRP и вот там вот всё само по себе отказоустойчиво переключается. Спецификация протокола VRRPv3, хоть и придумана ради IPv6, поддерживает очень быстрые переключения виртуальных IP в том числе для IPv4. Опять же, это всё при том, что это гейтвеи на граничных роутерах. А если там еще что-то есть третье тоже отказоустойчивое или между ними есть физическое соединение через менеджмент сеть (эта сущность сетевой топологии должна быть построена полностью отдельно) для управления роутерами, то логично было бы повесить сессию протокола BFD на эти роутеры и еще больше ускорить переключение в отказоустойчивом сценарии. Опять же, если роутер умеет.
Или допустим у вас есть 2 сетевых интерфейса с разными сетями и разными гейтвеями в этих сетях. Тут есть варианты:
1. Это 2 сети в рамках одной корпоративной сети и поэтому выход во внешку производится через один (ну может быть 2 в смысле отказоустойчивости) роутер. Если всё идет через одно и то же оборудование, в этом случае второй маршрут по умолчанию нужно просто убрать.
2. Если у вас есть 2 разных сети которые физически никак не пересекаются (2 провайдера, например). То такая вот "отказоустойчивость" и "резервный интернет" времён Windows 2000 скорее даст больше боли, чем решения проблем по следующим причинам
- доступность шлюза по умолчанию не гарантирует, что сеть есть.
- Windows-специфичные TCP-проверки игнорируют UDP, также возможны ложные срабатывания
- Возвращаться назад после включения шлюза как будете? Особенно феерично, если каналы не симметричные.
В этой ситуации рекомендуется написать сценарии мониторинга перечня внешних IP-адресов и переключать себе шлюз по умолчанию скриптами. Windows там у вас или Linux с NetworkManager не имеет значения. Только скрипты. А если хочется автоматического переключения без костылей, купите себе AS и освойте eBGP c Full View на своих корпоративных роутерах.
3. Это 2 разные сети, которые финально обслуживаются одним роутером, но физически идут по разным коммутаторам. Тут тоже есть варианты:
3.1 Если это стоит в серверной/датацентре, то вы уволены^W не верно настроили сеть датацентра. Вам нужно пересмотреть Access-уровень вашей сети так, чтобы использовать Bond через LACP/802.3ad, если у вас стек Access-коммутаторов. Можно также собрать из пары коммутаторов MLAG, если вам важна скорость переключения в случае выхода из строя коммутатора. Если у вас нет технической возможности подружить коммутаторы чтобы дать на сервер агрегационную группу (LAG), то вы можете использовать другие варианты Bond-соединений. И вот это всё NetworkManager поддерживает. B Windows тоже поддерживает через его NIC Teaming или через новый модуль тиминга поверх виртуального коммутатора Hyper-V.
3.2 Если у вас там просто сеть (в смысле campus network) и приходят веревки, например, с разных корпусов, то это опять лучше переключать скриптами, а не тем, что предлагает Windows.
Пожалуйста, не пользуйтесь этой функцией ни на Windows, ни где бы то ни было еще. Эти трюки 25-летней давности не актуальны. Оно переключается как попало, оно не защищает от реальных сбоев. Настройте лучше себе сеть по нормальному. Эту бяку из Windows-то хотели выпилить, а вы спрашиваете почему этого мрачного легаси нету в NetworkManager.
