HW1000 4 Failover и резервный канал

[volosnikov]

Камрады!

На HW 3-й версии мы "резервировали" каналы стандартным кластером горячего резервирования.
Два провайдера: один - в 1-ый HW кластера, другой - во 2-ой HW.
В случае падения "основного" провайдера, активный HW (testip) - перезагружался, пассивный становился активным и гонял трафик через "резервного" провайдера.

На HW 4 такой "трюк" теперь не пройдет? В том смысле, что активная нода с удовольствием передает пассивной свой шлюз по умолчанию, который, как бы, шлюзом  для пассивной никак не может быть (другой провайдер).

Или я чего-то не дочитал? Ткните, пожалуйста, в нужное место.

[R.Sheyn]

6 минут назад, volosnikov сказал:

Камрады!

На HW 3-й версии мы "резервировали" каналы стандартным кластером горячего резервирования.
Два провайдера: один - в 1-ый HW кластера, другой - во 2-ой HW.
В случае падения "основного" провайдера, активный HW (testip) - перезагружался, пассивный становился активным и гонял трафик через "резервного" провайдера.

На HW 4 такой "трюк" теперь не пройдет? В том смысле, что активная нода с удовольствием передает пассивной свой шлюз по умолчанию, который, как бы, шлюзом  для пассивной никак не может быть (другой провайдер).

Или я чего-то не дочитал? Ткните, пожалуйста, в нужное место.

Оригинальный метод ) в 4й версии маршрутизация синхронизируется, поэтому такой трюк не пройдет. Ставьте балансировщик перед координатором.

[volosnikov]

19 минут назад, R.Sheyn сказал:

Ставьте балансировщик перед координатором.

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

Спасибо отечественному производителю! 

[R.Sheyn]

46 минут назад, volosnikov сказал:

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

Спасибо отечественному производителю! 

Ну стоит понимать, что это все таки в первую очередь КШ, а потом уже все остальное. Хотя у Континента есть например.

[zero]

Описанная схема никогда официально не поддерживалась, так как файловер изначально это два ПАК скоммутированные и настроенные синхронно по интерфейсам и полностью дублирующие работу друг друга. Пока без внешнего балансировщика действительно не обойтись. В версии 4.3 обещают DGD ( Dead Gateway Detection ) и тогда можно будет настроить без него.

 

[volosnikov]

6 минут назад, zero сказал:

Описанная схема никогда официально не поддерживалась

Не надо ее поддерживать! Зачем вот сломали . . .
Опять придется что-то придумывать.

[zero]

1 минуту назад, volosnikov сказал:

Зачем вот сломали . . .

Потому, что клиенты, которые использовали ПАК в соответствии с документацией, просили сделать резервирование таблицы маршрутизации. И это как бы логично.

Про Ваше решение "на коленке" никто ничего не знал, поэтому оно вполне ожидаемо перестало работать. Но скоро заработает уже официально и надёжно, а не как сейчас: что будет если ляжет один провайдер и сломается ПАК на втором канале? Бежать в серверную и все перенастраивать?

 

[volosnikov]

Ну что вы сразу валите (с)  ))

9 минут назад, zero сказал:

И это как бы логично

Для каких тогда клиентов, которые все и всегда делают по документации (omg), в failover.ini необходимы столь ценные параметры:

[sendconfig]
config =
keys =
journals =

 

[zero]

5 минут назад, volosnikov сказал:

Для каких тогда клиентов, которые все и всегда делают по документации (omg), в failover.ini необходимы столь ценные параметры

Эти параметры, включены по-умолчанию, а также об этом честно сказано:

Не рекомендуется устанавливать параметры config и keys в значение no, так как это может привести к некорректной работе ПО ViPNet.

Дальше уже на свой страх и риск, как говорится.

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

 

 

[volosnikov]

Великолепно на HW 3 без "send config" обруливалсь ситуация с NAT-ом по внешним адресам...

Правда вручную приходилось поддерживать туннели, но их не Бог сколько, однажды сделал и забыл.
Ладно, ждем 4.3 ...  

[R.Sheyn]

14 минут назад, volosnikov сказал:

Великолепно на HW 3 без "send config" обруливалсь ситуация с NAT-ом по внешним адресам...

Что вы имеете ввиду?)

[volosnikov]

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

Что вы имеете ввиду?)

firewall.conf

. . .

[nat]
rule= num 1 proto any from 192.168.1.1-192.168.1.254 to anyip   change src=8.8.8.8

. . .

Что-то типа этого. Идея понятна?

[zero]

19 часов назад, volosnikov сказал:

change src=8.8.8.8

Вот именно это точно чинили, чтобы натить в не свои адреса было нельзя. Или Вы в Гугл работаете?

[volosnikov]

2 минуты назад, zero сказал:

Или Вы в Гугл работаете?

8-ки - пример внешних адресов.

При синхронизации конфигураций, на пассивную ноду улетает правило с src= внешнему IP активной ноды.
Соответственно при переключении NAT-ы не работали.

send config = no       решало эту проблему.

[zero]

config — включение или выключение резервирования группы конфигурационных файлов. Возможные значения: yes (по умолчанию) или no. В группу входят следующие конфигурационные файлы:
файл iplir.conf;

файлы iplir.conf-<интерфейс или группа интерфейсов>, кроме файла для интерфейса резервного канала;
 файл mftp.conf
 файлы, содержащие сетевые фильтры и правила трансляции (заданные пользователем и полученные из программы ViPNet Policy Manager);
 файлы с настройками функции L2OverIP;
 файлы *.crg с контрольными суммами конфигурационных файлов;
 файлы с настройками маршрутизации  и статическими маршрутами (если такие создавались);
 другие служебные конфигурационные файлы.

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

 

[volosnikov]

23 часа назад, volosnikov сказал:

Правда вручную приходилось поддерживать туннели, но их не Бог сколько, однажды сделал и забыл.

 

[volosnikov]

В 23.10.2018 в 12:09, R.Sheyn сказал:

Ставьте балансировщик перед координатором.

Слава Богу обошлись без этого, все решилось стандартными для HW способами 

В документации забыли удалить этот абзац.

[Rinya]

А можно немного поподробнее как обошлись?

[volosnikov]

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

А можно немного поподробнее как обошлись?

Отказались от статического дефолтного маршрута и воспользовались:

failover.ini
afterifconf =