Комментарии
Про использование SD-WAN для выхода в интернет, тут все хорошо, т.к. наружу адрес натится и вернется через того же провайдера что и ушел.
А вот при использовании между двумя офисами тут не все так просто, ибо sd-wan в одном офисе ничего не знает про sd-wan в другом. Поэтому когда трафик уходи из одного офиса в другой по выбранным критериям в офисе, по одному каналу, то не факт что он вернется по этому же самому а не другому.

Подскажите есть-ли какой-то механизм заставить отправлять ответ, через тот же канал через который пришло соединение?
Здесь речь о том, что у вас идёт TCP-сессия из точки А в точку Б, а обратный трафик не разрешён правилами межсетевого экрана, но он пропускается, так как принадлежит к TCP-сессии, открытой изнутри (классический Stateful Firewall). При этом сессия сохраняется с указанием входящего и исходящего интерфейсов межсетевого экрана. А потом вдруг обратный трафик приходит не на тот же интерфейс, с которого ушёл исходящий, а значит не на тот, который записан в таблице сессий. Этот трафик блокируется. Чтобы такого не происходило, можно включить Auxiliary-сессию, тогда межсетевой экран будет открывать сессию и по второму интерфейсу тоже, просто чтобы она была в таблице и обратный трафик, приходящий на другой интерфейс, разрешался.

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

это разрешает асинхронный трафик, и не решает проблему.
Это скорее про ситуацию, когда нам важно, чтобы трафик дошёл и мы готовы тратить на это в два раза больше пропускной способности. Например транзакция от банковского терминала — если мы её потеряем, то клиенту придётся второй раз прикладывать карту. При этом данных там килобайты, поэтому их не жалко передать два раза одновременно по разным каналам.
Если для какого-то трафика это принципиально, то я бы сделал это с помощью SD-WAN Policy. Заматчил трафик по L3-L4-критериям или по приложению, а в Action-части задал бы SD-WAN-туннели с одинаковым приоритетом с обеих сторон.

Но на самом деле не факт, что это всегда нужно. Если вдруг у вас канал выдаёт не одинаковое качество на Upstream и Downstream (и Probe это покажут), с точки зрения качества работы приложения, лучше будет передать одно из направлений через другой канал.
Мы же рассматриваем " самого демократичного из SD-WAN" а FortiManager это уже лишние затраты и не малые.

Централизованное управление, мониторинг и аудит все же необходим. И цена в общей стоимости проекта не такая уж и большая. Плюс есть возможность облачной подписки.

У всех вендоров ценовая политика разная — кто-то за компоненты управления денег не берёт, но это не значит, что совокупно его решение во всех случаях окажется дешевле, дороже могут оказаться оконечные устройства или лицензии на них. А могут и не оказаться.

Лучше всегда сравнивать общую цену решения для конкретной задачи — конкретного количества филиалов, производительности устройств, которые там нужны, функционала этих устройств и компонентов управления. Причём, и разовое вложение — при покупке, и ежегодные — обновления, техподдержка, подписки.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.