USG 3 — отказоустойчивость не работает

USG 3 — отказоустойчивость не работает, UniFi Network

randomusername

Guest

12.05.2017 16:04:00

Привет! У меня проблема с моим USG 3 — отказоустойчивость работает не так, как ожидалось. Моя текущая настройка:
USG 3P - 4.3.41.4975503
eth0 (WAN1) подключен через PtP Wi-Fi ссылку к удалённому роутеру (192.168.1.254)
eth2 (WAN2) подключён к локальному маршрутизируемому ADSL соединению (5.153.x.x)
eth2 настроен только на отказоустойчивость
VOIP порт переназначен в настройках на WAN2.

Если Wi-Fi связь обрывается, переключение на WAN2 происходит не полностью:
admin@UnifiSecurityGateway:~$ show load-balance status
Group wan_failover
interface : eth0
carrier : up
status : failover
gateway : 192.168.1.254
route table : 201
weight : 0
flows WAN Out : 130000
WAN In : 524
Local Out : 240451
interface : eth2
carrier : up
status : active
gateway : 5.153.x.x
route table : 202
weight : 100
flows WAN Out : 6844
WAN In : 20149
Local Out : 26529

admin@UnifiSecurityGateway:~$ show load-balance watchdog
Group wan_failover
eth0 status: Waiting on recovery (0/3)
pings: 3
fails: 3
run fails: 3/3
route drops: 4
ping gateway: 8.8.8.8 - DOWN
last route drop : Fri May 12 15:54:08 2017
last route recover: Fri May 12 15:44:13 2017

eth2 status: Running
failover-only mode
pings: 82
fails: 0
run fails: 0/3
route drops: 15
ping gateway: 8.8.8.8 - REACHABLE
last route drop : Fri May 12 16:21:09 2017
last route recover: Fri May 12 16:31:07 2017

Маршрутизирующая таблица:
S>* 0.0.0.0/0 [1/0] via 192.168.1.254, eth0
S 0.0.0.0/0 [220/0] via 5.153.x.x, eth2
C>* 5.153.x.x/30 is directly connected, eth2
S>* 10.0.3.0/24 [1/0] is directly connected, eth2
C>* 10.10.0.0/23 is directly connected, eth1
S>* 10.254.254.0/24 [1/0] is directly connected, eth0
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.1.0/24 is directly connected, eth0

Watchdog определил, что не может пинговать 8.8.8.8 и переключился на второе соединение. Однако клиенты не могут выйти в интернет — всё зависает по таймауту.

Если я физически вытяну кабель с eth0, таблица маршрутов меняется и трафик снова начинает идти:
S 0.0.0.0/0 [1/0] via 192.168.1.254 inactive
S>* 0.0.0.0/0 [220/0] via 5.153.x.x, eth2
C>* 5.153.x.x/30 is directly connected, eth2
S>* 10.0.3.0/24 [1/0] is directly connected, eth2
C>* 10.10.0.0/23 is directly connected, eth1
S 10.254.254.0/24 [1/0] is directly connected, eth0 inactive
C>* 127.0.0.0/8 is directly connected, lo

Есть идеи, в чём может быть проблема, или это баг?

UI-Team

Guest

21.08.2017 15:47:00

@MarkCarragher

*редактирование* Рад слышать, что переключение на резервный канал у тебя работает как надо! Сейчас пробросы портов на USG настраиваются только на WAN1. Они будут работать на WAN2 при переключении, но для сохранения настроек нужно вручную прописать правила DNAT для WAN2 в файле config.gateway.json. Чтобы включить это в рабочую конфигурацию, можно сделать так:

configure
set service nat rule 4500 type destination
set service nat rule 4500 destination address <wan2_address>
set service nat rule 4500 destination port <port#>
set service nat rule 4500 inside-address address <target_lan_ip>
set service nat rule 4500 inside-address port <port#>
commit; exit

После этого просто добавь правило фаервола на WAN_IN, разрешающее доступ по адресу назначения (target_lan_ip) и порту.

MarkCarragher

Guest

19.08.2017 20:12:00

@UBNT-jaff

Рад сообщить, что могу подтвердить: эта девелоперская прошивка действительно исправляет мягкий и жёсткий failover на USG. Теперь при мягкой ошибке переключение происходит примерно через 3 минуты. При восстановлении подключения переключение обратно на WAN1 происходит почти мгновенно. Я проверял жёсткий failover (отключал кабель) и мягкий failover (отключал телефонный кабель DSL-маршрутизатора). Также проверял переключение обратно на WAN1, подключая телефонный кабель DSL-маршрутизатора.

