Привет, ребята! Я новичок в MT (v9.6). Пытался создать кластер VRRP с двумя интерфейсами eth (outside и inside). Моя проблема с VIP на outside. Хочу использовать его для входящих IPsec VPN-соединений. У локального пира (MT) VIP интерфейса outside. Я сделал маршрут по умолчанию для IP-адреса удаленного пира (реальный) с префиксом источника — VIP интерфейса outside, чтобы не нужно было создавать два пира на удаленной локации. Сначала заметил, что монитор отслеживания соединений не отслеживает IPsec-соединение, только TCP/UDP. Второе — после failback, резервный узел пытается подключиться к удаленному пиру со своим собственным IP-адресом, потому что адрес VIP снова занят основным узлом.
Удалённая площадка Локальная площадка
10.0.0.x → Cisco 192.168.1.4 ------> MT vip 192.168.0.4 → lan remote peer 192.168.0.4
remote peer 192.168.1.4 MT BOX-1 192.168.0.2 MT BOX-2 192.168.0.3
В первый раз все работает правильно (Cisco видит VIP MT). После failover, MT BOX-2 пытается подключиться с исходным IP-адресом 192.168.0.4 — это нормально. После failback начинаются ошибки (MT BOX 2 продолжает пытаться подключиться со своим IP-адресом 192.168.0.2, потому что VIP занят основным) и соединение пропадает. Чтобы восстановить соединение, приходится выключать второй MT.
Вопрос: такой сценарий вообще рабочий?
Спасибо.
Удалённая площадка Локальная площадка
10.0.0.x → Cisco 192.168.1.4 ------> MT vip 192.168.0.4 → lan remote peer 192.168.0.4
remote peer 192.168.1.4 MT BOX-1 192.168.0.2 MT BOX-2 192.168.0.3
В первый раз все работает правильно (Cisco видит VIP MT). После failover, MT BOX-2 пытается подключиться с исходным IP-адресом 192.168.0.4 — это нормально. После failback начинаются ошибки (MT BOX 2 продолжает пытаться подключиться со своим IP-адресом 192.168.0.2, потому что VIP занят основным) и соединение пропадает. Чтобы восстановить соединение, приходится выключать второй MT.
Вопрос: такой сценарий вообще рабочий?
Спасибо.
