Почему бы не найти окончательное решение для блокировки Youtube?

@SoB прав – не стоит слишком надеяться на то, что это всего лишь одна строка конфигурации. Полезная функция, но как комплексный инструмент для блокировки веб-сайтов она неполная. Я действительно считаю, что попытки эффективно блокировать YouTube без серьезного влияния на другие вещи на Mikrotik – это сложная задача. Поскольку я не против поиграть в адвоката дьявола… SOCKS5 как раз для таких случаев – весь трафик проходит через один порт, если операционная система/браузер это поддерживают. Я бы не стал рекомендовать использовать SOCKS на v7.1 пока… Но мне кажется, что домашние устройства поддерживают автоматическую настройку прокси через “PAC файл”: https://en.wikipedia.org/wiki/Proxy_auto-config. Zscaller приводил картинку/описание о том, как работает PAC. Также помню, что нужно было настроить некоторый DHCP для включения SOCKS5. Если что-то не позволяло использовать PAC файл/приложение не работало, или требовало более широкого доступа и т.д. – тогда можно было бы разрешить прямой доступ к этим сервисам в файерволе для каждого устройства. Для действительно сложных случаев разрешите прямой HTTPS доступ для "доверенного устройства" в конфигурации файервола. Или, возможно, используйте класс устройства через скрипт на DHCP-сервере, который добавляет в список файервола IoT-устройства, основываясь на начальном MAC или резервациях и т.д. Определенно стоит переосмыслить вашу конфигурацию/сеть, чтобы включить блокировку с помощью этого метода. Я думаю, что это игра в кузнечика, если у вас только Mikrotik в арсенале. Но если так, возможно SOCKS стоит рассмотреть – это что-то, что можно попробовать, поскольку дни подхода через DNS сочтены, и с QUIC мало что можно сделать. Снова говорю, придерживайтесь v6, если решите это сделать.

Я бы также не рекомендовал SOCKS. Или даже пытаться решить эту «проблему» на Mikrotik — лучше сосредоточиться на управлении пропускной способностью. Если вам нужно ограничить пользователей более детально, посмотрите что-то помимо Mikrotik. Но если вы ищете новаторский подход на Mikrotik, который блокирует сайты (насколько это возможно), MT предлагает множество способов, но это никогда не будет «окончательным решением». Так что это больше возможностей для экспериментов. По крайней мере, SOCKS всегда знает доменные имена, и если устройство/браузер это поддерживает, скорее всего, они будут следовать любой политике. DNS-уловки просты, но в конце концов клиенты начинают их избегать. SOCKS5, по крайней мере, будет стабильным (в конечном счете в V7), имеет интерфейс и либо работает, либо нет. В основном, SOCKS превращается из просто еще одного метода, позволяющего избежать тех самых MT-фильтров контента, о которых здесь говорили (например, жесткие правила DNS-файрвола здесь ничего не сделают, если кто-то настроит свое устройство на использование SOCKS) — в более историческую форму SOCKS как защитного контроллера. Начните с запрета для всех IPv4, затем создайте белый список для того, что не работает с SOCKS. Поскольку блокировка одного сайта, скорее всего, не единственное, что кто-то может хотеть заблокировать. Что делать с IPv6 и блокировкой — тут я совсем понятия не имею — это кажется еще сложнее (но, может быть, и проще). Конечно, есть некоторые [возможно частичные] решения. Если вы хотите внедрить использование IPv6, еще одна идея в этом направлении — предложить только доступ по SOCKS5 для IPv4, что, безусловно, является подходом — это позволит сосредоточить ваши усилия по блокировке на том, что нужно защитить в IPv6. Еще одна идея — поскольку все, что вы делаете в фаерволе IPv4, должно быть повторено в фаерволе IPv6, чтобы это работало — любая блокировка на MT фактически требует ВДВОЙНЕ больше работы. Если у вас есть IPv6 на WAN, в большинстве случаев вам захочется его использовать — помимо возможности блокировать сайты, он обычно предлагает преимущества скорости. Также стоит учесть, что если у вас только мобильное устройство (Apple/Android), могут быть простые/дешевые способы ограничить доступ к сайтам. Существует множество решений от MDM Apple для iPhone и iPad, включая использование Profile Manager на Mac — это позволяет вам блокировать сайты (и не только). У Android есть подобные вещи, снова, для экспертов. Также есть много опций DHCP, которые могут помочь управлять некоторыми политиками (не могу вспомнить, если там есть блокировка сайтов, но иногда есть экзотические вещи DHCP для реализации сетевой политики). Также я уверен, что есть решения Made for Mikrotik SaaS, которые решают ту же проблему, применяя эти MT-техники блокировки более автоматически. В основном, Mikrotik запрашивает сетевое устройство по уважению к некоторому протоколу и блокирует, если оно этого не делает — это другой способ решить эту задачу. Вам нужно будет выяснить, почему что-то не подчиняется. Или примите, что вам может понадобиться применить крупную организационную технику дома, чтобы более реально решить задачу блокировки сайтов эффективно.

