Автоматическая авторизация MikroTik на точке доступа: скрипт входа в captive portal из терминала

• Шаг 1: подключи MikroTik к AP в режиме station и получи адрес по DHCP.
• Шаг 2: в DevTools браузера сними URL и поля формы входа портала.
• Шаг 3: положи POST-запрос в скрипт cp-login через /tool fetch.
• Шаг 4: скрипт cp-check по расписанию ловит портал и запускает вход заново.

Диагноз: MikroTik подключился к Wi-Fi, а интернета нет

Автоматическая авторизация MikroTik на точке доступа нужна в одном сценарии. Поднял роутер клиентом к чужому Wi-Fi. Зелёный статус, адрес получен, шлюз пингуется. А сайты не открываются. Знакомо?

По факту ты упёрся в captive portal. Точка доступа пустила тебя в сеть, но интернет отдаст только после того, как кто-то введёт логин на веб-странице. Ноутбук открывает эту страницу сам. Роутер браузера не имеет, поэтому просто сидит без интернета и молчит.

Второй вариант того же диагноза: вход ты сделал руками с ноутбука за MikroTik, всё работало три дня, а потом сессия истекла. Или отель перезагрузил контроллер ночью. Или твой роутер моргнул питанием. И снова кто-то идёт с ноутбуком жать «Войти». Для объекта, где стоит камера, датчик или терминал без людей рядом, это не вариант.

Что получишь на выходе. Роутер сам поймёт что его заперли за порталом, сам отправит форму входа и сам повторит это после перезагрузки. В логе будет видно когда и почему он логинился.

Сразу договоримся о терминах, чтобы не путаться. MikroTik-клиент — твой роутер, который цепляется к чужому Wi-Fi. Чужая AP — точка доступа отеля, бизнес-центра или провайдера. Рабочая станция — ноутбук с браузером, на нём ты разбираешь форму входа. Над каждым блоком кода написано где его выполнять. Не перепутай, от этого зависит половина успеха.

В статье разберём:

• почему MikroTik не проходит веб-авторизацию сам и что ему мешает;
• как вытащить из браузера точный запрос формы входа;
• скрипты cp-login и cp-check для RouterOS 7 с логами и защитой от ошибок;
• порталы с токенами, MAC-адресом и cookie в запросе;
• WPA2-Enterprise как альтернатива веб-входу, где скрипт вообще не нужен;
• безопасность роутера, который торчит в чужую сеть;
• troubleshooting по частым ошибкам fetch и FAQ.

Как устроена схема

Смотри на картинку прежде чем лезть в терминал. Весь фокус в том, что роутер делает ровно то же, что делает браузер при нажатии кнопки «Войти», просто без браузера.

Синее — твоя сторона. Оранжевое — чужая инфраструктура, на которую ты не влияешь. Зелёное — то, что мы сегодня построим. Портал видит MAC и IP именно твоего MikroTik, поэтому после входа интернет получают все клиенты LAN за NAT.

Почему MikroTik не проходит авторизацию на точке доступа сам

Причин несколько, и они наслаиваются. Разберём каждую, потому что от неё зависит какой вариант решения тебе подойдёт.

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

Последняя строка отсекает часть порталов сразу. Если форма считает MD5 от пароля в браузере через JavaScript, как это делает, например, MikroTik Hotspot в режиме CHAP, то голым POST ты не войдёшь. Такое тоже разберём в осложнениях.

Отдельно про WPA2-Enterprise. Если при подключении к сети ноутбук спрашивает логин и пароль в системном окне Windows, а не на веб-странице, то это 802.1X, и весь блок про fetch тебе не нужен. Прыгай сразу в раздел про альтернативы, там три команды.

Как отличить тип авторизации за минуту

Подключись к сети с ноутбука и посмотри что происходит. Это главный развилочный вопрос всей статьи.

Рецепт: настройка автоматической авторизации MikroTik через /tool fetch

Системные требования

На момент публикации актуальна стабильная ветка RouterOS 7.23.x и long-term 7.21.x по данным endoflife.date. Перед установкой проверь свежие релизы на mikrotik.com/download.

Таблица портов

Роутер будет ходить наружу только по HTTP и HTTPS. Входящие соединения со стороны чужой AP нам не нужны вообще, и ниже мы их закроем.

Подготовка

Проверь три вещи до того как что-то настраивать. Первое — версию RouterOS и какой Wi-Fi пакет стоит. От этого зависит синтаксис команд на следующем шаге.

Где выполнять: терминал MikroTik-клиента.

/system resource print
/system package print
/interface print where type~"wlan|wifi"

Результат: в первой команде смотри строку version. Во второй ищи пакет wireless или wifi-qcom, wifi-qcom-ac. В третьей увидишь имя интерфейса: wlan1 для пакета wireless, wifi1 для пакета wifi. Дальше я пишу wlan1, если у тебя wifi1 — просто подставь.

Второе — доступ. Тебе нужен пользователь с группой full, потому что скрипты мы будем создавать с политиками read, write, test. Третье — учётка от портала. Проверь её руками с телефона. Если с телефона войти не получилось, скрипт тоже не войдёт, и это сэкономит тебе час.

Шаг 1. Сделай бэкап текущего конфига

Зачем: мы будем менять режим Wi-Fi интерфейса. Если роутер сейчас раздаёт Wi-Fi клиентам, после перевода в station раздача пропадёт. Откат должен занимать одну команду, а не полчаса вспоминаний.

Где выполнять: терминал MikroTik-клиента.

/export show-sensitive file=before-cp-login
/system backup save name=before-cp-login password=ПридумайПароль
/file print where name~"before-cp-login"

Результат: в списке файлов два файла, before-cp-login.rsc и before-cp-login.backup. В RouterOS 7 export по умолчанию прячет пароли, поэтому параметр show-sensitive обязателен, иначе в экспорте не будет ни Wi-Fi ключей, ни паролей пользователей. Скачай оба файла на рабочую станцию через WinBox, раздел Files. Бэкап на самом роутере — это не бэкап, это надежда.

Шаг 2. Переведи Wi-Fi в режим station

Зачем: чтобы MikroTik стал клиентом чужой точки, как ноутбук. Для одного радиомодуля это значит, что раздавать Wi-Fi со своего роутера на этом же радио ты не сможешь. Для раздачи нужен второй модуль или проводной LAN.

Вариант для пакета wireless, открытая сеть с порталом.

Где выполнять: терминал MikroTik-клиента.

/interface wireless security-profiles add name=cp-open mode=none
/interface wireless set wlan1 mode=station ssid="Hotel_WiFi" security-profile=cp-open frequency-mode=superchannel disabled=no

Если сеть с паролем WPA2 плюс портал, профиль делаешь с ключом:

/interface wireless security-profiles add name=cp-psk mode=dynamic-keys authentication-types=wpa2-psk wpa2-pre-shared-key="ПарольОтСети"
/interface wireless set wlan1 mode=station ssid="Hotel_WiFi" security-profile=cp-psk disabled=no

Вариант для пакета wifi на RouterOS 7:

/interface wifi set wifi1 configuration.mode=station configuration.ssid="Hotel_WiFi" disabled=no

Для сети с паролем добавь в ту же команду параметры security.authentication-types=wpa2-psk и security.passphrase=»ПарольОтСети».

Результат: интерфейс должен получить флаг R, running. Проверь регистрацию:

/interface wireless registration-table print
/interface wifi registration-table print

Выполняй ту команду, которая соответствует твоему пакету. В выводе должна быть одна строка с MAC чужой точки и уровнем сигнала. Сигнал хуже минус 75 dBm — это будущие проблемы с перелогинами, лучше сразу подумать про внешнюю антенну или другое место установки.

Про superchannel: на пакете wireless этот режим снимает ограничения по регуляторике и частотам. В России по закону надо ставить frequency-mode=regulatory-domain и country=russia. Я оставил superchannel для первой диагностики, когда точка не находится вообще. Когда связь поднялась — верни regulatory-domain.

Шаг 3. Подними DHCP-клиент, NAT и список WAN

Зачем: чужая сеть выдаст адрес по DHCP. Маршрут по умолчанию и DNS тоже придут от неё. NAT нужен, чтобы клиенты твоего LAN выходили в интернет через адрес роутера, ведь портал авторизует только его.

Где выполнять: терминал MikroTik-клиента.

/ip dhcp-client add interface=wlan1 use-peer-dns=yes add-default-route=yes default-route-distance=1 disabled=no comment="cp uplink"
/interface list member add list=WAN interface=wlan1
/ip firewall nat add chain=srcnat out-interface=wlan1 action=masquerade comment="cp uplink nat"

Если у тебя дефолтный конфиг с bridge и списком WAN, правило masquerade по out-interface-list=WAN уже есть, и третью команду можно пропустить. Проверь командой /ip firewall nat print, чтобы не плодить дубли.

Результат: проверь что адрес получен.

/ip dhcp-client print detail where interface=wlan1
/ip route print where dst-address=0.0.0.0/0
/ping 8.8.8.8 count=4

В dhcp-client статус bound, есть address и gateway. Маршрут по умолчанию через шлюз чужой сети. А вот пинг, скорее всего, не пройдёт или пройдёт странно. Многие порталы режут ICMP до входа, некоторые наоборот пропускают его и режут только HTTP. Поэтому пинг — плохой индикатор авторизации, и дальше мы будем проверять именно HTTP.

Шаг 4. Разбери форму входа портала на рабочей станции

Вот тут важно. Это главный шаг всей статьи, и на нём спотыкается большинство. Скрипт должен отправить ровно тот же запрос, что отправляет браузер. Не похожий, а тот же: тот же URL, тот же метод, те же имена полей.

Подключи ноутбук к той же чужой сети или к LAN за своим MikroTik. Открой любой HTTP-сайт, например http://neverssl.com. Портал перехватит запрос и покажет страницу входа.

Где выполнять: браузер на рабочей станции.

• Нажми F12, открой вкладку Network, поставь галку Preserve log.
• Введи логин и пароль в форме портала, нажми «Войти».
• В списке запросов найди первый запрос с методом POST, обычно он называется login, auth или logon.
• Открой его: во вкладке Headers смотри Request URL и Content-Type, во вкладке Payload смотри Form Data.
• Правой кнопкой на запросе выбери Copy, затем Copy as cURL. Сохрани это в блокнот.
• Посмотри исходник страницы входа через Ctrl+U и найди тег form и все input type=hidden.
• Выпиши что из этих полей меняется при повторной загрузке страницы, а что статично.

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

Где выполнять: это пример вывода с рабочей станции, запускать не нужно.

curl 'http://10.10.0.1/login' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Cookie: PHPSESSID=8f3c2a1b' \
  --data-raw 'username=room512&password=S3cret%40pw&dst=&popup=true'

Из него тебе нужно четыре вещи. Адрес, куда уходит форма: http://10.10.0.1/login. Метод: POST, раз есть data-raw. Тип контента: application/x-www-form-urlencoded. Тело: строка с полями через амперсанд. Cookie пока отложи, про него отдельный разговор в осложнениях.

Ещё одна проверка, которую делают единицы. Выполни этот cURL с рабочей станции в другой сети или после выхода из портала, но без cookie. Если вход прошёл без cookie — тебе повезло, скрипт будет в три строки. Если нет — портал держит сессию, и скрипт станет чуть сложнее.

Шаг 5. Закодируй спецсимволы в пароле

Зачем: тело формы кодируется по правилам URL. Если в пароле есть @, &, # или пробел, их нужно заменить на процентные коды. Браузер делает это сам, fetch нет. Непрокодированный амперсанд в пароле разорвёт строку на два поля, и портал увидит обрезанный пароль.

