Отказоустойчивость при межсетевом взаимодействии.

[kotohrun]

Добрый день.
Помогите пожалуйста разобраться.
При установленном МСВ данные ходят только через шлюзовые координаторы и если мой координатор выходит из строя, то связность теряется?
Со стороны моей сети есть 2 координатора, только один из них я могу поставить шлюзовым. Если я добавлю второй в ЦУС -> Доверенные сети -> Свойства сетей -> Сетевые узлы что это мне даст? Второй координатор построит туннель до доверенной сети? Трафик через него будет ходить при выходе из строя шлюзового координатора?

ЦУС: 4.6.1.3861
Координатор HW1000, версия ПО: 4.3.2-3365

[Заикающийся]

При таких вопросах обычно рисуют схему: удобно для всех участников процесса.

[R.Sheyn]

"шлюзовые" координаторы отличаются от обычных, тем, что через них по умолчанию ходит между сетями mftp.

В остальном при взаимодействии с доверенной сетью все принципы взаимодействия такие же как и внутри вашей сети.

Если вы добавите второй координатор в связи с координатором доверенной сети, то туннель он построит при наличии сетевой связности, а вот уже как трафик и куда будет ходить это другой вопрос, который как минимум требует схемы с адресацией.

[kotohrun]

Спасибо, за ваши ответы.

Простите за кривую схему.

https://drive.google.com/file/d/1BYdLZ_rcdYIpBtTaPcKaBHed3EVEmWCS/view?usp=sharing

Сейчас установлено МСВ, с моей стороны в качестве шлюзового координатора выбран Coordinator1. Он же в списке узлов для этой доверенной сети. Хост 10.0.0.1 туннелируется через него же.
Собственно мой вопрос: я могу поднять туннель ещё и между Coordinator2 и Coordinator3 таким образом чтобы при падении одного из каналов трафик шёл через второй?
Если да, то ещё вопрос: у Coordinator3 получится 2 маршрута до 10.0.0.1 так? Не получится ассиметричного роутинга?

[R.Sheyn]

1 час назад, kotohrun сказал:

Спасибо, за ваши ответы.

Простите за кривую схему.

https://drive.google.com/file/d/1BYdLZ_rcdYIpBtTaPcKaBHed3EVEmWCS/view?usp=sharing

Сейчас установлено МСВ, с моей стороны в качестве шлюзового координатора выбран Coordinator1. Он же в списке узлов для этой доверенной сети. Хост 10.0.0.1 туннелируется через него же.
Собственно мой вопрос: я могу поднять туннель ещё и между Coordinator2 и Coordinator3 таким образом чтобы при падении одного из каналов трафик шёл через второй?
Если да, то ещё вопрос: у Coordinator3 получится 2 маршрута до 10.0.0.1 так? Не получится ассиметричного роутинга?

во-первых не очень понятно как вы собираетесь переключать маршрут до 192.168.1.1/24 при падении канала.

во-вторых не получится, так как Coordinator3 загрузит туннель 10.0.0.1 только для одного вашего координатора, ибо пересечение.

[gorbushka]

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

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

Как сделать правильно?

 

[R.Sheyn]

На "той" стороне для одного из ваших координаторов должна быть установлена реальная видимость туннелей, для другого виртуальная. Это единственный вариант.

Но вы написали про нат. И тут надо понимать что именно они у себя делают. Если подразумевается, что соединение устанавливается с их стороны и у них dnat, то такая схема работать не будет.

[gorbushka]

3 часа назад, R.Sheyn сказал:

На "той" стороне для одного из ваших координаторов должна быть установлена реальная видимость туннелей, для другого виртуальная. Это единственный вариант.

Но вы написали про нат. И тут надо понимать что именно они у себя делают. Если подразумевается, что соединение устанавливается с их стороны и у них dnat, то такая схема работать не будет.

Выяснили, что на их стороне на самом деле не НАТ. Они собираются к нам ходить, используя виртуальные адреса(ну можно сказать NAT на iplir ). То есть наш опубликованный в туннель адрес они у себя в конфиге в секции каждого нашего координатора исправляют на свой виртуальный. Получается у них два адреса. Соответственно собираются обращаться к нашему адресу, используя виртуальные. Возможно в варианта DNS roundrobin. Правильно ли я понимаю, что по-прежнему остаётся вариант,  когда они, обращаясь к виртуальному адресу 1, попадут к нам в сеть через первый координатор, а обратно с нашей стороны в сторону их сети маршрут может быть через второй наш координатор, соответственно удаленный координатор не сможет сопоставить такой ответ?

 

[R.Sheyn]

16.04.2021 в 09:48, gorbushka сказал:

а обратно с нашей стороны в сторону их сети маршрут может быть через второй наш координатор

это зависит от того, как настроена "балансировка" с вашей стороны.

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