Как подружить Mikrotik HotSpot со стартовой рекламной Pop-Up страницей (Login Page, Captive Portal) и устройства Apple (iPhone, iPad, MacBook)

Ранее я уже неоднократно создавал системы HotSpot на базе оборудования Mikrotik, правда, никогда не вникал в тонкости совместимости с продукцией Apple, в частности с устройствами iPhone, iPad и MacBook.

Последний объект, для которого я создавал небольшой HotSpot, отличался тем, что большинство его посетителей как раз таки использовали продукцию Apple. Тут то и всплыли все те грабли, на которые начали спотыкаться iPhone.

Если коротко, использовался HotSpot с измененной страницей авторизации и триальным доступом по времени. Собственно стартовая страница была изменена под заказчика.

Ноутбуки и ПК на базе операционной системы Windows без проблем определяют подключение к HotSpot, причем никаких дополнительных настроек не требуется, достаточно стандартных настроек в пошаговом мастере. Та же ситуация со всеми устройствами, работающими под управлением операционной системы Android – все смартфоны и планшеты без проблем определяют подключение к Mikrotik HotSpot и выполняют переадресацию на гостевой портал.

Проблема с устройствами Apple довольно распространенная, существует сотни тем на разных форумах, но нет единого решения проблемы. Кому-то помогают одни методы, кому-то другие, так или иначе гарантированно 100%-ного решения я не нашел, причем поиск решения я начинал именно с зарубежных ресурсов и официального форума Mikrotik.

Сама суть проблемы заключается в том, что устройства Apple могут не определять гостевой портал и, соответственно не выполняют переадресацию. Проблема усугубляется трендом последних лет – повальным переходом ресурсов к использованию HTTPS.

Mikrotik без проблем выполняет в браузере переадресацию для тех сайтов и страниц, которые используют обычный протокол HTTP, данные ведь не зашифрованы. А вот с HTTPS у Mikrotik имеются проблемы, переадресация не происходит, при этом в браузере выдается ошибка о невозможности отображения страницы.

Общие рекомендации Apple по настройке точек доступа Wi-Fi

Начнем с общих рекомендаций Apple по настройке точки доступа в целом. Опираться будем на официальную документацию из справочного раздела. У Apple в этом плане своя религия, местами противоречащая со здравым смыслом.

Все мы прекрасно знаем, что МАС-адрес можно без проблем изменить, тем не менее, в ряде случаев фильтрация по МАС может быть неплохим дополнением к общей политике безопасности. Конечно, для публичного HotSpot вы не будете регистрировать все МАС.

Тем не менее, Apple рекомендует отключать MAC ACL как таковой в принципе. Более того, американцы нам говорят о том, что при сканировании доступных сетей, начиная с iSO 8 и выше, используется случайно сгенерированный MAC. Следовательно, фильтрацией по MAC и отключением Default Authenticate пользоваться нельзя.

В плане общих настроек безопасности, Apple придерживается все тех же позиций, что и весь цивилизованный мир – использование только наиболее защищенного WPA2 с шифрованием AES. Никаких WPA, WEP и TKIP – забудьте про них раз и навсегда.

 

Позиция Apple касаемо выбора стандартов, мягко говоря, странная, компания придерживается той позиции, что необходимо всегда выбирать режим «совместимости», т.е. для 2.4 ГГц это смешанный 802.11 b/g/n. И никого при этом не волнует, что удаленный клиент с низким уровнем сигнала, ухватившийся за точку на древнем 802.11b будет вешать производительность всей сети.

     

Я правда не знаю, кто писал и/или переводил справочный раздел на русском языке, но тут я нашел полную ахинею о том, что, оказывается в диапазоне 5 ГГц есть стандарты 802.11a/b/g/n.

Нет, я понимаю, что 802.11a/n работают в 5 ГГц, но коим боком сюда приписали 802.11b/g Для меня остается загадкой. Если вы склоняетесь к «трудностям перевода», спешу вас разочаровать, та же наркомания написана и в английской версии документации. По крайней мере, на момент написания данного теста, скриншоты прилагаются.