Проще всего взять значение прямо из Payload в DevTools, нажав view source. Там браузер показывает уже закодированную строку. Её и вставляешь в скрипт. Буквы, цифры, дефис, точку и подчёркивание кодировать не надо.

Отдельная ловушка RouterOS. Символ доллара внутри строки скрипта означает переменную. Если в закодированном пароле остался $, экранируй его обратным слешем. Знак вопроса при вставке в терминал вызывает подсказку, поэтому в URL с параметрами тоже пиши его как \?. После кодирования в процентах этих символов обычно не остаётся, что лишний раз говорит в пользу кодирования.

Шаг 6. Проверь вход одной командой из терминала

Зачем: прежде чем писать скрипт, убедись что сам запрос работает. Одна команда, один ответ. Если она не сработала, скрипт тоже не сработает, только ошибку будет сложнее найти.

Где выполнять: терминал MikroTik-клиента.

/tool fetch url="http://10.10.0.1/login" http-method=post http-header-field="Content-Type:application/x-www-form-urlencoded" http-data="username=room512&password=S3cret%40pw&dst=&popup=true" output=user

Результат: status finished и в поле data кусок HTML страницы портала. Часто там текст вида «You are logged in» или редирект на сайт отеля. Теперь проверь интернет:

/tool fetch url="http://detectportal.firefox.com/success.txt" output=user

Если в data пришло слово success — портал тебя пустил. Если пришёл HTML или ошибка — вход не прошёл, иди в раздел осложнений. Ничего не меняй наугад, сначала прочитай что ответил портал на первую команду.

Почему именно detectportal.firefox.com. Это служебный адрес Mozilla, который Firefox дёргает для той же задачи: понять, заперт ли он за порталом. Отвечает он по чистому HTTP одной строкой success. Любой портал перехватит этот запрос и подсунет свою страницу. Отсюда простой признак: пришло success — интернет есть, пришло что-то другое — нас держат на входе.

Для справки по параметрам fetch держи под рукой официальную документацию MikroTik по Fetch. Там описаны http-method, http-data, http-header-field, output и as-value. Нас интересует ещё http-max-redirect-count: по умолчанию fetch проходит два редиректа, и это нам пригодится.

Шаг 7. Создай скрипт входа cp-login

Зачем: вынести вход в отдельный скрипт, который можно вызвать из расписания, из Netwatch или руками. Все настройки собраны вверху, чтобы через полгода не искать где там был пароль.

Логи пишем латиницей. RouterOS хранит сообщения лога в своей кодировке, и кириллица в WinBox и в удалённом syslog превращается в знаки вопроса. Раз уж ты будешь читать этот лог в 3 ночи, пусть он хотя бы читается.

Где выполнять: терминал MikroTik-клиента. Вставляй целиком, одним блоком.

/system script add name=cp-login policy=read,write,test dont-require-permissions=no comment="captive portal login" source={
# ===== settings =====
:local wlan "wlan1"
:local loginUrl "http://10.10.0.1/login"
:local user "room512"
:local pass "S3cret%40pw"
:local extra "dst=&popup=true"
# ====================

:local body ("username=" . $user . "&password=" . $pass)
:if ([:len $extra] > 0) do={ :set body ($body . "&" . $extra) }

:local st [/ip dhcp-client get [find interface=$wlan] status]
:if ($st != "bound") do={
  :log warning ("cp-login: dhcp on " . $wlan . " is " . $st . ", skip")
  :error "no lease"
}

:do {
  :local res [/tool fetch url=$loginUrl http-method=post \
    http-header-field="Content-Type:application/x-www-form-urlencoded" \
    http-data=$body check-certificate=no output=user as-value]
  :log info ("cp-login: request sent, status=" . ($res->"status"))
} on-error={
  :log error "cp-login: fetch failed"
}
}

Что тут происходит, по строкам. Сначала собираем тело формы из логина, пароля и дополнительных полей. Потом проверяем что DHCP-клиент в статусе bound: нет адреса — нет смысла ломиться в портал, выходим с внятной записью в логе. Затем отправляем POST, и любая ошибка fetch ловится в on-error, чтобы скрипт не падал молча.

Параметр check-certificate=no оставлен явно. Для HTTPS-порталов это обычная история: самоподписанный сертификат на внутреннем IP. Для fetch значение no и так по умолчанию, но явная запись избавит тебя от вопроса коллеги «а почему оно не ругается на сертификат».

Результат: запусти скрипт вручную и посмотри лог.

/system script run cp-login
/log print where message~"cp-login"

В логе строка cp-login: request sent, status=finished. Это значит запрос ушёл и сервер ответил. Это ещё не значит что вход удался, это проверит следующий скрипт.

Шаг 8. Создай скрипт проверки cp-check

Зачем: вход сам по себе ничего не гарантирует. Нужен сторож, который раз в минуту спросит у интернета «ты тут?» и, если вместо ответа пришла страница портала, вызовет cp-login. Логика простая, и в этом её сила.

Где выполнять: терминал MikroTik-клиента.

/system script add name=cp-check policy=read,write,test dont-require-permissions=no comment="captive portal watchdog" source={
:local checkUrl "http://detectportal.firefox.com/success.txt"
:local online false

:do {
  :local res [/tool fetch url=$checkUrl output=user as-value]
  :local data ($res->"data")
  :if ([:pick $data 0 7] = "success") do={ :set online true }
} on-error={}

:if (!$online) do={
  :log warning "cp-check: no internet or portal detected, running cp-login"
  :do { /system script run cp-login } on-error={}
  :delay 5s

  :do {
    :local res2 [/tool fetch url=$checkUrl output=user as-value]
    :if ([:pick ($res2->"data") 0 7] = "success") do={
      :log info "cp-check: login OK, internet is up"
    } else={
      :log error "cp-check: still behind portal after login"
    }
  } on-error={
    :log error "cp-check: recheck failed"
  }
}
}

