Mikrotik. Блокировка доступа к HTTPS сайтам : Сеть

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

А как их не отдавать тогда тем, кого лимиты не касаются?

а почему не отдавать? ипы то вполне валидные, пусть по ним и работают

Сразу не дошло, что их же и баним. Я просто рассматривал схему подсовывания кривых IP в интервал времени, но проблема была в том, чтобы разным пользователям отдавать разные адреса. Схема нормальная, за исключением того, что адреса меняются... Придется все время их обновлять... Теоретически возможно, конечно, дергать их из nslookup и перестраивать DNS-static и листы... Но это уже какой-то углубленный колхоз... :)

а смысл? они динамически меняются роунд-робином на днс у гугла для выравнивания нагрузки, но ведь однажды занесенные в статик все равно остаются валидными. Освежать список нужно будет лишь тогда когда по ним перестанет отдаваться контент или тормозить начнет. Я бы особо и не парился, можно ручками изредка обновлять, а можно и скрипт накидать хоть внутри, хоть снаружи

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

[ ➜ ] тут решение схожей задачи. Обход имен по днс, создание адрес листов и чистка кеша днс микрота. Достаточно будет вместо чистки кеша заполнять статик записи в днс.

Познавательно :) Я тут уже себе мозг вывернул - отвлекают, к выходным ближе буду на практике тестировать...

можно вот так:
Проверил, работает.
блокируем трубу с 9 до 18

Хм, противоречит сути HTTPS же... content=youtube будет срабатывать только если холодный старт и не был там раньше, в результате чего сначала идешь на HTTP, где тебя и палит правило, нет?