Вообще для 5 ГГц оправдано оставлять 802.11n/ac, а не 802.11a/n как написано. Стандарт «А» давно устарел, а те ноутбуки, которые могут вам попасться с поддержкой 5 ГГц уж точно смогут работать на стандарте «N».

Теперь что касается ширины каналов. В Apple настоятельно рекомендуют ставить принудительно ширину канала 20 МГц для 2.4 ГГц, ссылая на проблемы совместимости, стабильности и прочую чушь.

Действительно, каналы на 40 МГц приводят к зашумлению радиоэфира, особенно если в радиусе действия несколько точек доступа. В случаях, когда радиоэфир не загружен, 40 МГц обеспечивают лучшую скорость и производительность сети в целом, обеспечивая более быстрое обслуживание клиентов. Причем современные устройства сами, без помощи Apple могут определить, использовать им 20 или 40 МГц. Ноутбуки без проблем могут цепляться на 40 МГц, в то время как рядом с ними некоторые смартфоны будут принудительно использовать 20 МГц. Использование 20 МГц оправдано только в случае когда рядом есть несколько других сетей и вы с владельцами договорились, кто какой канал использует. Напомню, что в диапазоне 2.4 ГГц есть 3 непересекающиеся канала – 1, 6 и 11.

В то же время, для 5 ГГц Apple рекомендует смешанный режим 20/40/80 МГц.

Последнее замечание касается опции «Wi-Fi Multimedia» (WMM), которую следует всегда включать, для того, чтобы устройства Apple смогли корректно работать.

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

Если все же возникают проблемы с постоянными отключениями, для начала попробуйте посмотреть логи Wi-Fi. Если логи по каким-либо причинам отключены, загляните System - Logging  и во вкладке Rules добавьте Topics: Wireless.

Mikrotik HotSpot и продукция Apple

Казалось бы, все настроено верно, но для корректной работы этого все еще не достаточно.

Во-первых, iOS (iPhone, iPad, MacBook) при проверке доступности сети Интернет, проверяет доступ к своим ресурсам. В частности, осуществляется проверка доступа к странице

www.apple.com/library/test/success.html

 

которая должна отдавать успешный ответ:

<HTML>
<HEAD>
<TITLE>Success</TITLE>
</HEAD>
<BODY>
Success
</BODY>
</HTML>

Во-вторых, необходимо следить за тем, чтобы на роутере было правильно настроено время, оптимально для этих целей использовать встроенный в RouterOS клиент NTP.

На официальном форуме представители Mikrotik (в частности normis) неоднократно заявляли о том, что HotSpot должен корректно работать с Apple, даже . настройками по-умолчанию.

Одно из условий – корректный валидный DNS для хотспота. С адресами типа *.local (например, hotspot.local) могут быть проблемы, вместо них следует использовать корректные *.com / *.info и т.д. Некоторым пользователям помогает смена DNS-имени хотспота на *.pt (например, на hotspot.pt). Не путайте DNS-имя роутера с именем хотспота, подсети разные, DNS также разные. Вообще, использовать DNS-имя не обязательно, в этом случае стартовая страница будет загружаться по IP.

Меняется DNS-имя в профиле хотспота, например:

/ip hotspot profile

add dns-name=hotspot.ua hotspot-address=10.0.0.1 login-by=http-chap,trial name=free_wifi_moloko trial-uptime-limit=3h trial-uptime-reset=3m

Что дальше?

Дальше необходимо предоставить устройствам Apple доступ к своим ресурсам без авторизации на гостевом портале.

Делается это в подменю:

/ip hotspot walled-garden

Подбор узлов делается методом «научного тыка», в сети вы можете найти следующие варианты:

add dst-host=*.apple.com
add dst-host=*.apple.com.edgekey.net
add dst-host=*.akamaiedge.net
add dst-host=*.akamaitechnologies.com
add dst-host=apple.com
add dst-host=airport.us
add dst-host=itools.info
add dst-host=appleiphonecell.com
add dst-host=captive.apple.com
add dst-host=thinkdifferent.us
add dst-host=ibook.info