Смотри на логику. Если success пришёл — скрипт заканчивается молча, лог не засоряем. Раз в минуту писать «всё хорошо» — это способ через месяц не найти в логе ничего важного. Если не пришёл — пишем предупреждение, логинимся, ждём пять секунд и проверяем ещё раз. Вторая проверка пишет в лог итог: получилось или нет.

Пять секунд — не магическое число. Некоторые порталы применяют правила доступа с задержкой, на медленных контроллерах бывает и 10-15 секунд. Если видишь в логе «still behind portal», а через минуту всё работает — увеличь delay.

Шаг 9. Повесь проверку на расписание

Зачем: два триггера. Первый — раз в минуту, ловит истечение сессии. Второй — при старте роутера, с задержкой, чтобы Wi-Fi успел подключиться и получить адрес.

Где выполнять: терминал MikroTik-клиента.

/system scheduler add name=cp-check-1m interval=1m start-time=startup policy=read,write,test on-event="/system script run cp-check" comment="captive portal watchdog"
/system scheduler add name=cp-check-boot start-time=startup policy=read,write,test on-event=":delay 40s; /system script run cp-check" comment="captive portal on boot"

Результат: в /system scheduler print обе задачи, у первой растёт run-count. Политики у расписания и у скриптов должны совпадать. Если у scheduler политик меньше, чем у скрипта, скрипт просто не запустится, и никакой ошибки ты не увидишь, кроме тишины в логе.

Почему интервал минута, а не 10 секунд. Каждая проверка — это HTTP-запрос через чужую сеть. На слабом hAP lite это нагрузка на CPU, а в логах портала ты будешь выглядеть как бот. Минута — хороший баланс: максимальный простой после выкидывания сессии чуть больше минуты, и никто не нервничает.

Вот как выглядит полный цикл с точки зрения сети:

Обрати внимание на третью стрелку. Запрос к detectportal до входа перехватывает портал, а не сервер Mozilla. Именно поэтому нам не нужен никакой хитрый парсинг: достаточно проверить, что ответил настоящий сервер, а не подменщик.

Шаг 10. Порталы с динамическими полями

Если в шаге 4 ты увидел, что какие-то поля формы меняются от раза к разу, статичный скрипт не подойдёт. Три самых частых случая: портал хочет в запросе твой MAC, твой IP или одноразовый токен со страницы входа.

MAC и IP роутер знает сам. Двоеточия в MAC кодируем в %3A, иначе часть порталов не распознает адрес.

Где выполнять: терминал MikroTik-клиента. Этот фрагмент вставляется в cp-login перед строкой сборки body.

:local mac [/interface get [find name=$wlan] mac-address]
:local macEnc ""
:for i from=0 to=([:len $mac] - 1) do={
  :local c [:pick $mac $i]
  :if ($c = ":") do={ :set macEnc ($macEnc . "%3A") } else={ :set macEnc ($macEnc . $c) }
}

:local cidr [/ip dhcp-client get [find interface=$wlan] address]
:local ip [:pick $cidr 0 [:find $cidr "/"]]

:set extra ("mac=" . $macEnc . "&ip=" . $ip . "&" . $extra)

Имена полей mac и ip тут для примера. Бери те, что увидел в Payload: у одних порталов это client_mac и ipc, у других clientMac и userIp, у третьих вообще что-то своё. Буква в букву, регистр тоже важен.

С токеном сложнее. Его надо сначала вытащить со страницы входа. Страницу получаем тем же запросом к detectportal: портал перехватит его и отдаст HTML формы. Дальше ищем в HTML нужное скрытое поле.

Где выполнять: терминал MikroTik-клиента, фрагмент для cp-login.

:local token ""
:do {
  :local page [/tool fetch url="http://detectportal.firefox.com/success.txt" output=user as-value]
  :local html ($page->"data")
  :local key "name=\"token\" value=\""
  :local p [:find $html $key]
  :if ([:typeof $p] = "num") do={
    :local s ($p + [:len $key])
    :local e [:find $html "\"" $s]
    :set token [:pick $html $s $e]
  }
} on-error={ :log error "cp-login: cannot load portal page" }

:if ([:len $token] = 0) do={
  :log error "cp-login: token not found"
  :error "no token"
}
:set extra ("token=" . $token . "&" . $extra)

Строку key подгони под свой HTML. Если в исходнике написано value раньше чем name, или используются одинарные кавычки, поиск не сработает. Скопируй кусок тега из исходника страницы как есть и экранируй двойные кавычки обратным слешем.

Здесь есть тонкость, о которой молчат форумы. У output=user есть ограничение на размер ответа, большая страница с встроенными картинками может не влезть в переменную целиком. Если токен в самом конце огромной страницы — сохраняй ответ в файл через dst-path и читай его через /file get contents. Для большинства лёгких порталов это не нужно.

Бывают порталы, которые отдают страницу входа только после пары редиректов. По умолчанию fetch проходит два. Если редиректов больше, добавь в запрос http-max-redirect-count=5.

Проверка: работает ли автоматическая авторизация

Настроить мало. Надо убедиться, что схема переживёт реальные события: истечение сессии, реконнект и перезагрузку. Проверяем по очереди, от простого к жёсткому.

Где выполнять: терминал MikroTik-клиента.

/interface wireless registration-table print
/ip dhcp-client print where interface=wlan1
/tool fetch url="http://detectportal.firefox.com/success.txt" output=user
/system scheduler print where name~"cp-check"
/log print where message~"cp-"

Теперь жёсткий тест: разорви сессию сам. Отключи и включи Wi-Fi интерфейс, подожди пару минут и посмотри лог.

/interface disable wlan1
:delay 5s
/interface enable wlan1
:delay 120s
/log print where message~"cp-"

Нормальный результат: одна запись warning о том, что портал обнаружен, и одна запись info «login OK». Если портал не сбрасывает сессию при реконнекте, записей не будет вообще, и это тоже нормально. Последний тест — полная перезагрузка роутера командой /system reboot. После загрузки через 40-60 секунд в логе должен отработать cp-check-boot.

И проверь со стороны клиента LAN. На рабочей станции за MikroTik открой любой сайт. Он должен открыться без страницы портала. Если ноутбук видит портал, а роутер нет — проверь, что NAT настроен и клиент действительно ходит через MikroTik, а не через другую сеть.

Осложнения: частые ошибки и как их лечить

Всё не так плохо, как ты думаешь. Всё хуже, потому что каждый портал написан своим подрядчиком, и стандартов там столько же, сколько подрядчиков. Ниже ошибки, которые я встречал чаще всего, в формате: симптом, причина, решение.

Ошибка: fetch failed, could not resolve host

Причина: портал живёт по доменному имени вида login.hotel.local, а DNS роутера смотрит на публичные серверы. Внутреннее имя портала знает только DNS чужой сети. Классика: когда-то вбил 1.1.1.1 в /ip dns servers и забыл.

Решение: включи use-peer-dns на DHCP-клиенте и проверь, что DNS от чужой сети попал в список. Или используй в скрипте IP портала вместо имени.

Где выполнять: терминал MikroTik-клиента.

/ip dhcp-client set [find interface=wlan1] use-peer-dns=yes
/ip dns print
:put [:resolve "login.hotel.local"]

Если имя портала резолвится, но только через их DNS, а остальное ты хочешь гнать через свой — добавь статичную запись с IP портала. Его видно в DevTools, в поле Remote Address.

/ip dns static add name=login.hotel.local address=10.10.0.1 comment="captive portal"

Ошибка: status finished, но интернета всё равно нет

Причина: запрос дошёл, портал ответил 200, но вход не засчитал. Портал вежливо вернул ту же страницу входа с ошибкой, а fetch честно сказал «скачал». Ответ 200 значит только то, что сервер жив.

Решение: посмотри что именно вернул портал. Сохрани ответ в файл и прочитай.

Где выполнять: терминал MikroTik-клиента.

/tool fetch url="http://10.10.0.1/login" http-method=post http-header-field="Content-Type:application/x-www-form-urlencoded" http-data="username=room512&password=S3cret%40pw" dst-path=cp-answer.html
:put [/file get cp-answer.html contents]

Ищи в тексте слова error, invalid, неверный, expired. Чаще всего это одно из трёх: пропущенное скрытое поле, неверная кодировка пароля или отсутствующий cookie сессии. Сверь тело запроса с Payload из DevTools посимвольно. Не на глаз, а скопировав обе строки в один блокнот друг под другом.

Ошибка: портал требует cookie сессии

Причина: портал при показе страницы входа ставит cookie и принимает POST только вместе с ним. Fetch cookie не хранит: каждый вызов для него как первый раз в жизни.

Решение: получить cookie первым запросом и передать его вторым. В RouterOS 7 у fetch есть режим output=user-with-headers, который возвращает заголовки ответа вместе с телом. Проверь на своей версии, что в data действительно приходят заголовки, прежде чем строить на этом скрипт.

Где выполнять: терминал MikroTik-клиента.

{ :local r [/tool fetch url="http://10.10.0.1/login" output=user-with-headers as-value]; :put ($r->"data") }

Фигурные скобки тут не для красоты. В терминале каждая строка живёт в своей области видимости, и переменная :local с первой строки на второй уже не существует. Скобки собирают обе команды в один блок.

Если в выводе видишь строку Set-Cookie с именем вроде PHPSESSID — вытаскиваешь значение тем же приёмом с :find и :pick, что и токен в шаге 10, и добавляешь в POST заголовок Cookie. Несколько заголовков в http-header-field перечисляются через запятую.

/tool fetch url="http://10.10.0.1/login" http-method=post http-header-field="Content-Type:application/x-www-form-urlencoded,Cookie:PHPSESSID=8f3c2a1b" http-data="username=room512&password=S3cret%40pw" output=user

Если в заголовках нет ничего полезного, а портал без cookie не пускает — тебе дорога в альтернативы, раздел про внешний скрипт на curl. Там с cookie работать проще.

Ошибка: bad request или 405 Method Not Allowed

Причина: не тот метод или не тот Content-Type. Некоторые современные порталы принимают JSON, а не форму. Другие, наоборот, ждут GET с параметрами в URL.

Решение: посмотри Content-Type в Request Headers в DevTools. Если там application/json — меняй заголовок и формат тела.

Где выполнять: терминал MikroTik-клиента.

/tool fetch url="https://portal.example.net/api/auth" http-method=post http-header-field="Content-Type:application/json" http-data="{\"login\":\"room512\",\"password\":\"S3cret@pw\"}" output=user

Обрати внимание: в JSON пароль не кодируется процентами, а кавычки экранируются обратным слешем. Если портал принимает GET, параметры идут прямо в URL, и знак вопроса в терминале пишется как \?.

/tool fetch url="http://10.10.0.1/login\?username=room512&password=S3cret%40pw" output=user

Ошибка: портал на MikroTik Hotspot в режиме CHAP

Причина: если чужая точка — сама MikroTik с Hotspot, страница входа по умолчанию хеширует пароль в браузере через JavaScript: MD5 от chap-id, пароля и chap-challenge. Этих значений нет в статичном скрипте, и POST с открытым паролем портал отбросит, если у него выключен HTTP PAP.

Решение: проверь, принимает ли портал открытый пароль. У Hotspot MikroTik форма уходит на адрес /login с полями username и password. Если в профиле Hotspot включён метод http-pap, простой запрос сработает.

/tool fetch url="http://10.5.50.1/login" http-method=post http-header-field="Content-Type:application/x-www-form-urlencoded" http-data="username=room512&password=S3cret%40pw" output=user

Если не сработало — администратор портала оставил только CHAP. Тогда честный путь один: попросить у него привязку по MAC-адресу или отдельную учётку с типом входа by-mac. На MikroTik Hotspot это делается одной строкой в ip hotspot ip-binding на его стороне, и твой скрипт становится вообще не нужен.

Ошибка: скрипт вручную работает, по расписанию нет

Причина: политики. Scheduler запускает скрипт со своими правами. Если у scheduler нет test или write, fetch внутри скрипта не выполнится, и ошибки в логе не будет.

Решение: выровняй политики у scheduler и у обоих скриптов.

Где выполнять: терминал MikroTik-клиента.

/system script set [find name~"cp-"] policy=read,write,test
/system scheduler set [find name~"cp-check"] policy=read,write,test
/system script print detail where name~"cp-"

Ещё один подвох: владелец скрипта. Scheduler запускает скрипт от имени того пользователя, который его создал. Если ты создавал скрипт от пользователя с урезанной группой, прав может не хватить, даже если политики выставлены.

Ошибка: в логе login OK, а через 10 минут опять портал

Причина: портал выкидывает по простою или проверяет, что клиент «живой». Бывает и хуже: в сети два твоих устройства с одной учёткой, и портал выкидывает старую сессию при каждом новом входе.

Решение: сначала найди второе устройство. Телефон, который ты авторизовал той же учёткой при тестах, — частый виновник. Если дело в простое — добавь в cp-check лёгкий keepalive: даже раз в минуту запрос к detectportal портал обычно считает активностью. Если портал выкидывает по таймеру сессии, раз в сутки — твой скрипт с этим уже справится, простой будет около минуты.

Ошибка: сертификат при HTTPS-портале

Причина: кто-то из коллег «для безопасности» поставил check-certificate=yes. У портала самоподписанный сертификат на внутреннем IP, цепочку доверия RouterOS не находит.

Решение: для внутреннего портала верни check-certificate=no. Это осознанный компромисс: учётка от гостевого Wi-Fi не та тайна, ради которой стоит импортировать чужой CA на роутер. Если портал внешний и с нормальным сертификатом — можно оставить проверку, но тогда на роутере должно быть корректное время, иначе проверка упадёт по сроку действия.

/system ntp client set enabled=yes servers=ru.pool.ntp.org
/system clock print

Время, кстати, до входа в портал по NTP не синхронизируется. Замкнутый круг: для HTTPS нужно время, для времени нужен интернет, для интернета нужен HTTPS. Поэтому для порталов check-certificate=no — не лень, а инженерное решение.

Альтернативные решения

Скрипт на fetch — не единственный путь. Иногда он даже не лучший. Вот что ещё работает и когда это выбирать.

WPA2-Enterprise: авторизация на AP без скриптов

Если точка доступа спрашивает логин и пароль до подключения, это 802.1X, и RouterOS умеет его сам. Вход происходит при каждой ассоциации с точкой, автоматически, без расписаний и проверок. Это самый надёжный вариант из всех, жаль что выбирать его обычно не тебе.

Для пакета wireless RouterOS поддерживает PEAP только с внутренним методом MSCHAPv2, это прямо написано в вики MikroTik по PEAP-клиенту.

Где выполнять: терминал MikroTik-клиента.

/interface wireless security-profiles add name=corp-eap mode=dynamic-keys authentication-types=wpa2-eap eap-methods=peap supplicant-identity="ivanov" mschapv2-username="ivanov" mschapv2-password="ПарольAD" tls-mode=dont-verify-certificate
/interface wireless set wlan1 mode=station ssid="Corp_WiFi" security-profile=corp-eap disabled=no

Для пакета wifi на RouterOS 7 те же параметры задаются в security интерфейса:

/interface wifi set wifi1 configuration.mode=station configuration.ssid="Corp_WiFi" security.authentication-types=wpa2-eap security.eap-methods=peap security.eap-username="ivanov" security.eap-password="ПарольAD" disabled=no

Результат: в registration-table появляется точка, в логе строки wireless или wifi о подключении. Если на старых 7.x PEAP не поднимался — обнови RouterOS: в релизе 7.15 MikroTik отдельно чинил клиентскую аутентификацию eap-peap и mschapv2, об этом есть тред на форуме MikroTik.

Про dont-verify-certificate. Это значит роутер не проверяет сертификат RADIUS-сервера. В корпоративной сети это дыра: злоумышленник с поддельной точкой соберёт хеш твоего пароля. Если есть возможность — импортируй CA организации и проверяй сертификат. Если нет — хотя бы используй для роутера отдельную учётку, а не свою доменную.

Netwatch вместо scheduler

Netwatch умеет запускать скрипт при переходе хоста в состояние down. Выглядит элегантно, но есть два нюанса. Первый: многие порталы пропускают ICMP до авторизации, и пинг до 8.8.8.8 будет зелёным, пока сайты не открываются. Второй: Netwatch выполняет скрипты от системного пользователя и только с политиками read, write, test, reboot, так что права надо выставить аккуратно.

Где выполнять: терминал MikroTik-клиента.

/tool netwatch add name=cp-watch type=icmp host=8.8.8.8 interval=30s down-script="/system script run cp-login" comment="captive portal fallback"

Я использую Netwatch как второй слой: он ловит полную пропажу связи быстрее минутного расписания. Основной сторож всё равно cp-check, потому что он проверяет именно HTTP, а не ICMP.

Внешний скрипт на curl

Когда портал совсем злой — cookie, редиректы через три домена, JavaScript, — проще отдать вход инструменту, который это умеет. curl держит cookie jar, ходит по любым редиректам и понимает всё, что понимает браузер, кроме JavaScript. Запускать можно на Raspberry Pi за роутером или в контейнере на самом MikroTik, если модель поддерживает container.

Где выполнять: Linux-хост в LAN за MikroTik-клиентом.

#!/bin/bash
# /usr/local/bin/cp-login.sh
JAR=/tmp/cp.cookies
if curl -s --max-time 5 http://detectportal.firefox.com/success.txt | grep -q '^success'; then
  exit 0
fi
curl -s -c "$JAR" -b "$JAR" -L http://10.10.0.1/login -o /dev/null
curl -s -c "$JAR" -b "$JAR" -L -X POST http://10.10.0.1/login \
  --data-urlencode 'username=room512' \
  --data-urlencode 'password=S3cret@pw' \
  -o /dev/null
logger -t cp-login "login attempt done"

chmod +x /usr/local/bin/cp-login.sh
( crontab -l 2>/dev/null; echo '* * * * * /usr/local/bin/cp-login.sh' ) | crontab -

Заметь, что curl кодирует пароль сам через —data-urlencode, и таблица процентов тебе больше не нужна. Портал всё равно видит один IP — адрес MikroTik после NAT, поэтому вход с Linux-хоста открывает интернет всему LAN. Капля никотина убивает лошадь. Одна строка в crontab без комментария — весь отдел, который через год будет искать, откуда в логах портала раз в минуту берутся запросы. Подпиши её.

Почему основной вариант всё-таки fetch

Всё живёт на одном устройстве. Нет второй железки, которую надо питать, обновлять и которая умрёт первой. Конфиг экспортируется вместе с роутером одной командой, и при замене железа переезжает целиком. Для 80% порталов, которые я видел в отелях, бизнес-центрах и на объектах, простой формы и fetch хватает с головой.

Профилактика: мониторинг, бэкап, безопасность

Мониторинг

Лог роутера никто не читает, пока не случилось. Поэтому ошибки скрипта надо выносить туда, где их увидят. Минимум — удалённый syslog. Если есть Zabbix или Telegram-бот для алертов — отправляй туда.

Где выполнять: терминал MikroTik-клиента. IP 192.168.88.10 замени на свой syslog-сервер.

/system logging action add name=remote target=remote remote=192.168.88.10 remote-port=514
/system logging add topics=script action=remote
/system logging add topics=error action=remote

Для Telegram добавь в конец блока с ошибкой в cp-check вызов fetch к API бота. Токен и chat_id подставь свои. Если интернета нет, сообщение, понятно, не уйдёт, поэтому шли его после успешного перелогина: «был портал, залогинился». Так ты увидишь, как часто портал тебя выкидывает, и заметишь, если частота вдруг выросла.

/tool fetch url="https://api.telegram.org/bot<TOKEN>/sendMessage" http-method=post http-header-field="Content-Type:application/json" http-data="{\"chat_id\":\"<CHAT_ID>\",\"text\":\"cp-login: relogin done\"}" output=none

Безопасность

Где выполнять: терминал MikroTik-клиента.

/interface list member print where list=WAN
/ip firewall filter add chain=input in-interface-list=WAN connection-state=established,related action=accept comment="cp: allow replies"
/ip firewall filter add chain=input in-interface-list=WAN action=drop comment="cp: drop all from uplink"
/ip service set [find name~"telnet|ftp|www|api"] disabled=yes
/ip service set [find name~"ssh|winbox"] address=192.168.88.0/24
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN
/ip neighbor discovery-settings set discover-interface-list=LAN

Проверь, что правило drop стоит ниже правил accept для LAN. В дефолтном конфиге MikroTik такое правило уже есть — тогда достаточно убедиться, что wlan1 в списке WAN, и не дублировать. Подсеть 192.168.88.0/24 замени на свою локалку.

Аналог fail2ban на RouterOS — список адресов для перебора SSH. Раз все сервисы и так закрыты со стороны wlan1, это защита второго рубежа, на случай если кто-то в LAN решит поиграть в хакера.

/ip firewall filter add chain=input protocol=tcp dst-port=22 src-address-list=ssh-blacklist action=drop comment="ssh bruteforce drop"
/ip firewall filter add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh-stage2 action=add-src-to-address-list address-list=ssh-blacklist address-list-timeout=1d
/ip firewall filter add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh-stage1 action=add-src-to-address-list address-list=ssh-stage2 address-list-timeout=1m
/ip firewall filter add chain=input protocol=tcp dst-port=22 connection-state=new action=add-src-to-address-list address-list=ssh-stage1 address-list-timeout=1m

SSH hardening: включи strong-crypto, заведи ключ и отдельного админа, стандартного admin отключи. Публичный ключ id_ed25519.pub предварительно закинь в Files через WinBox. Порядок важен: сначала проверь вход новым пользователем в соседней сессии, потом отключай старого.

/ip ssh set strong-crypto=yes
/user add name=netadm group=full password="ДлинныйПароль"
/user ssh-keys import user=netadm public-key-file=id_ed25519.pub
/user disable admin

Отдельно про пароль от портала в скрипте. Он лежит открытым текстом в source, и любой пользователь с правом read его увидит. Отдельного пользователя БД тут нет, но логика та же: если на роутер ходят подрядчики — заведи им группу без policy sensitive и read на скрипты. Подрядчик, который видит пароль от Wi-Fi отеля, — это не катастрофа. Подрядчик, который видит пароль от 802.1X с доменной учёткой, — это инцидент.

Резервное копирование

Автоматический бэкап раз в неделю кладём на сам роутер и забираем по SFTP с сервера. Бинарный backup восстанавливается только на такую же модель, поэтому текстовый export важнее: его можно поднять на любом MikroTik.

Где выполнять: терминал MikroTik-клиента.

/system script add name=weekly-backup policy=read,write,test,policy,sensitive source={
:local d [/system clock get date]
/export show-sensitive file=("cp-export-" . $d)
/system backup save name=("cp-backup-" . $d) password="ПарольБэкапа"
}
/system scheduler add name=weekly-backup interval=7d start-time=03:30:00 policy=read,write,test,policy,sensitive on-event="/system script run weekly-backup"

Восстановление скриптов после сброса — это тот же блок из шагов 7-9, поэтому держи его в одном файле cp-portal.rsc. Проверь восстановление хотя бы раз на тестовом роутере. Бэкап, который ни разу не восстанавливали, — это просто файл.

Автозапуск

Он у нас уже есть: scheduler cp-check-boot с задержкой 40 секунд. Проверь что задержки хватает на твоём железе. На hAP lite загрузка с подключением к Wi-Fi может занять больше минуты, и тогда первый запуск просто отработает вхолостую, а минутный сторож подхватит. Некритично, но лишняя запись в логе.

Обновление RouterOS без сюрпризов

Перед обновлением сделай export, прочитай changelog на предмет изменений в fetch, scripting и wireless/wifi. Синтаксис скриптов между 7.x меняется редко, но переименования параметров случаются. Обновляйся только на ветке stable или long-term, testing на удалённом объекте без рук — это смелость, а не инженерия.

Где выполнять: терминал MikroTik-клиента.

/export show-sensitive file=before-upgrade
/system package update set channel=stable
/system package update check-for-updates
/system package update install

После перезагрузки прогони раздел проверки целиком. Откат: скачай npk нужной версии для своей архитектуры с сайта MikroTik, загрузи в Files и выполни /system package downgrade. Роутер перезагрузится на старую версию, конфиг сохранится.

Отдельная засада для удалённых объектов. Если обновление сломает Wi-Fi драйвер, роутер больше не подключится к точке, и попасть на него удалённо ты не сможешь. Поэтому обновляй такие устройства только когда рядом есть человек, способный передёрнуть питание и подключить кабель. Рождённый в legacy рефакторинга не боится. Но и обновляться в пятницу вечером не спешит.

FAQ: частые вопросы про авторизацию MikroTik на точке доступа

Почему автоматическая авторизация MikroTik не работает после настройки?

В девяти случаях из десяти запрос из скрипта отличается от запроса браузера: пропущено скрытое поле, пароль не закодирован или портал ждёт cookie. Сохрани ответ портала в файл через dst-path и прочитай его — там обычно прямо написана причина отказа. Десятый случай — политики scheduler, которые не дают скрипту запуститься.

Как проверить, что авторизация на точке доступа работает правильно?

Выполни в терминале fetch к detectportal.firefox.com/success.txt с output=user. Если в data пришло success — интернет открыт. Для полной проверки отключи и включи Wi-Fi интерфейс и через пару минут посмотри лог по фильтру cp-: там должна быть запись login OK.

Можно ли подключить MikroTik к Wi-Fi с веб-авторизацией через браузер?

Да, и это самый быстрый разовый способ. Подключи роутер к точке в режиме station, настрой NAT и войди в портал с любого ноутбука за MikroTik. Портал видит IP и MAC роутера, поэтому интернет откроется для всей локальной сети. Минус один: после истечения сессии всё придётся повторить, поэтому для постоянной работы нужен скрипт.

Что делать, если /tool fetch возвращает ошибку при входе в портал?

Смотри текст ошибки. Could not resolve host — проблема DNS, включи use-peer-dns или пиши IP портала. Ошибка редиректа — добавь http-max-redirect-count. Ошибка SSL — проверь check-certificate=no. Ответ 405 или 400 — не тот метод или Content-Type, сверь с DevTools.

Чем вход через скрипт fetch отличается от WPA2-Enterprise?

WPA2-Enterprise авторизует на уровне самого Wi-Fi через 802.1X: пока логин не принят, точка тебя не пустит даже в сеть. Там логин прописывается в security-профиле, и RouterOS входит сам при каждом подключении. Скрипт fetch нужен для веб-порталов, где сеть открыта, а доступ в интернет выдаётся после отправки формы. Это две разные технологии, и выбор между ними делает владелец точки, а не ты.

Как подключить MikroTik к публичному Wi-Fi с авторизацией по SMS?

Полностью автоматизировать такой вход нельзя: код приходит на телефон и каждый раз новый. Но большинство таких сетей после входа запоминают MAC-адрес на срок от суток до месяца. Войди один раз с ноутбука за MikroTik, и роутер будет считаться авторизованным до конца этого срока. Помни про закон: в России публичный Wi-Fi обязан идентифицировать пользователя, и вход идёт на твой номер.

Почему авторизация слетает после перезагрузки MikroTik?

Многие порталы привязывают сессию к DHCP-аренде или к ассоциации с точкой. После перезагрузки роутер переподключается, и портал считает его новым клиентом. Лечится задачей в scheduler с start-time=startup и задержкой 40-60 секунд, которая запускает проверку и вход после загрузки.

Безопасно ли хранить пароль от портала в скрипте MikroTik?

Он хранится открытым текстом и виден любому пользователю с правом read на скрипты. Для гостевого Wi-Fi это приемлемо. Для 802.1X с доменной учёткой — нет: заведи для роутера отдельную сервисную учётку с минимальными правами и ограничь группы пользователей RouterOS.

Прогноз

Мы перевели MikroTik в клиентский режим, сняли в браузере точный запрос формы входа и научили роутер повторять его командой fetch. Поверх поставили сторожа cp-check, который раз в минуту отличает настоящий интернет от подменной страницы портала и логинится заново, плюс запуск после перезагрузки. Для точек с 802.1X разобрали вход через security-профиль, где скрипт вообще не нужен. Роутер закрыт со стороны чужой сети, конфиг выгружается раз в неделю.

Теперь истекшая сессия стоит тебе минуту простоя и одну строку в логе, а не поездку на объект. Портал может сменить подрядчика, поменять имена полей или добавить капчу, и тогда рецепт придётся повторить с шага 4. Держи cURL из DevTools в том же репозитории, что и export роутера: в следующий раз это сэкономит час.