Page History

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

Когда абонент выбирает для подключения гостевую сеть, подключается к ней, устройство получает IP-адрес и другие параметры, производится автоматическая попытка определить наличие доступа в сеть Интернет. Наличие доступа проверяется для устройств c ОС Android и iOS:

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

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

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

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

Если отключен CNA, или абонент пытается подключиться к сети Wi-Fi сети при помощи ноутбука, авторизация проводится обычным браузером. При этом абонент, скорее всего, будет пробовать перейти на свой любимый сайт, указанный как стартовый, либо будет пользоваться стартовой страницей поисковой системы (googleGoogle, yandexYandex). В подавляющем большинстве случаев такие сайты работают по протоколу HTTPS, что в обычных условиях делает невозможным редирект (перенаправление) на портал авторизации. Для такого перенаправления пользователь должен перейти по обычной , HTTP ссылке. Однако, большинство из порталов перехвата в оборудовании (беспроводные контроллеры, Linux-маршрутизатор, Mikrotik и т.п.) могут проводить перехват и перенаправление и HTTPS-сессии. Для этого необходимо, как минимум, иметь установленный SSL-сертификат как в устройство доступа, так и в сервер системы WNAM. При попытке перехода браузером по HTTPS-ссылке  портал перехвата производит подстановку своего сертификата вместо сертификата сервера. Большинство браузеров на такую операцию выдают предупреждение, вынуждая пользователей принять риск :при переходе на страницу сети Интернет.

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

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

...

...

...

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

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

...

...

...

...

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

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

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

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

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

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

# openssl x509 -in cert.pem -text -noout

Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number:
 03:0c:ab:c8:e6:3a:0c:7e:5a:e5:ff:23:ab:5f:cf:9b:15:a5
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
 Validity
 Not Before: May 15 14:45:00 2016 GMT
 Not After : Aug 13 14:45:00 2016 GMT
 Subject: CN=mk.k18.netams.com
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 Public-Key: (2048 bit)
 Modulus:
 ... 
 Exponent: 65537 (0x10001)
 X509v3 extensions:
 X509v3 Key Usage: critical
 Digital Signature, Key Encipherment
 X509v3 Extended Key Usage: 
 TLS Web Server Authentication, TLS Web Client Authentication
 X509v3 Basic Constraints: critical
 CA:FALSE
 X509v3 Subject Key Identifier: 
 C4:B9:60:6C:08:8E:00:AB:9D:F9:40:59:09:1A:16:B3:62:3C:71:36
 X509v3 Authority Key Identifier: 
 keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1 

Authority Information Access: 
 OCSP - URI:http://ocsp.int-x3.letsencrypt.org/
 CA Issuers - URI:http://cert.int-x3.letsencrypt.org/ 

X509v3 Subject Alternative Name: 
 DNS:mk.k18.netams.com
 X509v3 Certificate Policies: 
 Policy: 2.23.140.1.2.1
 Policy: 1.3.6.1.4.1.44947.1.1.1
 CPS: http://cps.letsencrypt.org
 User Notice:
 Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/ 

Signature Algorithm: sha256WithRSAEncryption
 ...

Вы можете Можно установить сертификат в nginx, если вы оставили tomcat на порту 8080 , и используете nginx в качестве фронт-сервера. Подробнее здесьПодробная информация про установку системного ПО представлена в соответствующем разделе настоящей документации (здесь).

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

Необходимо В первую очередь необходимо преобразовать сертификат и закрытый ключ к нему в формат JKS, распознаваемый веб-сервером.  Помещаем Для этого следует поместить полный сертификат из файла fullchain1.pem и закрытый ключ из файла privkey1.pem в контейнет контейнер PKCS#12 с именем debian64.p12. При конвертации укажем следует указать пароль на контейнер: Password.

    openssl pkcs12 -export -in fullchain1.pem -inkey privkey1.pem -out debian64.p12 -name tomcat

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

    keytool -importkeystore -deststorepass Password -destkeypass Password -destkeystore debian64.jks -srckeystore debian64.p12 -srcstoretype PKCS12 -srcstorepass Password -alias tomcat

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

    cp debian64.jks /etc/tomcat7/

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

    <Connector port="443" protocol="org.apache.coyote.http11.Http11Protocol" URIEncoding="UTF-8" keystoreFile="/etc/tomcat7/debian64.jks" keystorePass="Password" keyAlias="tomcat" keyPass="Password"
     maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" />

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

    touch /etc/authbind/byport/443

    chmod 500 /etc/authbind/byport/443

    chown tomcat7 /etc/authbind/byport/443

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

    /etc/init.d/tomcat7 restart

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

    INFO: Deployment of web application archive /var/lib/tomcat7/webapps/ROOT.war has finished in 52,197 ms
    май 15, 2016 6:58:21 PM org.apache.coyote.AbstractProtocol start
    INFO: Starting ProtocolHandler ["http-bio-80"]
    май 15, 2016 6:58:21 PM org.apache.coyote.AbstractProtocol start
    INFO: Starting ProtocolHandler ["http-bio-443"]
    май 15, 2016 6:58:21 PM org.apache.catalina.startup.Catalina start
    INFO: Server startup in 54766 ms

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

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

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

1. Переместите Переместить файлы с сертификатом и ключом на файловую систему маршрутизатора. Для этого удобно использовать утилиту Winbox:.
   
   
   
2. Импортируйте Импортировать сертификаты через Winbox или HTTP Web интерфейс в меню "System-Certificates". Пароль при импорте указывать не требуется:.
   
   
   
3. Включите Включить HTTPS режим в меню "System-Services" , (www-ssl), выберите после чего выбрать сертификат cert_1 и порт 443:.
   
   
   
4. После этого административный интерфейс администратора Mikrotik должен быть доступен по имени и по порту HTTPS:.
   
   
   
5. В настройках профиля сервера хотспота необходимо указать DNS-имя (как в сертификате), перехват по HTTPS, сертификат:.
   
   
   
   

6. В файле перенаправления hotspot/rlogin.html, который

   вы должны

   необходимо отредактировать и загрузить в Mikrotik, необходимо изменить редирект на HTTPS-версию портала с обращением по DNS-имени, а также адрес сервера:

<form

...

name="wnamlogin"

...

action="https://debian64.k18.netams.com/cp/mikrotik"

...

method="post"> 
<input

...

type="hidden"

...

name="server-address"

...

value

...

=

...

"mk.k18.netams.com:443"

...

/>

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

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

Внимание: на вашей ответственности следить за тем, чтобы установленные сертификаты не закончили свой строк действия!