[cameron]

начнём с того, что реализация Site-to-Site VPN (LAN-to-LAN) через клиенское подключение и прописываение маршрутов руками неверно.
нужно делать Site-to-Site.
далее у вас появлется адекватная таблица маршрутизации, в которой всем понятко куда и откуда нужно бегать.
соотно в вашей схеме я вижу 3 Site-to-Site туннеля:
192.168.0.0/24 <->192.168.4.0/24
192.168.0.0/24 <->192.168.3.0/24
192.168.3.0/24 <->192.168.4.0/24
тогда, конечно же, не придётся гонять траффик через основной офис (192.168.0.0/24)

а по вопросу динамической маршрутизации - я бы выбрала либо несколько шлюзов с разными метриками, либо аналоги IP-SLA(cisco)/ip-monitoing(juniper), когда делаются два туннеля и в определённых условиях (нет пинга, к примеру) в таблицу маршрутизации заносятся изменения.
Можно, так же, рассмотреть OSPF или BGP.

[Tonny_Bennet]

начнём с того, что реализация Site-to-Site VPN (LAN-to-LAN) через клиенское подключение и прописываение маршрутов руками неверно. нужно делать Site-to-Site. »

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

[cameron]

Повторюсь что сейчас все клиентские шлюзы подключаются к шлюзу центрального офиса, скрипты сами прописывают маршруты, при падении система пытается сама переподключиться. »

тогда я вас не совсем верно поняла.
обычно это и называется Site-to-Site, тогда не нужно писать много слов, а технология становится ясной.

[Tonny_Bennet]

cameron, всегда пытаюсь рассказать как можно подробнее.

Ваше сообщение, меня натолкнуло на мысль поднятия туннеля. Т.е. сейчас есть сервер, есть клиент, логины пароли и процедура авторизации. И при падении клиент должен заново инициализировать соединение. Когда-то я настраивал GRE туннель между двумя Linux системами. В системе он определялся просто как интерфейс tun0. В настройках интерфейса указывались внешние адреса двух взаимодействующих серверов. И, как я понимаю, пакетам просто добавлялся заголовок и пакет передавался на внешний интерфейс второго сервера. Сервер приняв такой пакет снимал заголовок и маршрутизировал дальше. Меня не обрадовало отсутствие шифрования.

Если есть мысли по этому вопросу - прошу озвучить

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

[cameron]

И при падении клиент должен заново инициализировать соединение. Когда-то я настраивал GRE туннель между двумя Linux системами. В системе он определялся просто как интерфейс tun0. В настройках интерфейса указывались внешние адреса двух взаимодействующих серверов. И, как я понимаю, пакетам просто добавлялся заголовок и пакет передавался на внешний интерфейс второго сервера. Сервер приняв такой пакет снимал заголовок и маршрутизировал дальше. »

похоже что, наконец, мы сошлись в понимании процесса.

Меня не обрадовало отсутствие шифрования. »

IPsec over GRE?

По идее мне бы сначала найти вариант передачи трафика между сетями с минимальными количеством настроек на точках, »

я не сильна в Linux системах, но, по описанию похоже, что вы начинаете говорить о том, о чём говорила я.
вот пример
http://clauseriksen.net/2011/02/02/i...-debianubuntu/

[Tonny_Bennet]

IPsec over GRE? »

Чем-то мне не нравился этот вариант и я не стал его использовать.... возможно из за отсутствия острой необходимости в таком тунеле или отсутствия опыта и страха перед последствиями ошибок.

я не сильна в Linux системах, но, по описанию похоже, что вы начинаете говорить о том, о чём говорила я. вот пример http://clauseriksen.net/2011/02/02/i...-debianubuntu/ »

За ссылку спасибо, в ночи или на выходных попробую сделать. Как заработают тунели - вернусь и будем думать, что делать с маршрутизацией

[cameron]

Чем-то мне не нравился этот вариант и я не стал его использовать.... возможно из за отсутствия острой необходимости в таком тунеле или отсутствия опыта и страха перед последствиями ошибок. »

Меня не обрадовало отсутствие шифрования. »

определитесь

[exo]

В качестве шлюза везде используется Ubuntu Server. »

OpenVPN поддерживает Site-to-Site и SSL

Как заработают тунели - вернусь и будем думать, что делать с маршрутизацией »

как заработают тунели - над маршрутизацией будет думать OpenVPN... ну как и другие site-to-site шлюзы...

p.s.: русскоязычная статья про opens\wan

[Tonny_Bennet]

exo, спасибо.

Нашёл ещё одну статью.

Но в любом случае придётся на каждом из пяти шлюзов настроить четыре интерфейса смотрящих в соседние шлюзы.