Disable captive portal detection anyconnect что это

Обновлено: 05.07.2024

При подключении к Интернету система проверяет, находится ли он в окруженном стеной саду, который просто пытается подключиться к Google. В случае сбоя в Android 5 на значке WiFi или значке сигнала будет восклицательный знак.

В некоторых ситуациях это раздражает. Скажем, в Китае Google заблокирован, всегда будет восклицательный знак, что бессмысленно.

Как я могу отключить эту проверку, и заставить систему предполагать, что подключенные WiFi / мобильные данные подключены к Интернету?

Открыто, потому что это другой вопрос IMO. Вы можете отключить это, не сталкиваясь с проблемой в другом вопросе.

Это просто. В терминале (требуется root) или в adb shell (не требует root) введите команду

и перезагрузите компьютер. Это должно быть отключено. Существующее состояние также можно проверить с помощью команды

Ответ «null» означает, что значение глобального ключа не было установлено, и Android вернется к значению по умолчанию, когда он включен и выполняет обнаружение. Если обнаружение отключено, ответ «0» будет получен.

Это также работает в 5.

Большой! Отмечу, что ссылка описывает это в 4.2.2 и 4.3. Проверяли ли вы (или кто-либо еще), что это также работает в 5.0.x? @SimonW да, это работает. Вот почему я пометил вопрос леденец. Я использую CyanogenMod 12, хотя. Я в Android Noob. Нужно ли рутировать это, чтобы заставить это пойти? Комментарий Гери , у которого нет представителя: для тех, кто впервые использует терминал, не забудьте поставить команду «su» перед тем, как что-либо сделать, чтобы разрешить права суперпользователя. (Мне потребовалось некоторое время, чтобы понять, почему я получаю «отказано в разрешении»).

В Android M Developer Preview для Shamu (Nexus 6) и, возможно, других сборок этой ОС, ОС captive_portal_server global используется независимо от состояния captive_portal_detection_enabled для определения работоспособности сети WiFi.

Для сетей WiFi, он не только нарисует восклицательный знак на значке силы, он будет занесен в черный список, что SSID от автоматического переподключения, если он не успешно curl URL, указанный в captive_portal_server global через этот SSID. Ручное переподключение разрешено, но будет оставаться подключенным, только если у вас есть captive_portal_detection_enabled и выберете «Использовать эту сеть как есть» вручную, каждый раз при подключении к этому WiFi SSID. Это переопределение является временным.

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

На вашем рутированном устройстве решение состоит в том, чтобы повторно включить его, captive_portal_detection_enabled если вы его отключили, подключиться к этой сети Wi-Fi, выбрать «Использовать эту сеть как есть» в раскрывающемся меню во всплывающем окне портала, отключить мобильную сеть. данные, чтобы сосредоточиться на определении веб-сайта, который можно получить через вашу сеть Wi-Fi, войдя в свой портал, а затем используйте браузер, чтобы найти тот, который работает. После этого вы можете отключить, captive_portal_detection_enabled чтобы предотвратить раздражающее всплывающее окно.

Чтобы включить ваш captive_portal_detection , если вы ранее отключили его, введите команду:

Отключите мобильную сеть (в разделе «Настройки» - «Использование данных» - «Мобильные данные» - «Выкл.»), Чтобы временно использовать телефон для использования сети WiFi для всего трафика. Это не потребуется, если у вас есть все настройки, где они должны быть.

Android M, кажется, требует, чтобы веб-сайт загружался успешно и не возвращал активно 204 (без контента).

Несколько вариантов включают, но не ограничиваются

Сохраните сервер, запустив его в своем терминальном приложении с включенным корнем, заменив пример URL на тот, который, как вы надеетесь, будет работать:

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

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

Prerequisites

Requirements

Cisco recommends that you have knowledge of the Cisco AnyConnect Secure Mobility Client.

Components Used

The information in this document is based on these software versions:

  • AnyConnect Version 3.1.04072
  • Cisco Adaptive Security Appliance (ASA) Version 9.1.2

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background Information

