Gstatic com generate 204 что это

http://connectivitycheck.gstatic.com/generate_204 error — что это на Андроиде?

Приветствую. http://connectivitycheck.gstatic.com/generate_204 error — адрес (URL), который предположительно запрашивает Андроид (точнее HTTP-клиент Dalvik) для проверки соединения с интернетом.

Если веб-сервер отвечает кодом 200 или 204 (точно выяснить не удалось), Андроид предлагает подключиться к порталу. Слово error сообщает о неудачной проверке (ошибка).

The URL “http://www.gstatic.com/generate_204” is opening up for no reason in Chrome

Starting from a few days ago I have had the page http://www.gstatic.com/generate_204 open up in a new browser tab sometimes for seemingly no reason. I don’t know what is triggering it. It’s always an empty page and it is titled "Untitled".

From Googling it looks like this has something to do with accessing http websites, but I don’t know what’s causing it to happen now, when it didn’t use to happen before. All I know is that the first time I saw this page, it was when I tried to access an HTTP page hosted on another computer connected to my router, and I wasn’t able to do so because of the router’s settings.

Note that I am only mentioning this in case this is relevant, and it was the first time I ever remember seeing the gstatic page on this computer. My question is not about the http page hosted in a different computer on my router.

What exactly is this gstatic page and why is it popping up by itself?

Can/should I disable this page from popping up, or is it indicating any kind of problem with chrome or the computer?

Can't connect to home WiFi (generate_204)

Setting up my new HP 11 and am unable to connect to my home WiFi. A popup asks me to sign in to the network, which then opens up gstatic.com/generate_204.

That page then directs to the IP/ broadband provider page of my router, telling me my internet connection is unavailable.

WiFi is now down on all devices: restarted router, no dice. I'm not sure if the two problems are connected or it's just a bad coincidence.

Lots of issues with gstatic reported on google seem to be related to public WiFi, not home networks, so I'm a bit lost.

Портал перехвата HTTPS

Работоспособность WNAM тесно связана с возможностью надежной, удобной авторизации абонентского устройства в беспроводной сети.

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

Когда абонент выбирает для подключения гостевую сеть, подключается к ней, устройство получает IP адрес и другие параметры, производится автоматическая попытка определить наличие доступа в Интернет.

• Устройства Android запрашивают ссылку http://www.gstatic.com/generate_204
• Устройства iOS запрашивают (в зависимости от версии) ссылки из доменов www.ibook.info, www.appleiphonecell.com, captive.apple.com и т.п.

Если ответ по этим ссылкам приходит, устройство считает себя подключенным к Интернет. Если ответа нет, открывается специальный браузер (мини-браузер), в котором предполагается провести авторизацию в сети. Это называется Captive Network Assistant (CNA).

С сложными системами, в которых предполагается ввод авторизационного СМС или совершения звонка, CNA может работать плохо. В некоторых беспроводных контроллерах (Cisco, Aruba) можно включить функцию CNA Bypass, что позволяет при подключении абонентского устройства "обманывать" его, заставляя считать, что интернет уже предоставлен. В таком случае абоненту необходимо вручную открыть браузер, и перейти на какую-то вебстраницу.

За включение CNA в iOS отвечает настройка "автовход", но обычно про неё пользователи не знают:

Если отключен CNA, или абонент пытается подключиться к Wi-Fi сети при помощи ноутбука, авторизация проводится обычным браузером. При этом абонент, скорее всего, будет пробовать перейти на свой любимый сайт, указанный как стартовый, либо будет пользоваться стартовой страницей поисковой системы (google, yandex). В подавляющем большинстве случаев такие сайты работают по протоколу HTTPS, что в обычных условиях делает невозможным редирект (перенаправление) на портал авторизации. Для такого перенаправления пользователь должен перейти по обычной, HTTP ссылке.

Однако, большинство из порталов перехвата в оборудовании (беспроводные контроллеры, Linux-маршрутизатор, Mikrotik и т.п.) могут проводить перехват и перенаправление и HTTPS-сессии. Для этого необходимо, как минимум, иметь установленный SSL-сертификат как в устройство доступа, так и в сервер WNAM.

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

Фактически, портал перехвата проводит атаку типа MITM (Man-In-The-Middle), так что предупреждение браузера уместно. Причина такого поведения клиентского браузера в следующем:

• Браузер запрашивает https-ссылку. При этом клиентское устройство пробует установить HTTPS (т.е. SSL) соединение на IP адрес ресурса, полученный после DNS-запроса, и порт 443.
• Хотспот (контроллер беспроводных точек, микротик) заворачивают этот запрос на себя, на собственный встроенный веб-сервер, производя операцию трансляции адресов.
• Клиент успешно совершает TCP-соединение, и затем пробует установить SSL-соединение, проверяя сертификат отвечающей стороны. Хотспот или контроллер, имея сертификат, выдают его для проверки.
• Даже если этот сертификат "настоящий", т.е. купленный и валидный, всё равно в нём содержится имя (например, auth.provider.ru), не соответствующее запрошенному ресурсу (например, google.com). Действительно, откуда у вас серверный сертификат Google?
• Клиентское Wi-Fi устройство, видя такое несоответствие, показывает предупреждение.

Внимание! Данное поведение — не следствие ошибки или недоработки WNAM, это свойство самой технологии SSL и работы браузеров с HTTPS-сайтами. Это невозможно ни изменить, ни исправить .

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

• Настроить и протестировать работу WNAM в режиме HTTP-перехвата и авторизации
• Получить годные, подписанные и проверяемые HTTPS-сертификаты
• Установить HTTPS-сертификат в веб-сервер tomcat, который исполняет приложение WNAM и который служит порталом авторизации
• Установить HTTPS-сертификат в устройство, осуществляющее функции портала перехвата

Внимание! Даже, если вы настроите контроллер или хотспот на перехват HTTPS-трафика и перенаправление его на авторизацию WNAM, в любом случае абоненту будет показано окно ошибки сертификата. Вы можете пойти таким путем, а можете отключить перехват HTTPS, что приведет к появлению белого экрана или ошибки доступа у абонентов, пытающихся перейти по HTTPS-ссылке без участия CNA.

Получение сертификатов

Для работы HTTPS-авторизации вам потребуется легально выписанный, авторизованный сертификат SSL. Вы можете:

• Выписать так называемые "самоподписанные" сертификаты, однако браузеры абонентских устройств не смогут проверить их подлинность и всегда будут отображать сообщение об ошибке
• Приобрести сертификаты у сторонних организаций, таких как Synamtec, Thawte, Verisign, Comodo и т.п. Сертификаты покупаются на 1 год
• Выписать бесплатный сертификат при помощи сервисов типа Let’s Encrypt (обновления вручную каждые 90 дней) или WoSign

В любом случае у вас будут приватный ключ и публичный сертификат, а также цепочка сертификатов. Для получения сертификатов типа Letsencrypt применяется проверка принадлежности имени, указываемом в сертификате, вам. Такая проверка производится путем запроса к имени, указанному в сертификате, извне. Таким образом вы должны либо организовать работу сервера доступа либо на публичных IP-адресах, в которые преобразуются DNS-имена из сертификатов, либо использовать технологию Split DNS и специальный DNS-сервер для Wi-Fi абонентов.

В нашем примере далее предположим, что у сервера доступа типа Mikrotik внешний адрес 172.16.130.9 и имя mk.k18.netams.com, а у сервера WNAM адрес 1 72.16.130.13 и имя debian64.k18.netams.com. Все сказанное ниже справедливо и для доменов 2-го уровня, и для Wildcard-сертификатов (типа *.mydomain.ru).

Сертификат, полученный у Letsencrypt, имеет вид:

Вы можете установить сертификат в nginx, если вы оставили tomcat на порту 8080, и используете nginx в качестве фронт-сервера. Подробнее здесь.

Установка сертификата в tomcat

Необходимо преобразовать сертификат и закрытый ключ к нему в формат JKS, распознаваемый веб-сервером.

Помещаем полный сертификат из файла fullchain1.pem и закрытый ключ из файла privkey1.pem в контейнет PKCS#12 с именем debian64.p12. При конвертации укажем пароль на контейнер: Password

Создаем ключевое хранилище в формате JKS c этим контейнером и таким же паролем:

Копируем хранилище в каталог конфигурации вебсервера tomcat:

Редактируем файл конфигурации вебсервера /etc/tomcat7/server.xml так, чтобы в нем появился блок:

Добавляем возможность вебсерверу работать на привелигированном порту HTTPS (443):

После этого перезапускаем веб-сервер:

После запуска в лог-файле /var/log/tomcat7/catalina.out должны появиться следующие строки:

Если после этого административный интерфейс WNAM открывается по ссылке https://имявашегосервера/wnam/home, и браузер показывает на корректно установленное SSL-соединение, то установка сертификата прошла успешно:

Установка сертификата в портал перехвата

В данном примере описана установка и настройка маршрутизатора Mikrotik. Для других типов устройств доступа воспользуйтесь соответствующей инструкцией производителя.

Переместите файлы с сертификатом и ключом на файловую систему маршрутизатора. Для этого удобно использовать утилиту Winbox:

Теперь необходимо протестировать подключение абонента и перенаправление его сессии с изначально запрошенной HTTPS-страницы на HTTPS-портал авторизации и обратно на Mikrotik. В случае успеха авторизация пойдет по шифрованному SSL-каналу:

Если вы забудете указать имя сервера в шаблоне rlogin.html, то на последнем шаге авторизации возникнет ошибка:

Внимание: на вашей ответственности следить за тем, чтобы установленные сертификаты не закончили свой строк действия! Бесплатные сертификаты Let’s Encrypt выдаются на срок 90 дней, платные на 1 год.