Официального комментария Apple по этому поводу нет. Для того, чтобы HotSpot корректно работал с Android, достаточно того, чтобы хотспот не пускал клиента на домен clients3.google.com (по ссылке clients3.google.com/generate_204 либо https://www.google.com/blank.html), а т.к. хотспот по-умолчанию блокирует всё, то и данный домен тоже блокируется и проблем не возникает.

В случае с Apple все сложнее. Исходя из имеющейся информации, роутер должен резолвить и открывать для клиента http://www.apple.com, но при этом блокировать доступ к странице http://www.apple.com/library/test/success.html (источник на stackoverflow). В противном случае, iOS-клиент получит ответ «Success», т.е. «есть открытый доступ к Интернет».

По фен-шую, блокировать необходимо доступ только для User-Agent «CaptiveNetworkSupport/1.0 wispr». Усложнять не будем, запретим для всех:

/ip hotspot walled-garden

add action=deny dst-host=^apple.com path=/library/test/success.html

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

Соответственно, для конфигурация HotSpot без показа страницы входа, должно быть правило, которое наоборот, разрешает доступ к странице /library/test/success.html

Сделать это можно как одним правилом, так и двумя (для параноиков):

/ip hotspot walled-garden

add dst-host=www.apple.com dst-port=80 path=/library/test/success.html

add dst-host=www.apple.com dst-port=443 path=/library/test/success.html

В заключение

На тестовой конфигурации я пробовал самые разнообразные вариации и, в конечном итоге, так и не понял до конца механизм проверки Apple. Исходя из сотен пересмотренных страниц на зарубежных форумах, все предлагают для Apple разрешать доступ к /library/test/success.html, однако в тех же ветках люди пишут «не помогает». Так что пробуйте, тестируйте, если у кого есть умные мысли по этому поводу – пишите в комментарии.
И да, если вы думаете, что проблема есть только у Mikrotik - вы ошибаетесь, в UniFi также есть проблемы, и только у iPhone, причем баг подтвержен официально, единого решения нет.
Скажу даже больше, я общался по этому поводу c @AppleSupport, но никакой стоящей информации по этому поводу так и не получил. Поддержка дает ссылки на стандартную документацию iOS, в которой, конечно же, ничего этого нету. Предложили обращаться в техподдержку, а там надо быть владельцем продукции Apple. Вообще не думаю, что там чем-либо помогут, если бы они сами знали в чем дело, проблемы на Mikrotik и Ubiquiti уже давно были бы устранены.

Справочная информация по теме

1. Использование сетей Wi-Fi, требующих предварительной аутентификации, на устройстве iPhone, iPad или iPod touch
2. iOS Deployment Reference
3. Manual:IP/Hotspot

Дополнено 24 марта 2018

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

Что же мы имеем в дополнение к вышеописанному? У продукции Apple встречаются проблемы не только с HotSpot, но и вообще много проблем при работе с беспроводными сетями:

• Apple признали наличие проблем с подключением у iPhone 5. Путь решения – использование менее надежного TKIP. И тут не совсем понятно, то ли это проблема аппаратная и, следовательно, не лечится; либо программная, соответственно должна была быть устранена с обновлением iOS;
• В настройках AP следует принудительно выставлять wireless-protocol=802.11 вместо значения «any». Тут все просто, nstreme и NV2 «умеют» только устройства Mikrotik;
• В названии SSID необходимо использовать только большие латинские буквы, цифры и/или дефис (например, FREE-WIFI), прочие спецсимволы могут вызывать проблемы. Как сообщается, в некоторых драйверах Apple имеются ошибки (баги), приводящие к нестабильной работе. Конечно, ошибки в драйверах уже могли быть исправлены, но вы не застрахованы от наличия клиента со старой версией ПО;
• Используйте «Default data rates», поскольку некоторые устройства не поддерживают форсированные скорости. Вообще, в целях оптимизации пропускной способности, опытные администраторы могут отключать часть скоростей. По этому поводу не так давно я даже переводил официальную документацию Ubiquiti для UniFi. 
• Значение преамбулы следует выбирать «любое» (preamble-mode=both), потому как некоторые устройства Apple с чипами Broadcom могут иметь проблемы с подключением. По сути, преамбула это короткая служебная информация в кадрах, чем она больше, тем меньше скорость. Современные устройства используют короткую преамбулу (400 нс), именно для неё и указываются стандартные канальные скорости. Зависимости скоростей от преамбулы можно посмотреть в справочном разделе по канальным скоростям 802.11. Старые устройства используют длинную преамбулу, отключая её вы создаете проблемы с подключением;
• Специалисты Ветрикса рекомендуют отключать WMM, если ваши устройства часто теряют сеть и переподключаются;
• Не используйте опции оптимизаций, такие как hw-protection-mode=rts-cts и adaptive-noise-immunity=ap-and-client-mode, потому как не все устройства их поддерживают. Если коротко, данные опции помогают бороться с шумом, а также согласовывать работу клиентов A и B, которые видят AP, но не видят друг друга (отсутствие согласования).
• Используйте management-protection=disabled, т.к. не все устройства поддерживают эти режимы.

Дополнено 25 марта 2018

Последующие поиски гарантированно рабочего решения привели меня к публикации «How to disable macOS’s hotspot login float-over window». В данной публикации описан метод обхода всплывающих окон для входа. В частности нас интересует следующее:

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

На сегодня нигде нет ответа, достаточно Apple ответа HTTP 200 (OK), или же проверяется ключевое слово «success».

Ранее я уже упоминал страницу

http://www.apple.com/library/test/success.html

Однако начиная с OS X Maverick, конечный URL был изменент, теперь система пытается открыть:

http://captive.apple.com/hotspot-detect.html

Данный URL отдает страницу с Success:

<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>

Если данное утверждение верно, Wallen Garden должен иметь примерно следующий вид:

/ip hotspot walled-garden

add action=deny comment="APPLE DENY" dst-host=www.apple.com path=/library/test/success.html
add action=deny dst-host=apple.com path=/library/test/success.html
add action=deny dst-host=captive.apple.com path=/hotspot-detect.html

add comment="APPLE ALLOW" dst-host=*.apple.com
add dst-host=*.apple.com.edgekey.net
add dst-host=*.akamaiedge.net
add dst-host=*.akamaitechnologies.com
add dst-host=apple.com
add dst-host=airport.us
add dst-host=itools.info
add dst-host=appleiphonecell.com
add dst-host=captive.apple.com
add dst-host=thinkdifferent.us
add dst-host=ibook.info

Дополнено 26 марта 2018

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

Первое. iOS действительно пытается открыть целевой «Probe URL». Если системе удается открыть целевой URL, и она находит там правильное содержимое (например, «Success») – сеть считается «открытой», т.е. такой, которая не ограничена и не требует авторизации. Если же на целевой странице отображается не то, что ожидает система – сеть признается HotSpot, выполняется переадресация на Captive Portal.

Второе. Для корректной работы Captive Portal обязательно использовать DNS-имя, т.к. при использовании только IP, сеть будет признана локальной.

Разные ОС использую разные механизмы, Android-устройства и Chromebook обращаются к

clients3.google.com

iOS 6 пытается зайти на:

gsp1.apple.com
*.akamaitechnologies.com

iOS 7 пытается зайти на:

www.appleiphonecell.com
www.airport.us
*.apple.com.edgekey.net
*.akamaiedge.net
*.akamaitechnologies.com

Для более поздних iOS 8/9 используются страницы:

http://www.apple.com/library/test/success.html
http://captive.apple.com/hotspot-detect.html

Windows обращается к:

ipv6.msftncsi.com
www.msftncsi.com

Проверочная страница Amazon Kindle (Fire)

http://spectrum.s3.amazonaws.com/kindle-wifi/wifistub.html

И все бы хорошо, но… начиная с версии iOS 8.4, система делает запрос не только к

http://captive.apple.com

Но также к другим, динамически генерируемым страницам вида:

/fVfbcvcnbv/8Gfdfvb7.html
/NnB7bbvvvkfv77/fdjcv85gHFv/dfnb67f7.html

При этом обращения идут к следующим доменам:

http://captive.apple.com
http://www.ibook.info
http://www.itools.info
http://www.thinkdifferent.us

Судя по всему, во всех случаях запросы поступают с указанием User Agent «CaptiveNetworkSupport».

Предположения касательно «проблем» Apple

Вы, как и я, наверное, задаетесь вопросом «что за хрень здесь происходит?». Собственно у меня сложилось некое мнение, объясняющее происходящее. Все мы с вами знаем, как Apple и американцы относится к безопасности. Открытые сети HotSpot открывают потенциальным злоумышленникам новые возможности, как-минимум, возможность перехвата данных и кража личной информации. Именно по этой причине в публичных сетях следует всегда использовать только HTTPS.

Так вот, обычные сети HotSpot, как правило, не имеют пароля, следовательно, сеть не использует шифрование AES, как следствие, к сети имеет доступ кто угодно. Возможно, при активации WPA2+AES, проблема с устройствами Apple исчезнет, но это лишь предположение, требующее проверки на практике.

Во-вторых, принудительно пользователю можно подсунуть страницу на гостевом портале с вредоносным кодом. От этого не застрахован никто, более того, станица может быть фишинговой. Есть у меня предположение, что при условии использования действительного SSL-сертификата («зеленого», на который не ругается браузер), проблемы также не будет. Но опять же, это лишь мое предположение.

Дополнено 27 марта 2018

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

Дело в том, что пользователи могут использовать альтернативные DNS, например на MacBook. К примеру, те же сервисы Google DNS 8.8.8.8 и 8.8.4.4.

Как не сложно догадаться, при использовании сторонних DNS, пользовательское устройство не будет резолвить DNS-имя для локального HotSpota.

Как быть? Все достаточно просто, перенаправляем все пользовательские DNS-запросы на локальный DNS Mikroik’a. Для этого создаем правило вида:

/ip firewall nat

add action=dst-nat chain=dstnat comment="Redirect users DNS" dst-port=53 in-interface=bridge-free-wifi log=yes log-prefix=DNS_REDIRECT protocol=udp src-address=10.10.10.0/24 to-addresses=10.10.10.1 to-ports=53

add action=dst-nat chain=dstnat dst-port=53 in-interface=bridge-free-wifi log=yes log-prefix=DNS_REDIRECT protocol=tcp src-address=10.10.10.0/24 to-addresses=10.10.10.1 to-ports=53

Почему правило настолько большое? Лично я использую связку HotSpot и гостевой сети на отдельном Bridge. Наличие бриджа позволяет легко добавлять в него новые интерфейсы (порты) и дополнительно использовать CAPsMAN с точками доступа. Это одна из альтернатив использованию VLAN при добавлении дополнительных точек доступа.

bridge-free-wifi – мой локальный бридж, в котором работает HotSpot (в остальных случаях можно использовать wan2 или другой интерфейс, на котором у вас запущен HotSpot);

10.10.10.0/24 – локальная сеть HotSpot;

10.10.10.1 – IP HotSpot;

Наиболее простой вид правила:

chain=dstnat action=redirect to-ports=53 protocol=udp in-interface=Bridge src-port=53

Данное правило будет редиректить все DNS-запросы от любых адресов, Bridge здесь указан для того, чтобы не «выворачивать» 53-й порт наружу. Вообще, лично я всегда добавляю в Firewall правила, запрещающие доступ к DNS через WAN-интерфейс:

/ip firewall filter

add action=drop chain=input comment="DROP access to DNS from WAN (Internet)" dst-port=53 in-interface=ether1-gateway protocol=tcp

add action=drop chain=input dst-port=53 in-interface=ether1-gateway protocol=udp

Также есть конфигурации, при которых Mikrotik настроен в режиме моста (Bridge), в такой конфигурации правила не работают, для того, чтобы они заработали, в бридже необходимо активировать использование Firewall:

/interface bridge settings set use-ip-firewall=yes

Собственно после добавления нужных правил, пользователи больше не смогут использовать свои DNS-серверы (за исключением тех случаев, когда пользователь дополнительно использует VPN).

Видеокурс «Настройка оборудования MikroTik» (аналог MTCNA)

Учитесь работать с MikroTik? Рекомендую видеокурс «Настройка оборудования MikroTik». В курсе разобраны все темы из официальной учебной программы MTCNA и много дополнительного материала. Курс сочетает теоретическую часть и практику – настройку маршрутизатора по техническому заданию. Консультации по заданиям курса ведет его автор Дмитрий Скоромнов. Подойдет и для первого знакомства с оборудованием MikroTik, и для систематизации знаний опытным специалистам.