Many facilities that offer Wi-Fi and wired access, such as airports, coffee shops, and hotels, require users to pay before they obtain access, agree to abide by an acceptable use policy, or both. These facilities use a technique called captive portal in order to prevent applications from connecting until users open a browser and accept the conditions for access.

Captive Portal Remediation Requirements

Support for both captive portal detection and remediation requires one of these licenses:

  • AnyConnect Premium (Secure Sockets Layer (SSL) VPN Edition)
  • Cisco AnyConnect Secure Mobility

You can use a Cisco AnyConnect Secure Mobility license in order to provide support for captive portal detection and remediation in combination with either an AnyConnect Essentials or an AnyConnect Premium license.

Note: Captive portal detection and remediation is supported on the Microsoft Windows and Macintosh OS X operating systems supported by the release of AnyConnect that is in use.

Captive Portal Hotspot Detection

AnyConnect displays the Unable to contact VPN server message on the GUI if it cannot connect, regardless of the cause. The VPN server specifies the secure gateway. If Always-on is enabled and a captive portal is not present, the client continues to attempt to connect to the VPN and updates the status message accordingly.

If the Always-on VPN is enabled, the connect failure policy is closed, captive portal remediation is disabled, and AnyConnect detects the presence of a captive portal, then the AnyConnect GUI displays this message once per connection and once per reconnect:

If AnyConnect detects the presence of a captive portal and the AnyConnect configuration differs from that previously described, the AnyConnect GUI displays this message once per connection and once per reconnect:

Caution: Captive portal detection is enabled by default and is nonconfigurable. AnyConnect does not modify any browser configuration settings during captive portal detection.

Captive Portal Hotspot Remediation

Captive portal remediation is the process where you satisfy the requirements of a captive portal hotspot in order to obtain network access.

AnyConnect does not remediate the captive portal; it relies on the end user to perform the remediation.

In order to perform the captive portal remediation, the end user meets the requirements of the hotspot provider. These requirements might include payment of a fee to access the network, a signature on an acceptable use policy, both, or some other requirement that is defined by the provider.

Captive portal remediation must be explicitly allowed in an AnyConnect VPN Client profile if AnyConnect Always-on is enabled and the Connect failure policy is set to Closed. If Always-on is enabled and the Connect Failure policy is set to Open, you do not need to explicitly allow captive portal remediation in an AnyConnect VPN Client profile because the user is not restricted from network access.

AnyConnect Behavior

This section describes how the AnyConnect behaves.

AnyConnect Captive Portal Detection and Remediation

Captive Portals

Captive portal — сетевой сервис, требующий от подключившегося к сети пользователя выполнить некоторые действия для получения доступа в Интернет. Обычно используется для взимания платы, аутентификации абонента либо показа рекламы. Настроим его что-бы он стучался не на google.

Дальнейшая инструкция подразумевает то, что вы уже получили root через magisk

image

Присоединяем телефон по USB, запускаем терминал (linux;macos) и заходим в shell, ./adb shell , и переходим в режим админа su . Может отбить: permission denied, в этом случае заходим в magisk и даем shell рута.

image

Далее вводим следующие команды. Я выбрал заменить google на магазин f-droid

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

False Captive Portal Detection

AnyConnect can falsely assume it is in a captive portal in these situations.

    If AnyConnect attempts to contact an ASA with a certificate that contains an incorrect server name (CN), then the AnyConnect client will think it is in a captive portal environment.

In order to prevent this issue, make sure that the ASA certificate is properly configured. The CN value in the certificate must match the name of the ASA server in the VPN client profile.

Как я избавлялся от Google на Android

image

Недавно на работе получил задачу от руководителя: сделай так чтобы телефон android не сливал данные гуглу. Можете представить мой восторг (и предвкушение) ибо спустя 2 недели тестов я вполне уже чувствовал себя человеком который прошивает телефоны на радиорынке (ничего личного, просто не мой профиль). Прочел отличную статью и понабравшись опыта решил немного дополнить. Статья кстати отличная, рекомендую к прочтению.

Давайте рассмотрим несколько альтернативных операционных систем якобы без сервисов гугла, и выясним действительно ли они не общаются с гуглом. Подготовился я к слову основательно, для тестов даже приобрел девайс "pixel 3", так как GrapheneOS работает только с устройствами от google.

