Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Unifi информирование и настройка через VPN-туннель, UniFi Network
 
Всем привет,  
У нас несколько устройств UniFi, которые отлично работают через наш WAN.  
Но у меня проблема с одним устройством UniFi, которое подключается через VPN-туннель Cisco между офисом в Сиднее и нашим центральным офисом в Крайстчерче.  
Похоже, что оно не может связаться с контроллером — хотя я знаю, что другие устройства в той же подсети могут пинговать и обращаться по HTTP к контроллеру UniFi.  

Логи такие:  
Jun 1 04:00:26 (none) user.debug syslog: uplink-monitor.update(): belief is eth  
Jun 1 04:00:26 (none) user.debug syslog: uplink-monitor.update(): uplink is eth0  
Jun 1 04:00:26 (none) user.debug syslog: libubnt.url_resolve(): url: unifi:8080/inform  
Jun 1 04:00:26 (none) user.debug syslog: libubnt.get_scanlist(): error during obtain scan_result  
Jun 1 04:00:26 (none) user.debug syslog: ace_reporter.reporter_inform(): connect(unifi:8080/inform) in progress...  
Jun 1 04:00:26 (none) user.debug syslog: ace_reporter.reporter_connected(): reporter connected to unifi:8080/inform  
Jun 1 04:00:26 (none) user.debug syslog: ace_reporter.reporter_send(): request sent, waiting for response  
Jun 1 04:00:34 (none) user.debug syslog: mca-client.service(): Sending request to '/tmp/.mcad'  
Jun 1 04:00:34 (none) user.debug syslog: mcad-ctrl.cl_read(): received packet of 22 bytes from '/tmp/.mca-yV4K5J' (fromlen: 19)  
Jun 1 04:00:34 (none) user.debug syslog: mcad-ctrl.cl_read(): Processing status request...  
Jun 1 04:00:34 (none) user.debug syslog: mcad-ctrl.cl_read(): sending back the response (type: 0)...  
Jun 1 04:00:34 (none) user.debug syslog: mca-client.service(): Waiting for response...  
Jun 1 04:00:35 (none) user.debug syslog: infctld.fill_response_data(): version=2.2.5.1080  
Jun 1 04:00:35 (none) user.debug syslog: infctld.mcast_beacon(): send_beacon(): src=00:27:22:50:d6:eb, seq=87, len=147  
Jun 1 04:00:41 (none) user.debug syslog: uplink-monitor.update(): prev observation is eth, seq 54  
Jun 1 04:00:41 (none) user.debug syslog: ace_reporter.reporter_timedout(): read(unifi:8080/inform) has timed out  
Jun 1 04:00:41 (none) user.err syslog: ace_reporter.reporter_fail(): server unreachable  
Jun 1 04:00:41 (none) user.err syslog: ace_reporter.reporter_fail(): initial contact failed #51, url=http://unifi:8080/inform, rc=3  
Jun 1 04:00:41 (none) user.info syslog: ace_reporter.reporter_next_inform_url(): next inform url=http://unifi:8080/inform  

На случай, если проблема с разрешением DNS (хотя я в это сомневаюсь), я попросил нашего консультанта добавить в DHCP опцию 43 (IP контроллера 172.16.32.77). Остальные DHCP опции настроены для IP-телефонов (и они работают).  

Если кто-то может проверить, правильно ли отформатирована опция 43, было бы здорово.  

ip dhcp pool dhcp_pool  
import all  
network 172.17.80.0 255.255.255.0  
domain-name elastomer.co.nz  
default-router 172.17.80.254  
dns-server 172.16.32.2 61.9.192.14  
option 43 hex 0104.ac10.204d  
option 66 ascii 172.16.33.1  
option 150 ip 172.16.33.1  
option 160 ascii tftp://172.16.33.1/polycom/  

Пытался менять URL для информирования, но после каждого опроса он возвращается обратно.  

VPN-туннель проброшен между двумя маршрутизаторами Cisco серии 800. Весь TCP/UDP трафик маршрутизируется между двумя подсетями (никаких блокировок протоколов нет).  

Точка доступа, о которой речь, — UniFi AP  
Модель: BZ2  
Версия: 2.2.5.1080  
MAC-адрес: 00:27:22:50:d6:eb  
IP-адрес: 172.17.80.23  
Время работы: 385 секунд  

Данное устройство до отправки в Сидней работало у нас в WAN без проблем.  

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

Спасибо заранее!  
Кайл
 
У меня была такая же проблема: одновременно пропали три точки доступа на одном объекте. Иронично, что это случилось именно тогда, когда наши внутренние основные каналы упали, и мы переключились на GRE поверх IPSEC, где уменьшен MTU. Я уверен, что наши маршрутизаторы (и VPN, которые между ними) настроены правильно, но, по моему мнению, точки доступа с версией 3.4.18.3464 или контроллер с версией 4.8.18 не учитывают PMTU, который возвращают маршрутизаторы Cisco.

Через несколько секунд после того, как я выполнил эту команду на точках доступа, они снова заработали:

ifconfig eth0 mtu 1400
 
Если при снижении MTU на устройстве всё работает, значит ваша проблема — в настройках VPN или интернет-соединения, прямо и просто. Я бы предположил, что дело именно в настройках VPN.
 
Открой порт 8080 на своем WAN и забудь об этом.
 
Да, мы используем маршрутизаторы Cisco. Я никогда не смотрел в сторону маршрутизаторов ubnt. Думаю, если у вас вся сеть построена на продуктах Ubiquity и что-то не работает, то поддержка Ubiquity должна помочь. Может, стоит попробовать?
 
@wilsonwaters

Я уже проверил VPN-соединение, и всё настроено согласно лучшим рекомендациям UBNT. Я использую ERL на удалённых узлах и ER-PRO в центральной точке. Похоже, это ошибка проектирования в протоколе связи Unifi. Несколько других тоже сталкиваются с такой же проблемой при использовании GRE-IPSEC VPN-тоннеля для связи с точками доступа.

Ты говорил, что изменял конфиг, чтобы сбросить бит DF. Ты делал это на ERL или Cisco? Я знаю, как это сделать на Cisco, но пока не нашёл способа для ERL. Мы также пробовали MSS-Clamping, но безрезультатно.

— Eli
 
Мой совет — проверить конфигурацию вашего VPN-роутера. В нашем случае фрагментация пакетов через VPN вызывала проблемы не только с некоторыми другими сервисами, но и с устройствами Unifi. В итоге я изменил настройки VPN так, чтобы пакеты тихо фрагментировались/переформировывались даже при установленном флаге DF.
 
Есть какие-то сдвиги по этому вопросу? У меня по-прежнему проблемы — пакеты оповещений как будто не работают нормально через GRE-IPSEC туннель. (Использую ERL 1.6) Если зайти в каждый UAP и выполнить: ifconfig br0 mtu 1200, то проблема вроде исчезает. Но как только точка доступа перезагружается, mtu сбрасывается. У кого-то ещё такое есть? Включить уведомления не могу, потому что постоянно получаю сообщения о временных отключениях.
 
У меня такая же проблема. Есть какие-нибудь новости по этому поводу? Я оставил подробности здесь.
 
У меня похожая проблема: uap то подключаются, то отключаются, и во время информирования выдают тайм-ауты, хотя туннель при этом остаётся активным и работает. Раньше я уже создавал тему по этому вопросу, пока не нашёл эту. Надеюсь, вместе сможем разобраться… https://community.ui.com/questions/2b3bf5be-c4b4-4ff4-94fe-10a514f65ae4
 
Да, конечно. Я не пробовал менять MTU на стороне сервера, но заметил, что это срабатывает, если изменить MTU на стороне устройства. Вероятно, это проще, чем лезть в настройки роутера. Всё равно мне это говорит о том, что бит DF где-то устанавливается (возможно, даже по какой-то уважительной причине).
 
Мне пришлось значительно уменьшить размер MTU на стороне сервера Unifi, чтобы пакеты проходили без фрагментации.
 
Для тех, кто запускает unifi inform через Cisco ipsec VPN, я обнаружил, что единственный способ заставить это работать — сбросить бит «не фрагментировать» в туннеле VPN (на обеих концах): crypto ipsec df-bit clear. По мне, это означает, что устройства ubnt действительно устанавливают бит «не фрагментировать», вопреки тому, что говорит @UBNT-MikeD.
 
Звучит отлично. С наилучшими пожеланиями, Майк
 
Я загружу свой файл захвата пакета в заявку в службу поддержки.
 
Контроллер не устанавливает бит «не фрагментировать» на уровне приложения. Похоже, что ваша VPN (или связанные с ней настройки) настроена неправильно.  
С наилучшими пожеланиями, Майк
 
что-нибудь?
 
Есть хоть какой-то ответ?
 
Бьюллер... Бьюллер...
 
Есть какие-нибудь новости по этому поводу?
Страницы: 1 2 След.
Читают тему (гостей: 1)