Стоит отметить, что у меня оба WAN-интерфейса на USG настроены на внутренний DNS-сервер (OpenWRT), который просто кеширует и перенаправляет запросы на Google DNS. Так что единственная оставшаяся проблема — это правильное переключение порт-форвардинга между WAN2 и WAN1. Сейчас при переключении порт-форвардинги остаются на WAN1 и поэтому не работают. Однако это не было указано в списке изменений для этой прошивки, так что я и не рассчитывал на улучшения в этом плане.

Спасибо!

MarkCarragher

Guest

18.08.2017 21:33:00

Отлично, с нетерпением жду возможности протестировать это. Я создал статический маршрут на основе интерфейса. Резервное переключение (soft) сработало, но ни один ПК за USG не мог выйти в сеть, хотя разрешение DNS работало — очень странно. Линукс-сервер, который я подключил после переключения, работал без проблем, а вот ничего другое — нет. Сейчас протестирую прошивку dev link и потом напишу обновление.

UI-Team

Guest

18.08.2017 21:30:00

@MarkCarragher

С PPPoE можно просто использовать маршрут интерфейса, ведь это буквально точка-точка. Если использовать USG 4.3.54dev — маршрут не должен быть нужен. Эта версия исправляет все аппаратные и программные переключения (по крайней мере, всё, что я тестировал) https://community.ui.com/releases/afe46715-3f49-4f9d-b8a2-8ca567f8ccc4. Единственная возможная проблема — если у вас нет DNS-сервера, который указывает на оба WAN. Если же настроен только один DNS-сервер, добавьте 127.0.0.1 в одну из записей DNS-сервера в настройках WAN USG через контроллер GUI.

MarkCarragher Guest	#6 18.08.2017 14:07:00 @UBNT-jaffe Мой интерфейс WAN2 — это PPoE-соединение, так что как я могу использовать это для тестирования статического маршрута, если IP назначается при начале сессии? Спасибо.

UI-Team Guest	#7 04.08.2017 15:22:00 @amjc Убедись, что «Network» в статическом маршруте — это DNS-сервер, настроенный в /etc/resolv.conf, а «next hop» должен быть IP-шлюзом твоего WAN2.

amjcf Guest	#8 03.08.2017 22:29:00 Есть ли у кого-нибудь возможность показать пример того, как должна выглядеть эта статическая маршрутизация в интерфейсе USG? Я уже перепробовал несколько вариантов, но ничего не выходит. Заранее спасибо!

UI-Team

Guest

03.08.2017 20:20:00

@MarkCarragher

Отключение кабеля считается "жёстким" переключением на резервный канал, и это работает как задумано (за исключением переключения порт-форвардинга). Ваше переключение на резерв до отключения кабеля считается мягким, и его можно исправить тем, что я описал в последнем ответе — создать статическую запись маршрута в GUI, направляющую DNS-сервер через WAN2. Для этого не нужно использовать SSH или создавать config.gateway.json.

Согласен, что порт-форвардинг должен автоматически работать через WAN2 при переключении без всяких ручных ухищрений. Эта проблема известна и над ней работают вместе с десятками других фич. Точного времени, когда это появится, сказать не могу, это не в моей компетенции. Насколько я знаю, функционал WAN и IPv6 сейчас в приоритете. Создание таких функций занимает время, и, как я уже не раз говорил в других обсуждениях,

@UBNT-cmb

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

MarkCarragher Guest	#10 03.08.2017 19:05:00 @UBNT-jaffe

MarkCarragher

Guest

#11

03.08.2017 19:04:00

Спасибо за ответ и предложенное решение, которое я уже нашёл на форуме. Но в итоге это не отвечает на вопрос, когда USG начнёт работать как положено без обходных путей и манипуляций с конфигурационными файлами. WAN Failover (и возврат назад) с перенаправлением портов — это основная функция роутера с двумя WAN-портами, которая с момента выпуска не работает, и кажется, что нет никаких сроков её исправления. Также при тестировании WAN Failover я не мог пинговать через USG, пока не отключил кабель с WAN1. Поэтому не уверен, связано ли это с DNS, ведь монитор Failover пингует сервер UBNT, чтобы проверить, жив ли он. Статические маршруты, правки json-файлов и прочее — всё это непонятные и сложные задачи для такой простой функции, как WAN Failover. USG, похоже, принудительно встроен в систему UniFi, отойдя от своей основы — EdgeRouter. Может, сообществу всё же дадут сроки, когда это заработает так, как ожидалось и заявлено? Ждать больше года решения — просто неприемлемо, особенно для функции, которой даже обычный двухпортовый WAN-роутер управляет уже много лет. USG даёт большое преимущество в виде централизованного управления и единого интерфейса для администрирования сети, но всё это нивелируется тем, что основная функция — двух WAN и Failover — не работают.

UI-Team

Guest

#12

03.08.2017 18:54:00

Порт-форварды, настроенные через GUI, автоматически ставятся с адресом назначения WAN1. Чтобы порт-форварды на WAN2 работали, нужно настраивать их как DNAT-правила в файле config.gateway.json. Кстати, проблема с soft failover связана с тем, что таблица маршрутизации ядра обновляется неправильно, и весь трафик от фаервола уходит через WAN1. Локальная сеть всё равно использует политику маршрутизации, и трафик LAN идёт через WAN2, но причина отсутствия доступа в интернет — скорее всего, в том, что DNS-запросы отправляются через WAN1. Чтобы это исправить, нужно в GUI прописать статический маршрут с сетью назначения (IP публичного DNS-сервера) и следующим хопом (шлюз WAN2). Кстати, с версией 4.3.46 и failover сейчас известны проблемы.

MarkCarragher

Guest

#13

03.08.2017 12:17:00

@UBNT-jaffe

Есть какие-то новости? Я столкнулся с этой проблемой прошлой ночью: наш основной WAN упал, но USG не переключился на резерв. Когда я пришёл в офис и вытащил кабель, исходящий интернет переключился на WAN2, но входящие переадресации не сработали. Получается, что переключение происходит только при отключении кабеля, а то, что входящие NAT-правила не переключаются, сводит на нет весь смысл двух WAN-роутера. Судя по тому, что я читал, проблема тянется уже больше года. Есть ли вообще какие-то новости, сроки решения, чтобы всё наконец работало как надо?

amjcf Guest	#14 22.07.2017 08:48:00 Есть ли прогресс по этой проблеме? У меня установлена самая последняя версия контроллера и прошивки USG, но проблема всё та же.

ACarneiro

Guest

#15

11.07.2017 07:04:00

Согласен, что реализация USG сейчас далека от идеала, но верю, что со временем всё медленно, но верно улучшится. 😀 Вместо того чтобы возвращать весь комплект, может, просто заменить USG на другой роутер, например Edgerouter? Кажется, у них есть балансировка нагрузки, и это сэкономит тебе замену остального оборудования. Я правда начинаю думать, что всю линейку USG надо срочно переделывать. Особенно железо кажется немного слабоватым.

mwahlert Guest	#16 11.07.2017 03:26:00 Есть новости по этому поводу? Спасибо.

SubyBurke

Guest

#17

08.07.2017 05:49:00

Я в такой же ситуации с тестовой реализацией UNIFI в Аризоне. Заказал кучу железа у UBIQUITI для этого UNIFI-контроллера и однооконного решения. Мой USG просто не переключается на резервный канал, а если и переключается, обратно уже не возвращается. И случилось худшее. Сейчас я в Париже, в этой тестовой реализации WAN1 упал, переключения на LTE с WAN2 не произошло, а теперь, когда WAN1 снова доступен, он просто не работает. Я уже отправляю техника перезагружать USG, чтобы всё запустилось, и мы смогли получить доступ к данным из Парижа по расположению в Аризоне. Не должно быть так сложно. Поддержка UBIQUITI не должна быть такой проблемой. Им бы стоило держать все под лучшим контролем. Я даже сказал им, что если не исправят ситуацию, мы вернем заказ оборудования на сумму 54 тысячи, но их это, похоже, не волнует. В общем, хватит ныть. Если за следующую неделю не решат проблему, у нас не останется выбора, кроме как вернуть всё и начать смотреть в сторону решения Meraki. Мне нужно что-то, что будет стабильно работать.

UI-Team Guest	#18 08.06.2017 21:22:00 Согласен, ребята, что мягкий фейловер не всегда срабатывает так, как хотелось бы, а вот жёсткий фейловер почти всегда работает безупречно. CMB в курсе, и это в списке того, что он сейчас изучает.

randomusername

Guest

#19

08.06.2017 13:04:00

Да, согласен, это действительно хороший продукт, и интеграция с Unifi очень классная. Но вот текущая реализация просто ужасна — определять настройки через json-файл — это катастрофа, да и некоторые функции просто не работают. У edgerouter, кстати, есть очень удобная функция «config tree», где можно включать и отключать довольно сложные вещи через относительно простой интерфейс, который потом сохраняется в конфиг. Им бы действительно стоило перенести это в unifi, а не заставлять людей вручную редактировать json!

amjcf Guest	#20 08.06.2017 12:58:00 Жаль, ведь в остальном это неплохой продукт. У меня открытое обращение в Ubiquiti по этому поводу, как только получу ответ — обязательно поделюсь. (если он вообще будет)

Читают тему (гостей: 1)