Captive apple com андроид

CaptivePortalLogin что это такое то?

Всем привет Поговорим мы о такой штуке как CaptivePortalLogin, я расскажу что это такое и почему оно у вас появляется. Как я думаю, то CaptivePortalLogin предназначен для безопасного пользования открытыми вай фай частными сетями, то есть публичными. Когда вы захотите подключится к такой сети, то у вас выскочит предупредительное сообщение CaptivePortalLogin, где нужно нажать кнопку и в принципе все… Это касается вроде бы только телефонов Samsung, но у других тоже может быть такой прикол

Если отключить CaptivePortalLogin, то есть риск что вы не сможете подключиться к вай фай сети, так что учтите это

Я пошел в гугловский переводчик и написал туда Captive Portal Login:

И вот что мне выдал переводчик:

То есть все верно, это вход в систему, можно сказать еще что CaptivePortalLogin это некая дополнительная авторизация перед использование публичной беспроводной сети.

Вот смотрите, нашел картину, это Application manager, вкладка All и тут есть приложение CaptivePortalLogin:

Весит приложение 96 Кб, а это оч и оч мало…

В окне Сведения о приложении (App info) вы можете попробовать отключить приложение, если нажмете на FORCE STOP (но как я уже писал тогда у вас может быть ошибка при подключении к беспроводной сети):

Значит можно ли отключить CaptivePortalLogin, то я уже написал, что в принципе может и можно, но будут ли в таком случае нормально подключаться вай фай сети, то это неизвестно. В сети я также нашел способ как отключить CaptivePortalLogin, так чтобы и можно было подключаться к вай фай сетям, для этого нужно установить приложение WifiAutoLogin. Собственно из названия WifiAutoLogin понятно уже, что главная функция проги это автологин для вай фай сети, чтобы вы вручную не подтверждали. Ссылку где можно скачать WifiAutoLogin я давать не буду, скажу только то, что при желании все легко находится в поисковике

Так, еще раз, какой делаем вывод? CaptivePortalLogin это приложение для вывода запроса-подтверждения при подключении к вай фай сети. Если отключить, то есть риск что вообще не будет подключаться сеть. Решение это использовать WifiAutoLogin, пойдите на форум 4PDA, там есть тема с обсуждениями.

Надеюсь что все тут было понятно. Удачи вам

Источник

Можете ли вы освободить себя от captive.apple.com?

Порталы Wi-Fi используют уродливый хакер для перехвата соединения, когда место встречи требует, чтобы вы либо заплатили, либо вошли в систему с учетной записью, либо приняли условия перед использованием бесплатной сети. Когда вы выбираете сеть Wi-Fi, ваше устройство Mac или iOS (или другое) получает законный адрес локальной сети, но хак, который существует уже около двух десятилетий, перехватывает запросы DNS (системы доменных имен).

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

Apple несколько лет назад упростила представление страниц портала. Ранее (и до сих пор на некоторых платформах) вам нужно было загрузить веб-страницу, чтобы увидеть портал, и разобраться с ним. Но Apple поняла, что может выполнить проверку DNS при подключении к сети, чтобы выяснить, может ли она разрешить один из своих собственных доменов. В случае неудачи он распознает, что устройство подключено к порталу, и откроет страницу квази-входа, с которой вы уже знакомы: она выглядит как веб-страница, но это модальное окно, расположенное поверх macOS. или интерфейс iOS.

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

В верхней части этого окна в iOS появляется доменное имя, и оно коротко скажет captive.apple.com до завершения загрузки страницы портала. Я заметил это намного больше в iOS 11, чем в предыдущем выпуске, так что, возможно, Apple ввела задержку или изменение, чтобы каждое доменное имя появлялось достаточно долго, чтобы его прочитать? Проверяя форумы поддержки, я нахожу людей, спрашивающих о доменном имени в течение последних нескольких лет, но я никогда не замечал его до этого выпуска.

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

Спросите Mac 911

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

Источник

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 выполнять перенаправление пользователя на специальную страничку «сервиса нет, но мы чиним изо всех сил».

В случае централизованного captive portal все три компонента очевидным образом располагаются на одной машине (устройстве), что сильно упрощает задачу. Firewall в данном случае часто исполняет ещё и NAT, а captive portal можно реализовать в виде кучки скриптов, которые подкручивают локальный iptables. Возникает труднопреодолимое желание натолкать в сеть дешёвых точек доступа, которые свалят нам всех пользователей в ethernet или в самом лучшем случае — в отдельный vlan. Какие здесь проблемы:

• Проблемы с безопасностью. Мы ограничиваем доступ к внешнему каналу, однако в локальной сети всё плохо. Поскольку сеть открытая, любой пользователь может отвечать на 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 для этого клиента настроен одинаково.

Тонкости

Метод взаимодействия с captive portal. Нам нужен механизм, с помощью которого мы можем сообщить порталу результаты взаимодействия с пользователем. В нашем случае в качестве такого механизма был выбран HTTP GET. При необходимости приоткрыть портал мы посылаем HTTP GET в любое из его представительств. Состав передаваемых в GET параметров зависит от режима, в котором работает портал. Здесь несколько вариантов:

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

Всё, что за пределами этой логики, требует реализации в web frontend. Например, можно спросить у пользователя телефон, послать ему смс, проверить код. По результатам — зарядить в радиус пользователя (например) с username=номер_телефона и password=его_IP и дальше послать GET в портал с этими значениями.

Как портал, получив 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 пользователя (мы умеем), запоминать там, что мы ему уже посылали смс и при втором заходе спрашивать уже код. Ибо куки этот минибраузер не поддерживает.

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

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

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

В случае успеха последнего шага предполагаем, что интернет есть и слезаем с 3G. И так делаем при каждом подключении к wifi. Даже дома.
Если вместо «Success» наблюдаем что-то не то — вот он captive portal. Пора запускать минибраузер. Не смог пользователь за один раз договориться с порталом в окошке — отключаемся. Проблема с айфоном состоит в том, что он до последнего надеется на лучшее. Если вы просите подключиться к сети, и её видно на более, чем одной точке — будут перепробованы все варианты. Убьётся время. Большинство устройств, увидев портал, предполагают, что он тут везде, наверное.

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

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

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

Источник