+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

HTTPS URL-адреса не работают в гостевой сети с ограниченным доступом (walled garden).

HTTPS URL-адреса не работают в гостевой сети с ограниченным доступом (walled garden)., RouterOS

vikas565

Guest

09.04.2015 14:36:00

Нужна помощь с настройкой Mikrotik hotspot. Для схемы сценария см. приложенный файл. Я подключаю роутер Mikrotik к Antamedia Hotspot, который выступает в роли RADIUS-сервера для роутера Mikrotik. Всё работает нормально, кроме walled garden на роутере Mikrotik. Я добавил несколько URL в walled garden Mikrotik. Некоторые из них основаны на HTTP, некоторые — на HTTPS. Например: http://www.abc.com (работает по HTTP) и http://www.xyz.com (работает по HTTPS). Оба URL должны работать без перехода через hotspot (то есть без аутентификации через RADIUS), так как они добавлены в walled garden Mikrotik, но http://www.abc.com работает, а http://www.xyz.com — нет. Я проверял разные URL и выяснил, что URL с протоколом HTTPS не работают. В чём может быть проблема? Помогите, пожалуйста. nw hotspot.JPG

ivanfm

Guest

30.09.2016 22:18:00

Я обнаружил эту проблему в своих тестах с версиями 6.36 и 6.37. Вот что я выяснил (заменил оригинальные домены):

http://www.xyz.com работает,
https://www.xyz.com не работает,

в walled garden есть хост www.xyz.com с разрешённым доступом. В данный момент www.xyz.com не является A-записью в DNS, а CNAME-записью.
www.xyz.com — CNAME на www.kkk.com.

Когда я добавляю www.kkk.com в walled garden, доступ через https становится возможен. Также я заметил, что количество обращений в walled garden учитывается не по www.xyz.com, а только по конечной CNAME-записи www.kkk.com.

По моему мнению, когда пользователь запрашивает www.xyz.com, система DNS хотспота должна проверять именно первое имя, а не только последнее. Похоже, что это ошибка в системе хотспота.

ZeroByte

Guest

30.09.2016 23:23:00

Это не имеет значения для CNAME-записей. Причина проста: https зашифрован, поэтому хотспот не может отслеживать захватываемые URL — именно поэтому SSL требует контроля «walled garden» на основе IP-адреса. Если введённое имя — это CNAME (а не A-запись), это не важно — в итоге оно должно указывать на IP-адрес, и блокируется именно IP, а не имя. Пока заблокированный CNAME указывает на что-то, что в свою очередь ведёт к тому же IP-адресу, блокировка сработает.

Проблема с CNAME в том, что IP блокируется вне зависимости от того, под каким именем к нему обращаются. Представьте: bad.com → web.hosting.com и good.com → web.hosting.com. В этом случае Walled Garden заблокирует IP web.hosting.com. Так что даже если вы хотите разрешить good.com, но заблокировать bad.com — сделать это по IP невозможно, потому что оба имени разрешаются в один и тот же IP. И это не зависит от того, является ли RR CNAME или A-записью.

Есть ещё причины, по которым это может не работать полностью, но они не напрямую связаны с CNAME. Если у сайта DNS использует глобальный баланс нагрузки или другие сложные механизмы, когда разные запросы получают разные ответы в зависимости от каких-то параметров, тогда запрос пользователя к bad.com может получить другой IP, чем тот, который получил Mikrotik при своём запросе.

Чтобы избежать такой ситуации, нужно заставить пользователей использовать Mikrotik как DNS-сервер (либо прописав его напрямую в DHCP, либо прозрачным перенаправлением DNS-запросов на Mikrotik с помощью DSTNAT). Тогда у всех будет одинаковое представление о DNS, на основе которого строится политика блокировки по IP.

ivanfm

Guest

15.10.2016 19:22:00

Понимаю, что Mikrotik не может заглянуть внутрь пакетов, чтобы увидеть реальный адрес назначения по заголовку Host. Но в коде hotspot можно добавить опцию, которая будет проверять DNS-разрешения (да, все DNS-запросы обрабатываются самим Mikrotik), и если в walled garden есть разрешение для имени, то можно проследить всю цепочку разрешений и считать IP разрешённым.

name1 CNAME name2
name2 A 4.3.2.1

Если name1 находится в walled garden как разрешённый, и был разрешён DNS-сервером Mikrotik hotspot, то IP 4.3.2.1 тоже можно считать разрешённым. Конечно, если плохой сайт указывает на тот же IP (прямо или через cname), то пользователь сможет попасть на плохой сайт. Но это сейчас возможно только в случаях, когда сайты используют прямой A-запись и соединение происходит по https.

www.good.com A 1.2.3.4
www.bad.com A 1.2.3.4

Вы правильно заметили про балансировку, но если DNS hotspot проверяет разрешения, то IP будет очищен и разрешён в walled garden.

ZeroByte Guest	#5 0 21.10.2016 14:07:00 Если два имени с разными правилами разрешаются в один и тот же IP, то что, по твоему, должен сделать Mikrotik?

agnostic Guest	#6 0 21.10.2016 14:15:00 У тебя включен HTTPS для входа в хотспот? Кроме того, нужно сначала создать самоподписанный сертификат. Попробуй проверить, работает ли это.

ivanfm Guest	#7 0 22.10.2016 01:48:00 Учитывая, что проверка соединения происходит внутри https, это должно разрешать оба имени, потому что IP-адрес разрешён.

eduardomazolini

Guest

20.02.2017 12:43:00

Возможно, именно так и происходит, но это не лучший способ. Возможно, поэтому у меня несколько доменов Google были неправильно выпущены. Сегодня HTTPS-запросы используют TLS, а браузеры поддерживают SNI — при этом отправляется имя сервера. https://en.wikipedia.org/wiki/Server_Name_Indication Можете ли вы подтвердить эту информацию по Mikrotik? Можно ли отключить разрешение DNS и использовать только SNI?

ivanfm Guest	#9 0 20.02.2017 15:43:00 Проблема в том, что имя SNI приходит после установления TCP-соединения.

eduardomazolini Guest	#10 0 20.02.2017 16:25:00 Хорошо, но только на первых байтах. При первой отправке пакета. Отправлено с моего SM-G800H с помощью Tapatalk

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры