Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Сбой site to site VPN после переключения на резервный канал., UniFi Network
 
Всем привет!  
Один из наших объектов использует USG 3P для site-to-site VPN с Zyxel USG. На объекте есть два WAN PPPoE подключения, второе настроено как резервное. VPN работает нормально, кроме одного случая, когда соединение переключилось на резервное, а потом так и не вернулось обратно после того, как проблема с WAN1 была решена. Позвольте объяснить:  
WAN1 испытывал проблемы примерно 3-4 часа, поэтому трафик переключился на WAN2, как и должно было быть. После того как проблема с WAN1 была устранена и IPsec-туннель восстановился, через VPN трафик не шел. По результатам show route я увидел, что основным интерфейсом для USG по-прежнему является WAN2. Можно ли как-то сделать так, чтобы основной WAN возвращался к работе после устранения проблемы и сброса на резервный?
 
Я пытался вручную выполнить  
sudo ipsec down peer-<REMOTE_SITE_IP>-tunnel-vti  
sudo ipsec up peer-<REMOTE_SITE_IP>-tunnel-vti  
Тоннель устанавливается, но через него не проходит трафик. При выполнении show vpn ipsec sa видно, что туннель установлен, но принят 0 байт. Если проверить на другом сайте, там тоже 0 байт. Следующий шаг — зайти в контроллер, отключить и включить туннель, обычно это возвращает связь. Если и это не помогает, перезагрузка USG с обеих сторон восстанавливает соединение.
 
@jorrel - Этот скрипт вообще работает?
 
Мне удалось снова запустить туннели без перезагрузки, но пока только с ручным вмешательством. После переключения на резерв и обратно я могу выполнить на USG следующие команды:  
sudo ipsec down peer-<REMOTE_SITE_IP>-tunnel-vti  
sudo ipsec up peer-<REMOTE_SITE_IP>-tunnel-vti  
Это отключает туннель и позволяет мне его переподключить.  

Следующий шаг — добавить скрипт перехода или «захватить» для этого уже существующий. В логах я нашёл такие события:  
Feb 18 16:27:24 Gateway-RD wan-event: [WAN Transition] eth2 to state active
Feb 18 16:27:47 Gateway-RD wan-event: [WAN Transition] eth0 to state active
Feb 18 16:27:47 Gateway-RD wan-event: [WAN Transition] eth2 to state failover

Скрипт, который их создаёт и отправляет отчёты на контроллер, находится здесь:  
/config/scripts/wan-event-report.sh  

Я изменил скрипт, дописав в конце вот что (начинается с «Reset VPN tunnel...»):  
#!/bin/bash

# File: wan-event-report.sh  
# Desc: Сообщает контроллеру о событиях перехода WAN. Этот скрипт должен быть настроен в узле конфигурации  
#       "load-balance group <GROUP_NAME> transition-script". Если скрипт для отправки на контроллер не найден, то пишет в syslog.

REPORT_SCRIPT=/usr/bin/mca-custom-alert.sh  
NAME=wan-event  
EVENT_STRING="EVT_GW_WANTransition"  
IFACE=$2  
STATE=$3  

logger -t $NAME -- "[WAN Transition] $IFACE to state $STATE"
[ -f $REPORT_SCRIPT ] && $REPORT_SCRIPT -k event_string -v "$EVENT_STRING" -k iface -v "$IFACE" -k state -v "$STATE"

# Сброс VPN туннеля, когда eth0 становится активным.  
if [ "$IFACE" = "eth0" ] && [ "$STATE" = "active" ]; then
   TUNNEL="peer-<REMOTE_SITE_IP>-tunnel-vti"  
   /usr/sbin/ipsec down $TUNNEL  
   /usr/sbin/ipsec up $TUNNEL  
fi  

Строку TUNNEL можно получить, взяв префикс из вывода команды ipsec statusall. Сейчас жду, когда AT&T опять уйдёт в сбой, чтобы проверить, сработает ли скрипт так, как я и ожидал.
 
У меня всё чаще возникает эта проблема в последнее время. С обеих сторон туннелей стоят обновлённые USG и USG-PRO. На стороне USG у нас беспроводное соединение, поэтому WAN2 — это резерв на базе GSM. Переключение соединения происходит нормально, но когда WAN1 возвращается, я так и не понял, как поднять VPN без перезагрузки... Опять простой системы.
 
У нас такая же проблема с несколькими сайтами. Как только происходит переключение на резервное соединение и обратно на основное, нам приходится вручную удалять Site to Site VPN и создавать его заново, чтобы связь восстановилась. Это лишний простой, который сайтам совсем не нужен. Все дошло до того, что мы ищем другую VPN-решение и, возможно, даже полностью отказываемся от Unifi, особенно после того, как узнали, что эта проблема существует уже много лет — ну что за к черту...
 
У меня точно такая же проблема, кто-нибудь знает, как её решить?
 
Вы не одни... Point-to-Point VPN нормально работает между двумя USG Pro 4. Но если один из них переключается на WAN2, а потом возвращается обратно к WAN1, туннель VPN отображается как ESTABLISHED, но трафик не проходит, пока не перезапустишь USG.
 
Мы уже много лет сталкиваемся с этой же проблемой и не раз обращались в Ubiquiti по этому поводу. Последний ответ получили месяц назад, когда я напомнил про баг, который уведомил больше года назад: «Я уточнил у своей внутренней команды. Эта проблема до сих пор не исправлена. Точной даты исправления нет». Две основных функции UniFi: автоматическое переключение WAN и туннели Site-to-Site. Отличные функции, но они становятся бесполезными, когда пытаешься использовать их вместе...
Страницы: 1
Читают тему (гостей: 1)