Captive apple com что это

captive.apple.com на Android-смартфонах

Есть два аппарата на Android(Fly и Philips). Но суть не в этом, а в том, что у МТС, когда была МТС-коннект симка выходила в интернет, то если деньги заканчивались, то никаких проблем не было. Инет отключался и приходила смс-ка о том, что денег нет и услуги связи ограничены.
Перешёл на МОй безлимитище с интернетом и, когда заканчиваются деньги, то теряется «Регистрация в сети». Отмечу, что по 4G-подключается интернет. То же самое стало появляться, когда на тариф «Новый Супер МТС» добавили трафик и по окончании денег, выскакивает та же херня с «Нет регистрации в сети», при том, что ussd-смски работают и баланс показывает.
Сегодня закончились деньги, выскочила эта ерунда, потом положил и тут же нажимаю на эту регистрацию и выходит строка «https://captive.apple.com/тратата.чегототам» success.
Кто, что соединился, с чем? Гугление меня вывело только на WiFi и на iPhone. Инет по 4G.

xwicked ★★☆
25.08.18 12:41:24 MSK

Поменяй тариф на «Тарифище»

tiinn ★★★★★
( 27.08.18 11:05:47 MSK )

Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.

Похожие темы

• Форум Выбор Android-смартфона (2013)
• Форум Криптофон на Android смартфоне (2014)
• Форум Выбор не-android смартфона (2012)
• Форум Чем прошивать Android-based смартфон. (2015)
• Форум Как установить Android на смартфон? (2013)

• Форум Ваш рейтинг производителей Android-смартфонов (2013)
• Форум Android смартфон в качестве джойстика (2020)
• Новости Третий Android-смартфон от Motorola (2010)
• Форум Недорогой смартфон с чистым Android`ом (2023)
• Форум Посоветуйте Android-смартфон с QWERTY клавой (2014)

Captive apple com как отключить

Узнайте, как использовать пленного по Wi-Fi сети, которые общедоступных сетей, на которые вы подписались или оплатить.

В плену сетей являются так называемые «подписки» или «точка доступа WiFi» сетей. Вы можете найти эти сети в кофейни, интернет-кафе, гостиницах, аэропортах и других общественных местах. В некоторых странах и регионах, беспроводной связи спонсора и удержать в плену сетей.

Вступайте в плен к Wi-Fi сети

Присоединяйтесь к плененной, как Wi-Fi сети:

1. Коснитесь Настройки > Wi-Fi Интернет.
2. Нажмите на имя сети, затем дождитесь экрана входа в систему появится. Или нажмите рядом с Имя сети, затем нажмите Присоединиться к сети.
3. Если потребуется, введите имя пользователя и Пароль, ввести адрес электронной почты, или признаете условия.

После того как вы войти, вы должны быть в состоянии получить доступ к интернету. Сборов и других платежей могут применяться, когда вы используете в плен к Wi-Fi сетям. Обратитесь к оператору сотовой сети для получения дополнительной информации.

Если вы отмените до входа в сеть

Когда вы нажмете «отмена» на экране входа в систему, можно отключить устройство от пленника и Wi-Fi сети.

Если вы подключились к сети с Wi-Fi экран, нажав на кнопку, появляется сообщение, что сеть не подключена к интернету. Вы можете выбрать один из следующих вариантов:

• Без интернета закрывает экран приветствия и выключение автоматического входа в сеть. Он держит устройство, связанное с сетью и позволяет использовать сеть другими способами.
• Другие сети закрывает экран приветствия и отключение устройства от сети. Он возвращает вас к Wi-Fi экран настроек, где можно выбрать другую сеть.
• «Отмена» возвращает вас на экран приветствия.

Автоматическое подключение к Wi-Fi сетям

Вашем iPhone, iPad и iPod Touch может запомнить сеть и логин, так что вы можете автоматически подключиться к этой сети, когда вы находитесь в диапазоне.

Если ваше устройство не автоматически включаются в плену беспроводной сети, выполните следующие действия:

1. Коснитесь Настройки > Wi-Fi Интернет.
2. Нажмите рядом с названием сети.
3. Убедитесь, что авто-вход на.

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

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

Распределённый Captive Portal в публичных местах и сложности с Apple

Почитав про метро, хотел было комментировать, но решил написать отдельно.

Мы участвовали в создании публичных сетей с распределёнными captive portal и наступали практически на все грабли, поэтому хочу поделиться опытом.

Для начала — немного теории о том, как это работает и чем распределённые порталы отличаются от централизованных. Идеологически то, что мы привыкли называть Captive Portal, на самом деле состоит из трёх компонентов:

web frontend — предназначен для взаимодействия с пользователем, сбора информации методом заполнения форм и показа ему рекламы. Если мы собираемся просить пользователя вводить личную информацию и пароли, то следует использовать https, соответственно, на сервер нужен нормальный сертификат. Если собираемся просить поставить галочку под соглашением пользователя, то достаточно http.

собственно captive portal — это некий агент, призванный получать информацию, собранную с помощью web frontend, анализировать её, возможно делать от своего имени уточняющие запросы (например, в RADIUS) и по результатам сообщать о своём решении либо непосредственно пользователю, либо ему же посредством web frontend. В случае положительного решения captvie portal приоткрывает для данного пользователя необходимые отверстия в firewall. По истечении заданного промежутка времени отверстия закрываются и мы имеем пользователя обратно в web frontend. Досрочно портал закрывается по неактивности пользователя. Зачастую единственной причиной ограничения времени сессии является желание снова показать пользователю рекламу (если мы не хотим выступать как в метро, уродуя дизайн других сайтов)

firewall — ведает доступом отдельных пользователей в сеть. В случае отсутствия доступа по идейным соображениям — выполняет перенаправление пользователя в web frontend. В случае отсутствия доступа по техническим причинам (не пингуется gateway) можно поручить firewall выполнять перенаправление пользователя на специальную страничку «сервиса нет, но мы чиним изо всех сил».

• Проблемы с безопасностью. Мы ограничиваем доступ к внешнему каналу, однако в локальной сети всё плохо. Поскольку сеть открытая, любой пользователь может отвечать на arp от имени нашего default gateway, получать трафик пользователей и заниматься фишингом. Не возбраняется поставить свой сервер DHCP и в некой дельта-окрестности стремать пользователей заявлениями типа «ваш браузер безнадёжно устарел». Если ваш captive portal и пользователя разделяет роутер, то у вас нет возможности контролировать на captive portal соответствие mac и ip со всеми вытекающими. Коммуникация между беспроводными клиентами становится возможной. Вы можете на дешёвой точке запретить коммуницировать беспроводным клиентам, но клиенты других точек видны уже по ethernet.
• Проблемы с трафиком. Имеем в локальной сети много лишнего трафика. Желательно до открытия captive portal клиентов дальше точки доступа не пускать.
• Проблемы с масштабируемостью. При большом числе клиентов проблемным может стать любой из трёх компонентов портала.

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

Firewall должен находиться максимально близко к клиенту, т.е. однозначно в точке доступа. Поскольку точек доступа несколько и в каждой из них — свой firewall, то их работа должна быть синхронизирована в рамках некоторого пространства или местности, в пределах которой предполагается роуминг клиентов. В противном случае клиенты при роуминге будут испытывать проблемы с коммуникацией. В современных сетях задача синхронизации работы чего-либо внутри некой области (RF-домена) выполняется с помощью назначаемых арбитров (менеджеров RF-домена) и была решена в стародавние времена безотносительно к задаче реализации распределённого captive portal. Для этой системы синхронизация работы firewall — просто ещё один из процессов, который должен выполняться в домене согласованно, наряду (например) с коммутацией трафика, синхронизацией конфигураций точек или сбором статистики.

Место расположения web frontend сильно зависит от сложности задач, которые ему предстоит решать. Если надо показывать странички, не предполагающие server side processing или каких-то сложностей типа рассылки СМС, то вполне можно обойтись сервером на точке доступа. Он, опять же, располагается максимально близко к клиенту и обеспечивает наиболее эффективное с ним взаимодействие. Синхронизацией контента веб серверов на разных точках доступа займётся (сюрприз) менеджер RF-домена.

Место расположения captive portal зависит от положения web frontend и доступности точек. Поскольку задачей captive portal является подкручивание firewall, то он должен иметь своё представительство (агента) на каждой точке. Тем не менее, web frontend может коммуницировать с любой из копий этих агентов, ибо их состояние (вы уже догадались) также синхронизируется в рамках домена.

Таким образом, мы добиваемся ситуации, при которой для клиента, успешно прошедшего авторизацию, captive portal открывается сразу во всём домене и после этого в любой момент на всех точках доступа домена firewall для этого клиента настроен одинаково.

Тонкости

• Портал открывается всегда. Возможно занести запись об этом в log.
• Портал открывается при наличии в GET переменной, отражающей согласие с условиями (agreement).
• В GET передаются username и password, портал сам лезет в RADIUS с этими атрибутами и открывается, получив оттуда ACCEPT.
• В GET передаётся один (универсальный) атрибут, портал указывает его и как username и как password при обращении в RADIUS и открывается, получив ACCEPT. Понятно, что такой пользователь должен быть в RADIUS

Как портал, получив GET, разбирается о каком пользователе идёт речь? При переадресации пользователя в web frontend портал приделывает к вызову довольно длинную переменную, которую мы должны вернуть ему в неприкосновенности среди параметров запроса на открытие портала.

В идеале, точка выполняет бриджинг (форвардинг 2-го уровня) между SSID и неким vlan в проводах. То есть firewall работает на втором (MAC) уровне. Поскольку firewall видит прилетевший из недр вашей сети DHCP offer клиенту, он точно знает его IP, сам отвечает вместо клиента на ARP и жёстко фильтрует весь ARP и DHCP на беспроводном сегменте.

Отсутствие у точки IP-адреса в пользовательском vlan исключает возможность коммуникации пользователя непосредственно с точкой. Однако, иногда нам такая возможность необходима — при расположении web и портала прям на точке. В этом случае используется фиктивный адрес 1.1.1.1

При чём тут Apple

И почему мы везде, как и в метро, убеждаем айфончеги, что портала нет.

По тому, как айфончики ведут себя в беспроводных сетях, у меня сложилось стойкое убеждение, что создатели этого мегапродукта предполагали только один сценарий, а именно — одна точка доступа. То есть либо дома, либо в кафе для хипстеров. Во втором случае есть неиллюзорный шанс встретиться с captive portal.

Что предпринимает айфончик, встретив несколько точек с одним SSID и captive portal? Он пробует все доступные. На каждой он подключается, просит адрес, проверяет рандомный url из своего длинного списка (раньше он был один), понимает, что тут captive, отдаёт адрес (dhcp release) и отключается. Поскольку в нашем случае один SSID светит с каждой точки и в 2.4 и в 5GHz, всё умножается на два. Придя к логичному заключению «да тут везде засада!», айфончик снова подключается к одной из точек и рисует свой минибраузер. В терминологии наших заказчиков и клиентов этот процесс называется «Мой последний айфон очень долго подключается к вашей сети» и «у меня дома всё летает на точке за 1000 р.» В случае скоординированной сети (не отдельных точек) при каждом подключении точка посылает сообщение менеджеру домена «у нас новый пассажир», а в случае MESH — параллельно ещё и туда. Весь процесс занимает до 20 секунд.

Что предпринимает айфончик, встретив одинаковый SSID сразу в 2.4 и в 5GHz? Вы думали, что сможете балансировать клиентов между каналами, точками и диапазонами, максимально используя возможности клиентов и пропускание сети? Только не с продуктами Apple! Со стороны сети, слыша от клиента запросы в обоих диапазонах, мы вправе предполагать, что сможем вынудить клиента подключиться куда нам надо, пропуская запросы к тем точкам, куда мы не хотим, чтобы он подключался. Обычно клиенты понимают намёк и подключаются, например, в 5Ghz. Айфон будет ломиться в 2.4 до последнего. Для упорных есть отдельный счётчик (20 запросов подряд по умолчанию). Тоже занимает время.

Два описанных процесса происходят не только при подключении к сети, но и при роуминге, если отойти достаточно далеко. О, да здесь новые точки. Ну-ка, проверим…

Что предпринимает айфончик, если он запустил минибраузер и нам (вдруг) надо прислать клиенту СМС? Он показывает смс в маленьком окошке сверху с временем экспозиции порядка 3 секунд. Блондинка не в состоянии за это время запомнить 6 (шесть!) цифр. Окошко уезжает, пользователь тычет пальчиком в смс, минибраузер закрывается, dhcp release, disconnect, welcome to 3G. Пользователь с горем пополам запоминает код, лезет в settings, подключается к сети, введите номер телефона, получите новый смс. И далее, и далее… В терминологии заказчиков и пользователей это называется «на моём последнем айфоне не работает ваш каптив портал» и «даже в метро уже починили».
Ситуацию можно поправить, пересылая в web frontend MAC пользователя (мы умеем), запоминать там, что мы ему уже посылали смс и при втором заходе спрашивать уже код. Ибо куки этот минибраузер не поддерживает.

В чём причина такого малоадекватного поведения? Всё просто: создатели прибора ставили целью не оставить вас без связи.

1. Не можем получить IP — отключаемся
2. Не видим ARP с default gateway — отключаемся
3. Не отвечает ни один DNS из списка — отключаемся
4. Запрашиваем некий url с одного из своих доменов — надеемся увидеть

Success

Единственная возможность прекратить метания — выполнить обход обнаружения портала. Возможно осуществить двумя способами — фильтрацией «User-Agent: CaptiveNetworkSupport» или пропускать трафик по некоторому списку доменов. В метро, например, работает iMessage при закрытом портале.

В результате обхода портала сеть видно либо никак либо не всю. В любом случае, это — очень плохо, потому что, фактически оставляет пользователя без связи незаметным для него образом.

На нашем оборудовании обнаружение выключается одной командой:

ap7131-ABCDEF(config-captive-portal-XXXXX)#bypass ? captive-portal-detection Captive portal detection requests(e.g., Apple Captive Network Assistant ap7131-ABCDEF(config-captive-portal-XXXXX)#bypass captive-portal-detection 

Шо, опять?

В работе с гостевыми Wi-Fi сетями столкнулся с неприятной проблемой. Много устройств Apple iPhone и iPad отключается от Wi-Fi при затухании экрана (блокировка) и, при отсутствии мобильного интернета, сообщения из мессенджеров не приходят и гости эмоционально реагировали: «не в АйФоне же дело!? Дома всё в порядке на домашнем роутере!»

Дело почти дошло до «замены шлюза с встроенным контроллером точек доступа», управляющего десятками точек доступа, но ведь у Андроидов и Windows-устройств всё в порядке было.

В статье излагаются результаты проведенных исследований, перечисляются все танцы с бубном и перепробованные способы устранения проблемы. Печально, но решение, устроившее бы всех, так и не было найдено. Может быть после прочтения кому-то придет в голову что можно сделать. А тому, кто изложит в комментариях реальный фикс, который решит проблему на моём оборудовании, будет подарок: функциональный и стильный рюкзак от Zyxel.

Мои предыдущие статьи (спойлер).

В конце текста информация обо мне.

Итак, если разблокировать экран, телефон снова ищет Wi-Fi точку доступа и подключается к ней, если стояла галочка «Автоподключение», которая по дефолту не стоит при первом подключении к Wi-Fi. Необходимо вручную активировать её.

При повторной блокировке экрана аналогично АйФон отключается от Wi-Fi и снова к нему подключается при разблокировке и так было у всех и постоянно. Очень раздражало всех, и меня как сетевика, и гостей, что Wi-Fi «хреново» работает на их суперском АйФоне. У меня самого iPhone, когда интернет заканчивался на симке по тарифу, при отключении от Wi-Fi сообщения в мессенджерах не приходили.

Не оставлять же телефон с постоянно включённым экраном? Поиск в интернете предложил много сайтов и видеороликов. Рекомендации в основном были такие:

• «Помощь Wi-Fi» отключить;
• эксперименты с настройками GPS, конфиденциальностью;
• эксперимент с временами аренды DHCP.

Это не помогло. Ещё были рекомендации, которые совпали с рекомендациями техподдержки Apple после официального обращения к ним:

• жёсткая перезагрузка (кнопки ДОМОЙ+ВКЛ/ВЫКЛ или др. комбинации);
• обновление ПО шлюза (роутера);
• сброс шлюза и с повторной настройкой с нуля;
• «Сбросить настройки сети» на телефоне.

Перечисленные рекомендации, не помогли, кроме последней. Она помогла на пару дней, потом проблема снова повторялась. Далее были ещё рекомендации:

• обновление версии iOS до актуальной;

Обновление iOS реально помогло, но потом редко у некоторых проблема стала повторяться. Хозяин телефона «Сбросить настройки сети» отказывался и такое всем не предложишь.

Самое удивительное было то, что когда выходит новая версия iOS, нынешняя исправная версия начинает отваливаться от Wi-Fi. Раньше же нормально работало на этой же версии! Получается, что как версия iOS устаревает, телефон будет отваливаться от Wi-Fi.

Как быть тогда с пенсионерами Apple 5s; 6 у которых последняя версия iOS 12.5.5? Эти модели тоже отваливались от Wi-Fi.

Следующая рекомендация такая была:

• замените! шлюз или точку доступа.

Звучит как приговор. Домашний роутер ладно, там одна железка за 3 тыс.рублей и поменяться с кем-нибудь на время можно.

Как быть с шлюзом с аппаратным контроллером, который заведует десятками точек доступа? В этот комплекс столько денег, нервных клеток, переговоров с интеграторами, времени было вложено. Один только шлюз стоит 100 тыс.рублей, а если Cisco за 1 млн рублей был бы? Ну да, конечно, денег молча дали, заказал шлюз, привезли, поменял, ага, размечтались. 128 штук точек доступа тоже нужно поменять? Большинство на потолках, высотой 3-9 м, со стремянки не достанешь.

И руководству что говорить? Что в проекте ошиблись вендором, нужно его поменять на другого вендора ради телефонов Apple?

Поэтому вариант смены шлюза и точек доступа был неприемлемым, но давайте проверим детально, а верна ли эта рекомендация? Может поможет или АйФоны опять будут отваливаться?

Поэтому пришлось собрать АйФоны моделей iPhone 4s (iOS 9.3.5), 5s (iOS 12), 6 (iOS 10) и 7 (iOS 11 и 13), звал коллег из других подразделений потестить их АйФоны, вкусняшки покупал в знак благодарности. Всё это тестировал на свободном резервном шлюзе Zyxel UAG5100 с управляемой точкой доступа Zyxel NWA5121-NI, сброшенные в дефолтное состояние, настраивал шлюз небольшими шагами с обязательной проверкой поведения АйФонов, после какой настройки начнут отваливаться АйФоны от Wi-Fi.

Таблица 1 — Поиск причины отключения АйФона от Wi-Fi.

№ шага

Внесённая настройка

iPhone 4s (iOS 9.3.5), 5s (iOS 12), 6 (iOS 10) и 7 (iOS 11 и 13) и другие отключились от Wi-Fi?

WAN порт, DHCP в LAN подсети и SSID “Test”

Время аренды DHCP

Радиоканалы, мощность, балансировка SSID

Привязка IP/MAC, изоляция L2

BWM; ограничение скоростей в SSID; Intra-BSS

Включение Captive Portal (портал авторизации)

ДА, после ввода ваучера

Выключение Captive Portal (портал авторизации)

Включение Captive Portal (портал авторизации)

ДА, после ввода ваучера

Внесение MAC-адресов АйФонов в белый список, чтобы не запрашивать у них авторизацию

Значит после пройденной авторизации через Captive Portal (могут называться как портал авторизации или веб-аутентификация) АйФон отваливается от Wi-Fi.

Сбрасываю ещё раз конфиг UAG5100, чтобы исключить остальные взаимосвязанные настройки, оставив критические. Если проблема повторится, то попробую другие точки доступа.

Таблица 2 — Сравнение поведение АйФонов с различными точками доступа Wi-Fi на этом же шлюзе из таблицы 1, но с нуля заново настроенный по таблице 2.

№ шага

Внесённая настройка

iPhone 4s (iOS 9.3.5), 5s (iOS 12), 6 (iOS 10) и 7 (iOS 11 и 13) и другие отключились от Wi-Fi?

WAN порт, DHCP в LAN подсети и SSID «Test»

Включение Captive Portal (портал авторизации)

Выключение Captive Portal (портал авторизации)

Точку доступа меняю на Zyxel NWA5123-AC с SSID «Test2»

Включение Captive Portal

Выключение Captive Portal

Точку доступа меняю на автономную D-Link DAP-2690 с SSID «Test3»

Включение Captive Portal

Выключение Captive Portal

Точку доступа меняю на домашний однодиапазонный роутер Zyxel Keenetic 4G в режиме точки доступа, чтобы SSID «Test4» работал только на 2.4 ГГц

Включение Captive Portal

Выключение Captive Portal

Точку доступа меняю на Элтекс WEP-2ac «Test5»

Включение Captive Portal

Выключение Captive Portal

Возвращаю точку доступа Zyxel NWA5121-NI в режиме автономной (заранее сбросив её конфиг)

Включение Captive Portal

Выключение Captive Portal

Выключаю DHCP на шлюзе и установил статический IP на АйФонах

Включение Captive Portal

Выключение Captive Portal

Переключаю Zyxel NWA5121-NI в управляемый режим

Включение Captive Portal

В таблицах 1 и 2 Captive Portal тестировал со встроенным сервисом по ваучерам, потом тестировал с пятью внешними сервисами авторизаций, проблема оставалась такая же, iPhone отваливается от Wi-Fi.

Меняю шлюз на другие на тестовом стенде.

Таблица 3 — Проверка поведения АйФонов, подключённых к Wi-Fi после прохождения авторизации через Captive Portal на различных шлюзах.

Наименование шлюза с настройками как из таблицы 2 (1-я и 2-я строки).

iPhone 4s (iOS 9.3.5), iPhone 5s (iOS 12), 6 (iOS 10) и 7 (iOS 11 и 13) и другие отключились от Wi-Fi?

Не шлюз, но с функционалом Captive Portal. Программный комплекс Элтекс SoftWLC

Шлюз Элтекс ESR-20

В таблице 3 проверялись встроенные и внешние сервисы авторизации, поведение не поменялось, iPhone отключается от Wi-Fi.

Прошу обратить внимание, во всех трёх таблицах проблем с Андроидами и Windows не было. Там всё хорошо.

Спросил у знакомого, любителя Микротиков, насчёт АйФонов. Ответил, что у него тоже самое, iPhone отваливаются от Wi-Fi.

Узнаем у Гугла, как у заокеанских коллег на родине АйФонов дела обстоят? Первым предложил ссылку на форум Микротиков

Но больше волнуют Cisco и Aruba, земляки АйФонов, всё-таки в одной стране находятся, может у них получше с этой проблемой.

Вот на форуме Арубы

Там на форуме Cisco

Перевод текста (рис.6, 7 и 8):

А вот и реакция гостей в этой же теме «iPhone silent disconnect issue in guest wireless network.» и как много точек доступа и гостей у них, 6000! точек доступа!

напоследок видео из этой же темы.

Действительно так и ведут себя АйФоны в гостевых сетях с Captive Portal. Даже добавить нечего.

Итог: дочитав вышеуказанные ссылки на форумы, проблему так и не устранили. На американском оборудовании тоже американские АйФоны отваливаются и обратите внимание на даты создания тем. Проблема годами сохраняется. У коллеги iPhone 12 на прошлой неделе обновился на самую последнюю версию iOS 15 и стал отваливаться от Wi-Fi, а на предыдущем обновлении всё нормально было.

Вывод: проблема в устройствах Apple, но не в шлюзах и точках доступа, поэтому рекомендация «смена шлюза и точек доступа» явно не сработала, не помогла и, к огромному счастью, ей следовать не придётся.

В общем, отключение Captive Portal действительно помогает, всё отлично работает, но его отключать нельзя (постановления Правительства РФ №758 от 31 июля 2014 года и №801 от 12 августа 2014 года). Ищем варианты подружить Apple с Captive Portal.

Методом тыка выявил , что есть шанс немного помочь гостям двумя способами, прошедшие авторизацию:

Способ 1 (для чайников):

2. Заново подключиться к Wi-Fi

и устройство не будет отключаться от Wi-Fi до истечения срока авторизации. Когда истечёт авторизация, страница авторизации сама не выскочит и гость впадает в ступор, почему нет интернета и как пройти авторизацию, если страница авторизации не появляется?

Объяснение, с какой проблемой сталкиваются чайники:

по идее, ему нужно идти в Safari и самостоятельно набрать в адресной www.ru или любой http сайт, таких почти не осталось в интернете, всё на https переехало. Большинству набор адреса страницы является трудновыполнимой задачей (в некоторых браузерах адресной строки уже нет).

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

4. Заново подключиться к Wi-Fi;

5. Появится страница авторизации, но после прохождения авторизации по устройство снова будет отключаться от Wi-Fi как прежде. Повторить пункт 1 и 2.

И так каждый раз, пока не поставят последнюю версию iOS (не является 100% гарантией устранения проблем).

Способ 2 (для продвинутых):

2. Заново подключиться к Wi-Fi

и устройство не будет отключаться от Wi-Fi до истечения срока авторизации. Когда истечёт авторизация, страница авторизации сама не выскочит.

3. Зайти в Safari и в адресной строке (не в строке поиска. ) набрать самостоятельно www.ru или http://www.ru или http://6.6.6.6 (IP-адрес хотспота шлюза) или любой http сайт. Редирект на страницу авторизации с https сайта не будет работать;

4. Пройти авторизацию как обычно и всё будет нормально работать, АйФоны не отключаются от Wi-Fi. При истечении авторизации повторить пункт 3.

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

Дальше ещё одно исследование с неуспешным концом. Яндекс подсказал ещё эту статью. Цитирую оттуда кусочек текста

Убедитесь, что страница www.apple.com/library/test/success.html доступа из вашей сети, или настройте редирект на свой веб-сервер, который будет убеждать айфоны в том, что все в порядке. 🙂

Получается, что при подключении к Wi-Fi Apple ищет наличие интернета успешной загрузкой страницы http://www.apple.com/library/test/success.html и если удалось загрузить страницу, значит всё в порядке с доступом в интернет и не будет отключаться от Wi-Fi. Но в сетях с Captive Portal очевидно, что интернета не будет до успешной пройденной авторизации, соответственно Captive Portal не позволит неавторизованным АйФонам загрузить страницу http://www.apple.com/library/test/success.html и выскочит страница авторизации, что в принципе правильное поведение. Если гость потом авторизацию успешно пройдёт, АйФон всё равно будет считать, что интернета нет и продолжит отключаться до сброса сети. Далее, после повторного подключения к Wi-Fi ранее авторизованного АйФона, он не будет отключаться от Wi-Fi, т.к. успешно загрузит http://www.apple.com/library/test/success.html.

Исходя из этого, попробуем занести эту ссылку в белый список, которые можно пропускать в интернет без авторизации.

Это не помогло, АйФоны отключаются от Wi-Fi как обычно, хотя на ссылку удаётся зайти без авторизации.

Всё на сегодня. Мне самому очень нравятся АйФоны, несмотря на цену, но эта вот болячка с Wi-Fi через авторизацию портит всё.

А как у вас? Удалось ли кому решить проблему? Поделитесь, пожалуйста, в комментариях. Предлагайте решение, я проверю у себя и если всё заработает — рюкзак ваш.

Устройства, где нужно пофиксить проблему:

• Zyxel UAG5100 (несильно отличается от шлюзов серий ZyWALL, USG);
• Zyxel VPN300 (несильно отличается от шлюзов серии USG Flex; ATP);
• Точки доступа любые, они не влияют на Captive Portal.

Об авторе:

Кто я? Меня зовут Александр. 16 лет профессионально занимаюсь СКС и сетевым оборудованием. Больше времени провожу с СКС (монтаж, обслуживание), чем с настройкой сетевого оборудования, поэтому на настройки времени особо нет, но получил много опыта работы с сетевым оборудованием различных вендоров. Приветствую простоту и дружелюбность конфигурирования/мониторинга сетевого оборудования, ответственность вендора за качество выпускаемой продукции и готовность исправлять недостатки, чтобы не тормозили сдачу новых проектов в назначенные сроки. Меня можно встретить и лично пообщаться в телеграме — @NSanchez13, так что, если будут вопросы, комментарии, мнения – милости прошу.

• Русскоязычная документация на контроллеры точек доступа Zyxel с функцией межсетевого экрана http://download.from.Zyxel.ru/e2a9ef2c-8a04-4531-99ac-723ae068c44e/NXC2500_NXC5500_V4.10_UG-Rus.pdf
• Новостной канал в Telegram — https://t.me/zyxel_news
• Телеграм-чат поддержки для специалистов — https://t.me/zyxelru
• Форум для специалистов — https://community.zyxel.com/ru/categories
• Свежие новости в FaceBook — https://www.facebook.com/Zyxel.Russia
• Полезные и интересные статьи в блоге Zyxel на Хабре — https://habr.com/company/zyxel
• Наш YouTube — https://www.youtube.com/channel/UCcNN2UCEz1e49PEaAisN5ow
• Реализованные проекты — https://www.zyxel.com/ru/ru/solutions/success_stories_list.shtml
• Виртуальная лаборатория — https://support.zyxel.eu/hc/ru/sections/360001858040
• Удалённый стенд — https://support.zyxel.eu/hc/ru/articles/360014708840
• Мастер выбора оборудования — select.zyxel.ru
• Центр обучения Zyxel — https://academy.zyxel.eu/zcne-ru
• Постановление Правительства РФ №758 от 31 июля 2014 года — http://publication.pravo.gov.ru/Document/View/0001201408050024
• Постановление Правительства РФ №801 от 12 августа 2014 года — http://publication.pravo.gov.ru/Document/View/0001201408190035
• № 436-ФЗ — https://digital.gov.ru/ru/documents/3795
• Размеры штрафов — https://digital.gov.ru/ru/events/33687
• Примеры штрафов — https://mediapravo.com/ilaw/wi-fi-prokuratura.html
• Памятка для ЮЛ и ИП — https://77.rkn.gov.ru/directions/p30822

• zyxel
• zywall
• zyxel. zywall
• wi-fi
• wi-fi по-человечески
• wi-fi hotspot
• wi-fi роутер
• it-инфраструктура
• гостевой wi-fi
• гостевой доступ к wifi

• Блог компании ITT Solutions
• Системное администрирование
• IT-инфраструктура
• Беспроводные технологии
• Сетевое оборудование