Хотел протестировать еще:

    Но к сожалению моего девайса не было в списке Та же проблема Было желание приобрести тестовый девайс. Но после обзора на youtube, желание пропало, так как он очень тормозит, и сложно его представить в роли смартфона для повседневного пользования.

Disable the Captive Portal Feature

It is possible to disable the captive portal feature in AnyConnect client version 4.2.00096 and later (see Cisco bug ID CSCud97386). The administrator can determine if the option should be user configurable or disabled. This option is available under the Preferences (Part 1) section in the profile editor. The administrator can choose Disable Captive Portal Detection or User Controllable as shown in this profile editor snapshot:


WebView

Советую заменить браузер на "duck go browser" который можно найти на aurora store

LineageOS

image

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

Существует несколько способов ограничить доступ телефона к google:

  • Использование firewall. В моем случае я использовал afwall+, его можно скачать в магазине f-droid или же в aurora store, который можно скачать там же
  • Второй способ, менее радикальный и более трудоемкий. Он заключается в подмене сервисов. Настройка на службах альтернатив google.

Каждый способ требует root права. Описывать как их получить не буду, так как есть огромное количество статей на эту тему, и в зависимости от модели телефона инструкция может меняться. Я использовал magisk

Подмена сервисов

Необходимо настроить следующие сервисы:

По дефолту LineageOS использует гугловые dns 8.8.8.8, было бы не плохо заменить их на cloudflare 1.1.1.1. Идеальным решением будет использовать vpn и завернуть туда весь трафик, в противном случае для каждой wifi сети надо будет вбивать руками кастомные dns. Альтернативой является установка приблуды через magisk "CloudflareDNS4Magisk", или какой-либо другой с магазина, но там на свой страх и риск. Как по мне лучше с гугловыми dns, чем непонятным магазинным софтом.

Использование firewall

Ну с этим, думаю, понятно. Блокируем все, и разблокируем по мере необходимости (для AFwall+ понадобятся root права). В android 10 добавили модуль Network Stack Permission Config module. Если заблочить данный модуль то система будет говорить что у данной сети нет доступа к интернету.
Тем не менее интернет будет работать в обычном режиме. Так как у меня гугловый девайс Pixel 3, то были подозрения что устройство общается с google на hardware уровне. Но они развеялись после того как заблокировал все и снял дамп с роутера. Результаты показали что за двое суток устройство дальше внутренней сети не ушло.

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

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

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

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

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

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

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

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

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

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

Выводы:

Огромное количество информации сливается даже при кастомных прошивках которые, позиционируют себя как свободные от google. А по факту когда снимаешь дамп трафика то мягко говоря удивляешься.

Если вы выберете второй способ, то все-равно не пренебрегайте использованием firewall, я неделю проверял данные с роутера, пробовал разные варианты (что будет если заблокировать эту службу, а что если эту). Оказалось что это самый надежный способ. Как и любая настройка firewall, блокируем все, разблокируем по надобности.

Изучал вопрос приватности и решил поделится с Хабром, так как Хабр часто делится со мной. Может кому-то это будет полезно. Спасибо если дочитали до конца.

Hosts

Желательно заблокировать следующие сайты в файле hosts. Так как мы блокируем google нужно выбрать другой поисковик, предлагаю этот.

Captive Portal Incorrectly Detected with IKEV2

Workarounds

If you encounter this issue, here are some workarounds:

This issue is resolved by Cisco bug ID CSCud17825 in Version 3.1(3103).

GrapheneOS

На первый взгляд система позиционирует себя как максимально безопасная и анонимная. Есть пару нюансов которые мне не понравились:

Ничего необычного, этот сервис называется Captive portal используется для андроид с 4 версии. При наличии root можно выбрать другие независимые сервера или на крайняк поднять свой. Но такой возможности нет и приходится довольствоваться услугами google. Также разработчик утверждает что использование других серверов в качестве альтернативы нежелательно, по причине того что телефон будет более узнаваем в толпе, но говорит, что такая функция находится в разработке (правда имеет маленький приоритет)

Читайте также: