Похоже, у меня сработало. Огромное спасибо! Уже начал сходить с ума.

@jocke

Я очень надеялся, что твое решение сработает у меня, но пара AP, которые я обновил до v3.9.18.8086, всё равно показывают ошибку STUN communication failure. Я запускал tcpdump -i i/f port 3478 на самом AP, на роутере AP, на USG и на Ubuntu UniFi контроллере, а также nc -v -u host 3478 на клиентах — и во всех случаях STUN-пакеты корректно передаются или доходят до адресата. Как я уже говорил, у меня нет этой проблемы на сайтах, где мониторинг идёт через CloudKey, и на одном сайте с точно такой же установкой Ubuntu/UniFi контроллера v5.6.26, но все его AP подключены по LAN. Загадка. Впервые я столкнулся с этим на более старой версии контроллера, и тогда проблему решало включение форвардинга порта UDP3478, что исправляло все AP с ошибками — до тех пор, пока я не обновился до v5.6.26. Поскольку сейчас это ничему не мешает, я сказал нашим администраторам просто не обращать внимания на эту проблему.

Пожалуйста, предоставьте текст для перевода.

Это происходит и со мной. Вот факты:

- До обновления весь STUN работал нормально.
- Настройки FW не менялись.
- UniFi Controller не обновляли и конфигурацию не трогали.
- UniFi Controller версии 5.6.27 на Debian (без CloudKey).
- Обновили AP, коммутаторы и USG.
- AP (Lite + Pro) обновились с версии «3.9.3.7537» до «3.9.15.8011».
- Коммутаторы (US8) обновились с версии «3.9.6.7613» до «3.9.15.8011».

После обновления STUN не работает (значок треугольника), при этом:

- USG работают нормально.
- Коммутаторы работают нормально.
- Все AP (кроме одного) не работают.
- На одном из объектов с AP нет USG, но STUN всё равно не работает.
- IPv6 не при делах (на всех объектах его нет).
- STUN открыт и отвечает (все устройства, кроме AP, работают нормально).

Понизил версию одного из AP с проблемой STUN (до старой версии, ее можно скачать здесь: https://community.ui.com/releases/02a4de42-4231-4189-adcc-39566b534e4d). AP перезагрузился, и проблема с треугольником пропала. Больше никаких изменений не делал. AP с версией 3.9.15.8011 по-прежнему не работают.

@elcid89

Я не собираюсь выкладывать дамп здесь, но поймаю пакеты с обеих сторон и посмотрю их в shark, чтобы попытаться что-то понять. Когда у меня будет эта информация и если я найду что-то важное, выложу здесь или отправлю тебе файл в личку. В любом случае, это был мой следующий шаг, потому что я подозреваю, что что-то в настройках нашего контроллера заставляет устройства (старые и новые) либо неправильно отправлять stun-запрос, либо они даже получают ответ, но не подтверждают его. Было бы здорово, если бы Ubiquiti сами попросили об этом — я бы с удовольствием поделился всем, включая доступ к сети.

Полностью согласен с Tenenbaum. Мы оба прошли очень простое тестирование, чтобы убедиться, что STUN-сервис на контроллере доступен и отвечает корректно. Elcid, если ты считаешь, что я каким-то образом напортачил с открытием UDP-порта 3478 в инфраструктуре моего контроллера, не стесняйся проверить это сам. STUN будет доступен по адресу stun://unifi.aventinemills.com — попробуй протестировать его с помощью STUN-клиента. Попробуй, а потом возвращайся и рассказывай, что я напортачил, а заодно объясни, почему. Как ты и говоришь, STUN — очень простой протокол, и я особо ничего не могу сделать, кроме как убедиться, что порт открыт и доступен с любого устройства. К тому же многие мои объекты с треугольником предупреждения вообще не имеют USG, так что это явно не корень проблемы. У меня есть несколько объектов с USG, и там треугольник тоже появляется.

@elcid89

Я понимаю, что здесь нужно быть максимально точным, чтобы довести дело до разрешения. Но раз за разом, по крайней мере в моём случае, я предоставлял очень конкретные сетевые тесты и проходил все шаги по устранению неполадок, а треугольники всё равно появляются. Что ещё мы можем сделать кроме как запустить stun-скрипт на самих устройствах, которые показывают треугольник, и получить чёткие ответы от stun-сервера (контроллера)? Это своего рода стопроцентное доказательство того, что в нашем случае это не проблема сети, не брандмауэр и не NAT, не проблема с доменом — ничего из этого. Просто вдруг тысячи точек доступа, ни одна из которых не была исключением, после обновления начали показывать треугольник, и при этом никто не предлагает решение.

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

1. Те, у кого была эта проблема, но её решил сетевой апдейт или повторное подключение.
2. Те, у кого эта проблема, но, скорее всего, всё ещё есть сетевая проблема.
3. Те, у кого есть эта проблема, и они точно проверили, что проблема не в сети с их стороны.

С таким взглядом,  
Офер

Что вы ожидали? Вы не проявляете никакого интереса к выявлению причины своей проблемы, кроме как уверенности в том, что вы никак не могли её вызвать, и во всём виноват кто-то другой. При этом вы отвечаете с высокомерием, когда вам пытаются помочь, и, насколько я понимаю, отказываетесь даже рассматривать, что причина может (читай — обязательно лежит) в вашей сетевой структуре.

К слову, я последовательно устанавливал абсолютно все версии прошивок и контроллеров — стабильные и тестовые — начиная задолго до появления этого предупреждения в коде, и ни разу, ни единого раза не видел ошибки STUN. Ни «были на короткое время, потом исчезли», ни «у одних устройств есть, у других нет». Просто «у меня никогда этой проблемы не было, независимо от версии кода. Точка. На этом всё».

Отсюда остаётся два варианта — либо я каким-то образом пользуюсь волшебным кодом, отличающимся от вашего, либо наши сети устроены по-разному, и именно ваша создаёт проблемы с STUN-коммуникацией (а она, между прочим, очень и очень простая), а моя — нет.

Какой из этих вариантов, по-вашему, более вероятен?

Странная реакция. Не забудь дверь за собой захлопнуть!