Тогда полагаю, что модем выступает как NAT и вы строите обратный SSH тоннель?
Пару доп вопросов:
1) Есть возможно поднять сразу два модема?
2) Если поднять два модема, можно на одной поставить адрес 192.168.8.100, а на другом 192.168.8.101 ?
Если да, то Вам должен помочь policy-routing. Можно привязать через какой интерфейс должен бегать ssh и тогда падение-поднятие второго интерфейса никак на него не будет влиять. https://habr.com/ru/post/108690/
dlinyj, Куда вы эти модемы подключаете? Я предполагал, что у Вас Linux ПК с сетевым интерфесом, тогда можно привязаться к проводному интерфейсу и дергать другие интерфейсы сколько угодно.
Такие схемы как у Вас я тоже встречал и если маршрут на 1.1 прописал корректно, то все должно работать.
С 121 опцией тоже игрались, когда у одного ПК было два интерфейса и надо было разрулить маршрутизацию. С одной стороны ему отдавали default, а с другой - выбранные сети. Были клиенты которые не корректно отрабатывали. Особенно порадовал DNS клиент на windows 10 который СРАЛ на правила маршрутизации и рассылал запросы сразу со всех интерфейсов.
Я бы порекомендовал бриджевать все ВМ во внутреннюю сеть. ВМ получали бы IP с основного роутера и не надо было мучаться с маршрутизацией.
Или поднять маршрутизатор на Linux и указать его в качестве GW для всех ПК и ВМ.
Хотел посмотреть как Вы статический маршрут прописали, тут ламеров хватает.
Даже если маршрут на HG659 будет работать то маршрутизация у Вас все равно будет ходить треугольником потому как сервер и Ваш ПК в одной сети (см скриншот). Тут выплывает второй момент, возможно после добавления статического маршрута на HG659 пинг пинг добегает до 10.0.3.3 но назад не возвращается т.к. его режет firewall на вашем ПК. т.к. он ждет ответ от 192.168.1.1, а ответ приходит от 192.168.1.2.
Надо выполнить диагностику. Запустить tcpdump на 10.0.3.3 и посмотреть приходит ли пинг от 1.10, если приходит, то запустить wireshark на 1.10 и смотреть приходит ли ответ на пинг.
Все под свои задачи.
NFS
- проще в настройке
- стабильние в проблемных сетях (потеря пакетов)
iSCSI - можно сравнить с SATA поверх ethenet - попробуйте выдернуть SATA шнурок на ходу что бы система не полетела.
- быстрее чем NFS т.к. меньше накладных расходов на транспорт, но что бы получить все плюшки надо использовать сетевое оборудование с поддержкой 9k.
- требовательных к сети (все должно быть стабильно!!)
- на некоторых типах хранилищах может требовать лицензию.
На лицо проблема с маршрутизацией.
Скорее всего на хостах в сети 172.16.116.0/22 указал GW который ничего не знает про сеть VPN клиентов). Когда вы включаете NAT соответственно, GW уже не участвует в маршрутизации трафика.
Зачем Вам 2ва интерфейса на VPN сервере?
VPN сервер может добраться до сети 172.16.116.0/22 через gw в сети 192.168.16.3/24 ?
По накладным расходам лучше gre+ipsec. Что бы интернет не ходил через VPN надо маршруты правильно писать (в VPN заворачивать только сети других филиалов, а default gw делать на WAN)
