Hotspot для самых маленьких, часть 3: https и shaping

Мы продложаем настраивать свой модный hotspot, на котором сможем заработать много-много денег. Мы уже знаем, как открыть доступ для авторизации через соцсети и переправлять пользователей на нашу красивую welcome page.

Но появилась одна проблема: соцсети доступны клиентам без авторизации! Практически полностью! Что сильно снижает полезность хотспота, даже если приглашение стартует автоматически. Как с этим бороться?
Например, включить режим обнаружения https: тогда мы сможем фильтровать в т.ч. https-урлы (с определенными ограничениями, разумеется).
До кучи, разберемся как ограничивать скорость пользователям (чтобы не было соблазна качать торренты).

Разбираемся с HTTPS

Как известно, “посмотреть” https-url без раскрытия сертификата (т.е. по сути его подмены) нельзя. Но мы можем посмотреть имя хоста – т.н. SNI. Это уже лучше – во-первых, можно делать редирект с https-сайтов на наш login page, а во-вторых, более точно блокировать узлы социальных сетей, оставляя только те, что нужны для авторизации (помните, сколько всего мы открывали для Intagram?).

Для начала нам понадобится ssl-сертификат. Можно его купить, можно взять на startssl или воспользоваться letsencrypt – выбор за вами. Не советую только использовать самоподписанные сертификаты – пользователи не любят грозных предупреждений браузера о том, что сертификат подписан невалидным CA, например.

Закидываем на микротик свой публичный ключ (сертификат), приватный ключ и т.н. chain – цепочку сертификатов, которая нужна для связки нашего сертификата с одним из доверенных корневых центров сертификации.

/certificate import file-name=cert1.pem passphrase=""
/certificate import file-name=privkey1.pem passphrase=""
/certificate import file-name=chain1.pem passphrase=""

После этого наш сертификат можно посмотреть в /certificates print, например вот так:

[admin@snake-mikrotik] > /certificate print
Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted
# NAME COMMON-NAME SUBJECT-ALT-NAME FINGERPRINT
...
4 K T cert_12 wifi.nixman.info DNS:wifi.nixman.info 8dad2198edb12af14e46303cc3284d2ec50c01512992...
5 L T cert_13 Let's Encrypt Authority X1 7fdce3bf4103c2684b3adbb5792884bd45c75094c217...

cert_12 – это наш сертификат (публичный+приватный ключи)
cert_13 – это chain, который подтверждает подлинность нашего сертификата

Теперь надо включить www-ssl сервис, а также включить поддержку ssl в hotspot’e:

/ip service set [ find name=www-ssl ] certificate=cert_12 disabled=no
/ip hotspot profile set [ find name=hs-profile-nixman ] login-by=https ssl-certificate=cert_12

Теперь, можете убедиться сами, https-урлы успешно перехватываются (разумеется, их необходимо указать в walled-garden). Есть только один нюанс. Если сайт использует HSTS (например, Google и его сервисы), то пользователь все равно получит security exception. И сделать с этим ничего нельзя (ну, только если вы не умеете подменять ssl-сертификаты на лету… но тогда зачем вы здесь?).

Таблетка от жадности

Теперь поговорим об ограничении пользователей. Публичные хотспоты редко делают на нормальном оборудовании, выдерживающим большие нагрузки – все-таки услуга предоставляется бесплатно (или почти бесплатно) и вкладывать в нее много денег захочет далеко не каждый. С другой стороны – пользователям необходимо обеспечить комфортные условия для листания вконтактиков и инстаграмов, иначе никто не захочет пользоваться вашим замечательным и сто раз разрекламированным хотспотом.
Какой выход? Шейпить. Т.е. выделять на каждого подключившегося не больше определенной полосы, чтобы всем хватило.
Если вы – оператор, то, наверняка, у вас есть такие замечательные вещи как BRAS, RADIUS-сервер и биллинг, которые вам сделают “красиво”. Ну а мы маленькие, у нас ничего такого нет. Только микротик.
Но жизнь себе мы все равно облегчим.

Выглядеть ограничение будет примерно так:

[admin@snake-mikrotik] > /ip hotspot user profile print
Flags: * - default
0 * name="default" session-timeout=1d idle-timeout=none keepalive-timeout=2m status-autorefresh=1m shared-users=20 add-mac-cookie=yes mac-cookie-timeout=3d queue-type=hotspot-default rate-limit="24k/128k 32k/256k 24k/196k 30/30 8" address-list="" transparent-proxy=no

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

Поясню немного по “странным цифрам” (заметьте, то что для пользователя rx, для нас будет tx и наоборот):
1. Полоса (rate) в формате txrate/rxrate, у меня 24k/128k – собственно та скорость, которую мы выделяем пользователю.
2. Т.н. burst-полоса (burst-rate), т.е. грубо говоря “полоса для маленьких файлов” (у меня 32k/256k). Суть этого параметра в том, что в начале соединения пользователь получает бОльшую полосу, чем ему “положено”, что положительно влияет на веб-серфинг, но при этом отсекает большие закачки и торренты (они будут резаться по rate)
3. Порог срабатывания burst (24k/196k) – через какое количество байт burst-rate и пользователь будет шейпиться по rate
4. Burst Time (в секундах, у меня 60/60) – тоже самое, но ограничивает время с момента открытия новой сессии
5. Приоритет (целое в диапазоне 1-8). Если кратко – позволяет ранжировать несколько профилей по “классам обслуживания”. Чем выше приоритет, тем приоритетнее трафик.
6. Минимальная полоса (Minimum rate, у меня 32k/256k), которая обеспечивается клиенту (при загруженном канале, например).

После этого очедери можно будет посмотреть в queue simple:

[admin@snake-mikrotik] > /queue simple print
Flags: X - disabled, I - invalid, D - dynamic
0 D name="" target=10.1.3.254/32 parent=none packet-marks="" priority=8/8 queue=hotspot-default/hotspot-default limit-at=24k/128k max-limit=24k/128k burst-limit=32k/256k burst-threshold=24k/196k burst-time=30s/30s

1 D name="hs-" target=hs-ap-nixman parent=none packet-marks="" priority=8/8 queue=hotspot-default/hotspot-default limit-at=0/0 max-limit=0/0 burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s

Здесь под номером 0 – клиент, а под номером 1 – очередь, применяемая на весь хотспот (можно, например, ограничить по полосе пользователей хотспота в целом, чтобы они не сильно забивали канал провайдера.

Вот и все!
Теперь вы можете доработать свой хотспот, и сделать его еще более дружелюбным и полезным для пользователей!

16 Comments

  1. Способ с SSL – шикарен! Спасибо огромное!
    Только проблемы с facebook это не решает, т.к. у них нет отдельного имени для API и авторизации. Все крутится на facebook.com. Решением этой проблемы еще не занимались?

    1. Всё верно, не решает. И вряд ли получится решить, потому что url без подмены сертификата разобрать нельзя. А подменить сертификат на устройстве пользователя никто не даст 🙁

  2. В общем, ебаный wifi меня совсем достал, чтоб они сдохли все! А теперь собственно вопрос – гавностраница авторизации открывается ведь по ссылке вида ip~прочий бред, тогда почему сертификат нужно получать на поддомен/домен?
    Или же страница будет в вебе, и сайт добавлен в валлен гарден (садик), и только в этом случае?

    1. Добрый день.
      Если вы в настройках хотспота укажете dns-name, то страница приветствия будет открываться с “человеческим” хостнеймом. Вот на этот dns-name и нужно получить сертификат.
      В WG нужно будет добавить сайт, на который вы будете делать переадресацию в случае если WP у вас располагаться на отдельном сервере.

  3. Я правильно понимаю, что при переходе неавторизованного пользователя по https, например на https://fb.com – он все равно будет получать сообщение о том что сертификат не соответствует домену на который пытается перейти пользователь?

  4. ПОдскажите, что я делаю не так?
    Не устанавливается ограничение скорости по пользователям.

    Ставлю 5м/5м

    > /ip hotspot user profile export
    # nov/15/2016 13:43:52 by RouterOS 6.37.1
    # software id = DHGM-YKFD
    #
    /ip hotspot user profile
    set [ find default=yes ] insert-queue-before=bottom open-status-page=http-login rate-limit=5M/5M transparent-proxy=yes

    а в очередь все равно добавляется этот юзер с ограничением 100m/100m

    > /queue simple print
    Flags: X – disabled, I – invalid, D – dynamic
    …..
    1 D name=”” target=192.168.106.245/32 parent=none packet-marks=”” priority=8/8 queue=default-small/default-small
    limit-at=100M/100M max-limit=100M/100M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1

    1. Для начала могу предложить сменить версию routeros. Если есть возможность – проверить на другом устройстве.

    1. Да, проблема довольно актульная.
      Кроме как через Ansible пока не знаю, как это автоматизировать. Думаю, на праздниках как раз будет время попробовать и написать.

  5. Извините, что-то делаю не так, не подскажете в чем может быть дело.
    На удаленном VPS установил lets encrypt и успешно получил на домен mydomain.tk сертификат командой ./letsencrypt-auto certonly –standalone -d mydomain.tk. С папки /etc/letsencrypt/live/mydomain.tk скопировал cert.pem,chain.pem,privkey.pem и импортировал в микротик, в сертификатах KT cert.pem_0 C=US,O=Lets Encrypt,CN=Lets Encryp authority X3 LT chain.pem O=digital signature Trust Co, CN=DST Root CA X3. Ip/services/www-ssl выставил cert.pem_o, также выставил /hotspot/server profiles/https. Но браузер смартфона также ругается при перенаправлении на https.
    Я подозреваю что просто взять готовый сертификат и перенести его в хотспот микротика не сработает верно? Надо еще что то сделать?

    1. Должен признать, что указанный мной способ выдает security exception в 100% случаев. Увы, но такова специфика работы протокола https.
      Сертификат на микротике можно использовать любой, главное, чтобы домен, для которого он выдан, был прописан как адрес хотспота (иначе толку от сертификата нет). Так же https вам понадобится при настройке авторизации через соцсети (некоторые из них работают строго по https, а при наличии редиректов с https на http и наличии смешанного содержимого возможна ругань браузеров, особенно на мобильных устройствах.

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

  7. Здравствуйте! Вопрос такой, можно ли получить нормальный (не самоподписанный) сертификат для прокси, который работает в локалке? Сейчас самоподписанный, но некоторые девайсы не позволяют импортировать к себе такой сертификат.

    1. Добрый день.
      Можно, но только если ваш прокси, работающий в локалке, имеет валидное доменное имя вида proxy.tld, которое можно разрезолвить из интернета.
      При этом, если вас устроит обновлять сертификат от того же LE руками раз в три месяца, то даже не нужно поднимать на этом прокси web-сервер для проверки домена.

Leave a Reply