@UBNT-Cody

> По мере того, как браузеры становятся современнее, они внедряют свои способы реагирования на наличие captive portal, но на стороне AP у нас нет возможности как-то управлять их реакцией. < Это определённо НЕ так. Если вы добавляете определённые домены в «walled garden» на AP (пропуск независимо от того, вошёл пользователь или нет), браузеры ведут себя по-разному. Например, браузер Apple проверяет множество разных доменов, доступны они или нет, отправляя маленькие http-тесты. Если приходит ожидаемый ответ, всплывающих окон нет. Microsoft и Android делают подобное. Но эти домены/IP часто меняются, по крайней мере у Apple. Поэтому, когда вы используете «walled garden» (многие порталы обязаны так делать, чтобы, например, работал «Social Login»), может возникнуть разница в наборах «walled garden domains» между версиями контроллера, из-за чего одно и то же устройство или браузер ведут себя по-разному.

Привет, ubnt-Cody, спасибо за ответ и извиняюсь за задержку, был за границей пару дней. Думаю, наш конфиг портала сейчас не актуален, потому что мы закупили 90 точек доступа (AC), а используем пока только 86. Я взял одну домой и с нуля поставил контроллер (тоже на Ubuntu, как и на работе).

Сначала установил 3.1.13 с дефолтным порталом (не нашим модифицированным) — всё прошло отлично, никаких проблем, портал появляется за секунду, и не важно, первая страница http или https (как говорил, использовал стандартный портал из прошивки). Проверял на Windows 7, 8, Apple и Android устройствах.

Потом сделал чистую установку 4.6.6 на другом ПК (тоже на Ubuntu), точно такую же, как и на предыдущей с 3.1.13 (дефолтный портал, не наш), и вообще не мог получить портал, проверял на тех же устройствах — просто таймаут примерно через минуту.

Работает только если первая страница — не https://, а http://. Если изменить “config.redirect_https = true”, то работает, но с предупреждением о сертификате, что для нас не подходит, так как у нас реально много пользователей (часто свыше 1000 в день).

Большое спасибо!

Дорогой Ubnt-CODY, большое спасибо за всю вашу поддержку и помощь, я это очень-очень ценю. Поверьте, у нас нет никаких проблем или предупреждений о сертификате с версией 3.1.13 (на Linux/Ubuntu в качестве контроллера), которую я использую с самого начала проекта. У нас в выходные была конференция, где ежедневно было более 1200 подключенных клиентов, и ни одной проблемы. Я тестировал это на 3 операционных системах (Windows 7, 8, 8.1, 10 и Apple OS) — никаких проблем вообще.

Я подключил всего одну точку доступа AC в другом здании к контроллеру 4.6.6 (тоже Ubuntu) и получил те же проблемы, что и у меня в нашем здании с 4.6.6 (крутится круг, пока не истечёт время ожидания, потом появляется сообщение «страница не может быть отображена»), если только первая страница не HTTPS — в этом случае всё работает нормально. Если я следую вашим рекомендациям по HTTPS, то всегда получаю предупреждение о сертификате, что неудобно в нашей среде.

Как уже говорилось, с версией 3.1.13 ни у одного из наших «тысяч» клиентов нет никаких проблем с любой ОС (Windows, Android и прочие).

Я не единственный с этой проблемой, посмотрите, пожалуйста, ссылки ниже:  
https://community.ui.com/questions/182bcf2a-907b-4877-9686-6317e81be25a  
https://community.ui.com/questions/d8f152a4-8202-4861-a2a5-e67047f2b3d7#answer/d767a235-7516-4961-98b3-c626dad2b73e

Спасибо, UBNT-CODY. Мы не пробовали версию 3.2.7, так как 3.1.13 работает прекрасно. Мы тестировали 4.6.6, где есть проблема с порталом. Я бы проверил 3.2.7, но не могу рисковать в рабочей среде, ведь если что-то пойдет не так, сотни, а то и тысячи клиентов просто не смогут залогиниться.

Дело в том, что нам нужно обновиться до версии 4.x.x.x, поскольку мы планируем покупать коммутаторы и/или шлюзы Unifi (чтобы иметь возможность заставить проводных клиентов проходить через портал). Проект пока отложен, потому что мы не можем рисковать и тратить еще «тысячи» на новое оборудование Unifi, если оно потом не будет работать как надо.

Еще раз спасибо!