Хотспот и HTTPS? Какие есть решения?

Если сервер хотспота — это роутер Mikrotik, как это сделать? Нужно ли вручную добавлять дополнительные правила где-то? Правила хотспота создаются динамически в фильтре фаервола и NAT, поэтому эти правила нельзя опустить ниже. Можешь привести примеры, как правильно настроить это?

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

Это не меняет того факта, что другие устройства для хотспота справляются с этим гораздо лучше, чем MikroTik. У них, кажется, «просто работает» намного чаще. А у нас постоянно попадаются странные устройства, которые просто не хотят дружить с реализацией хотспота от MikroTik и не видят его. Как они это делают? Не знаю, но MikroTik либо должен улучшить свою систему, либо выкладывать в Wiki инструкции, как самому это исправить (то есть раскрыть механизмы, которые используют все устройства для определения систем с captive portal, чтобы мы могли вручную настроить редиректы и прочее). Мы говорим людям вручную заходить по IP-адресу роутера, но это не то, что они должны делать.

Есть какие-нибудь рекомендации по пакету, который можно поставить на недорогое или компактное устройство типа Raspberry Pi3/4? В конце концов, если я смогу поставить что-то, что «просто работает», я буду рад полностью отказаться от MikroTik для работы хотспота. Мне особо все равно, я просто хочу, чтобы оно работало и перестало вызывать жалобы от менеджеров отелей. Но при этом это должно быть что-то иерархическое и централизованно управляемое. Мы используем сторонний пакет с веб-интерфейсом, который ведет всю работу с хотспотом: учётные записи пользователей, изображения/HTML-страницы, а также даёт менеджерам отелей доступ для генерации ваучеров и прочего. Пока что эта функциональность перевешивает проблемы с обработкой хотспота на MikroTik, но я хочу повысить надежность, и кажется, что тут тупик, если только я не получу дополнительную помощь от MikroTik или кого-то, кто уже сам все решил.

Мой главный фокус здесь вовсе не в попытках перенаправить HTTPS, честно говоря, мне на это вообще наплевать. Настоящая проблема в том, что когда обнаружение хотспота тупит, пользователь не получает никакого уведомления или подсказки, что сначала надо “войти в сеть”, и обычно он просто открывает веб-браузер, который по умолчанию пытается зайти на HTTPS-сайт. В итоге соединение просто обрывается. Так что идея с HTTPS-редиректом — это всего лишь пластырь на настоящую проблему.

Повторюсь, мне совершенно не важен сам редирект, я хочу, чтобы система обнаружения captive portal/хотспота ПРОСТО РАБОТАЛА, чтобы такое не повторялось и пользователи ВСЕГДА получали уведомление о необходимости войти в сеть. MikroTik в этом плане — отстой. HTTPS-редирект — лишь временное решение проблемы кривого обнаружения хотспота.

Я видел, как в некоторых местах, когда вручную пытаешься зайти, скажем, на google.com, перехват действительно срабатывает — предлагается сначала войти в сеть, а соединение не рвётся, не возникает предупреждений о сертификате и не показывается, что интернета нет. Какая именно система там стояла — не знаю, и как это “на самом деле” работало (наверное, это не был HTTPS-редирект, а какая-то более аккуратная договорённость с устройством или браузером).

Если это невозможно, пусть так, мне всё равно, давайте лучше займёмся реальным решением проблемы. Либо вручную настроим правила в MikroTik, чтобы улучшить обнаружение хотспота, либо вообще откажемся от него и поставим что-то, что работает на маломощных устройствах, например на Raspberry Pi. Я за всё это, лишь бы появилась рабочая альтернатива. Мне нужен именно рабочий вариант.

Подожди немного… здесь должно быть так: убедись, что твоя точка доступа НЕ перехватывает эти запросы. Очень важно не обращаться с такими специальными сервисами обнаружения как с обычными! Ни в коем случае не подменяй IP в этих DNS-запросах, не перенаправляй их на локальные серверы, не помещай эти специальные сайты в закрытую зону и тому подобное! Такие запросы должны завершаться с ошибкой.

Когда это происходит, программа, которая за этим следит, понимает, что пользователь в сети без прямого доступа в интернет, и показывает ему специальную страницу с информацией о проблеме, позволяя перейти на страницу входа в твой хот-спот (попыткой загрузить фейковую http-страницу). После этого пользователь может вернуться на свою привычную https-страницу.

Любая попытка «помочь» этим запросам (например, пропускать их) сломает умный механизм и создаст проблемы для твоих пользователей!

Как уже много раз писалось выше, эту проблему решить нельзя! Однако разработчики таких программ, как Chrome и Android, знают об этом и используют запросы, которые вы сами не вводите (некоторые DNS и некоторые HTTP-запросы), чтобы определить такую ситуацию. Когда они обнаруживают, что вы подключены к сети с гостевой точкой/порталом, они дают пользователю возможность ввести данные для входа вместо того, чтобы просто открывать главную страницу сайта.