Удалив доступ в интернет, если они нарушат правила…

Файрволл Raw, если он ограниченного диапазона, — вы можете использовать вкладку соединений файрволла, чтобы получить адреса. В качестве альтернативы могут работать методы L7 и TLS Host для создания списка адресов, но их легко обойти. MT не предлагает простую фильтрацию URL или ключевых слов, как это делают потребительские роутеры. С помощью DNS-сервера вы можете блокировать рекламу и любой сайт, который вам нужен. Если это всего несколько компьютеров на Windows, вы также можете блокировать сайты с помощью файла HOST.

Это правило идеально подходит для меня: add action=reject chain=blocklist comment=“блокировать youtube” protocol=tcp reject-with=icmp-network-unreachable tls-host=youtube пожалуйста, не используйте l7 правила для блокировки веб-страниц.

Как вы загружаете свои видео, если это работает? Не волнуйтесь, Chrome позволяет мне смотреть. Документы по фильтрам довольно хорошо разъясняют большинство обсуждений здесь — по сути, там говорится, что в некоторых случаях этот метод не работает... Документы MT даже содержат желтое предупреждение, касающееся использования фильтра YouTube методом "tls-host": сопоставитель tls-host является мощным инструментом для блокировки HTTPS-сайтов, но, например, YouTube использует QUIC (протокол на основе UDP), а не обычный HTTP/2 (протокол на основе TCP). TLS-host не работает с QUIC, так как зависит от TCP-соединения. В правилах фильтра Firewall>Filter с tls-host есть некоторые тонкости: позволяет сопоставлять HTTPS-трафик на основе имени хоста TLS SNI. Принимает синтаксис GLOB для сопоставления с подстановочными знаками. Обратите внимание, что сопоставитель не сможет сопоставить имя хоста, если фрейм TLS-рукопожатия фрагментирован на несколько TCP-сегментов (пакетов). Поэтому, если "tls-host= domainname" не работает более широко с другими сайтами, проверьте/исправьте настройки диапазона MTU и/или MSS. Если у вас есть фрагментация, вы, вероятно, сделаете производительность лучше, исправив это — это может позволить вам не волноваться о том, что YouTube будет обходить блокировку. С другой стороны, использование любого Layer7/L7 RegEx на вашем маршрутизаторе, безусловно, негативно скажется на вашей производительности. Хотя на самом деле именно это в значительной степени и делают решения для фильтрации контента в бизнесе/других сферах, но это требует больших ресурсов процессора, потому что они используют сложный набор правил сопоставления, у которых есть гораздо больше контекста (например, правила L7 не могут использовать весь пакет), обычно с некоторым автоматическим обновлением, так как блокировочные правила нужно изменять вместе с методами веб-сайтов, чтобы избежать блокировки. Вот почему здесь предлагают такой набор: это + брандмауэр + перенаправление DNS как "лучший возможный" подход для Mikrotik. Но даже если вы все это делаете, вам все равно нужно учитывать IPv6, к которому компании вроде Google/Apple стараются подтолкнуть пользователей, и который теперь включен по умолчанию в V7. Брандмауэр IPv6 Mikrotik защитит входящий трафик, но по умолчанию разрешает LAN IPv6 без проблем. Но в случае с YouTube и браузером Chrome… вы действительно пытаетесь противостоять компании с доходами в 1 триллион долларов, чьи доходы зависят от того, чтобы люди видели контент вроде YouTube с использованием всех инструментов — они контролируют как клиента, так и сервер, и могут применять разнообразные техники, чтобы это "просто работало" для клиента — включая обход самых распространенных способов, которыми домашний маршрутизатор может блокировать трафик. Это не обязательно атака — люди действительно неправильно настраивают маршрутизаторы, и некоторым это кажется функцией, что Chrome "исправляет это". Или в случае QUIC, пытаются решить проблемы проектирования с TLS и TCP, которые ограничивают производительность. Я не принимаю чью-либо сторону в этом подходе, но если ваша техническая задача состоит в "остановке работы YouTube", это просто сложно и/или требует много работы и денег.

Соб, можешь привести пример того, что ты имеешь в виду под прокси???