&& rm /tmp/gw.changed

   fi

fi

То есть мы просто «пингуем» шлюз на стороне основного провайдера, и если он оказывается недоступен, то:

n  проверяем работоспособность резервного канала;

n  перенастраиваем маршрут по умолчанию на шлюз резервного канала;

n  оставляем «метку» /tmp/gw.changed, сигнализирующую о смене шлюза.

При следующем выполнении (например, скрипт можно запускать по cron раз в минуту), если GW1 в норме и есть «метка», то возвращаем основной шлюз на место. Если оба шлюза недоступны, текущее состояние не меняем. Показанный пример упрощён (в частности, могут потребоваться перенастройка NAT-сервера и правил файерволов для работы с новым шлюзом), но для понимания принципа работы достаточен.

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

Более серьёзной проблемой, чем может показаться на первый взгляд, является выбор ресурса, доступ к которому будет проверяться. Например, если выбрать в качестве такового шлюз или DNS-сервер провайдера, то в случае аварии на внешнем канале провайдера эти ресурсы будут доступны, и переключение на резервный канал не произойдёт.

Можно пытаться определять доступность некоторого удалённого ресурса (скажем, сервера yandex.ru), указывая с помощью ключа -S команды ping конкретный IP-адрес источника для отправляемых пакетов (понятно, что этот адрес должен «заворачиваться» в нужный интерфейс):

ping -S 10.0.1.2 yandex.ru

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

Заключение

Как видите, при желании можно решить почти любую задачу. Хотя приходится констатировать, что системе FreeBSD явно недостаёт возможностей пакета iproute2, используемого в Linux. Если бы была возможность, скажем, указывать несколько шлюзов по умолчанию с разными метриками, многие проблемы эффективного использования нескольких внешних каналов решались бы гораздо элегантнее.