Потому что ip-адреса серверов динамические, к тому же нет необходимости в том чтобы остальной трафик "гулял" через эти маршруты. На данный момент так и работает - через статику, но хотелось бы решения, которое не требует постоянного ручного вмешательства.
snoopik6, что вы головы людям морочите, вам неоднократно разжевывали как вам решить вашу проблему. Вы либо не понимаете смысл терминов, либо просто троллите людей, вводя в заблуждение. Из ваших конфигов видно, что ип-адреса вы получаете от провайдера на пппое-интерфейсы, при этом утверждаете что у вас статические ип адреса.
Статический ип-адрес прописывается со стороны абонента на физический интерфейс, фиксированный ип-адрес через пппое - ип-адрес выдается провайдером для виртуального интерфейса пппое - это совершенно разные технологии подключения, в случае пппое у вас не получиться добиться нормальной работы EoIP, скольбо вы не старались, это давно пройденные грабли и преодолеваются они очень просто, с помощью VPLS.
Также в вашем конфиге пппое-клиента присутствует dial-on-demand=yes, использовать подключение по требованию для wan-интерфейса, а тем более для соединения офисов через него, мягко говоря, совсем нелогично. В mangle зачем-то у вас устанавливается MSS=1360 для абсолютно всех syn-пакетов, вероятно для борьбы с PMTUD black hole с помощью топора, несмотря на то что в Router OS эта проблема давно решена без mangle, включением нужной опции в ppp-profile или галочек в настройках интерфейсов, которые у вас почему-то отключены.
Yan, шлюзом выступает маршрутизатор, на нем нужно подменить соответствующие dns-запросы и заблокировать соответствующие ип-адреса, но так чтобы интернет работал, а ncsi не имела доступа. Вопрос в том что подменять и блокировать.
Yan, При отключении службы ncsi значок сетевого подключения всегда показывает доступ в интернет, даже когда нет доступа, а нужно сделать наоборот, причем не меняя настройки клиентских ПК.
mazzahaker, навскидку - во всех правилах маркировки соединений у вас нигде нет connection state=new, не видно какие routing marks в /ip routes.
При маркировке соединений должно быть passthrough=yes, при маркировке маршрутов - passthrough=no.
Попробуйте настроить PCC по схожему принципу - сначала маркировать соединения, а далее маршруты.
Ну это не проблема, при использовании мультиван необходимо маркировать входящие соединения и ставить соответствующие маршрутные метки в цепочке output, чтобы пакеты возвращались туда, откуда пришли.
Вы смотрели, проверяли? А как думаете, что будет, если подменить домены для запросов, которые блокируют браузерные блокировщики?
youtube.com/api/stats/qoe?
youtube.com/player_204?
youtube.com/get_midroll_
youtube.com/youtubei/v1/log_event?
google.com/pagead/
youtube.com/ptracking?
youtube.com/api/stats/
youtube.com/csi_204?
И знаете ли вы какой-нибудь сторонний днс, который на данный момент решает задачу блокировки рекламы на ютьюб?
Лично мне не знаком ни один человек, у которого бы возникали трудности с доступом к запрещенным сайтам в России. То что госрыла гордо именуют "блокировка" - легко обходят даже школьники.
Да, он продемонстрировал что блокировка работает.
Видимо, вы не до конца информированы о произошедшим, 13 апреля 2018 года все российские СМИ начали трубить о решении Таганского суда по поводу блокировки telegram, которое никто не отменял и до сих пор юридически мессенджер "вне закона". Однако, сми молчат, а телеграм как работал так и работает, у всех провайдеров без всяких обходов блокировок, причем это было вполне ожидаемо, для тех кто имеет представление о работе cdn и понимает что у любого серьезного игрока в современном интернете достаточно средств и технических решений, чтобы избежать последствий действий российских недоучек.
Причем противодействует команда специалистов.
А осуществляют борьбу с рекламой одиночки в основном.
Тем не менее, заблокировать рекламу в браузере настолько же просто, как и получить доступ к запрещенным сайтам, установить плагины, которых просто невероятное количество, под силу даже детям.
У меня же стоит задача блокировки на уровне шлюза, чтобы избавить пользователей от лишних движений и решение уже на подходе.
dollar, в отношении запрещенных сайтов тоже было много пессимизма, но нужно признать, что механизмы блокировок на сегодняшний день не работают и не будут работать в будущем. Telegram вполне наглядно это продемонстрировал.
Что же касается борьбы с рекламой, в первую очередь здесь играет роль морально-нравственная сторона - как известно, любая информация носит управляющий характер, у человека в принципе не может быть своих мыслей и желаний - все его мысли есть результат обработки входящей информации, а что нам несет реклама? Это фактически насильственное принуждение, с целью чтобы паразиты обогащались за счет людей, что есть зло в чистом виде и с ним надо бороться каждому, в меру сил и возможностей. Что же касается технических решений - уререн, это лишь вопрос времени.
Дмитрий, спасибо за мысли, пока все же хочется надеяться на то, что анализ пакетов, возможно, поможет найти признаки, за которые можно зацепиться. Несколько лет уже мой сервер на Debian мирно покоится, доверив всю работу микротикам, похоже, скоро настанет его час взбодриться)
АртемЪ, За час просмотра юутьюб без рекламы более 100 роликов, uBlock origin заблокировал более 2000 запросов, к 11 доменным именам + несколько десятков адресов серверов видеоконтента, вида r2---sn-gvnuxaxjvh-t3nl.googlevideo.com. Среди заблокированных - запросы к youtube.com и google.com, которые также нельзя блокировать по доменному имени. Пару десятков тысяч днс-имен, это вероятно список для блокировки всей рекламы в интернете, есть и гораздо большие списки, но они безрезультатны в случае ютьюб.
dollar, Судя по наблюдениям, доменные имена и ип-адреса совпадают, поэтому подменять доменые имена вида *.googlevideo.com нельзя - вместе с рекламой блокируется и основной контент. Но ведь так и раньше было, при этом блокировка рекламы легко осуществлялась с помощью подмены пары десятков днс-имен, но теперь это не работает. Хотелось бы найти решение проблемы именно на роутере.
В RouterOS уже давненько решены все проблемы с regexp в /ip dns static. Недостаток в том, что днс-запросы по регулярным выражениям не попадают в кэш, но это легко решается 2-мя микротиками.
Maksim Herasim, вот вы здесь жути нагоняете, а как, например, провайдер сможет определять передачу трафика третьим лицам или наличие пароля на домашней точке доступа? В договорах страшилки написаны, доказать которые законными способами невозможно. Второй момент, пусть даже я нарушил договор с провайдером, пусть провайдер это докажет и накажет меня за нарушение договора (расторгнет его в одностороннем порядке) - это вовсе не означает, что именно я заходил на свою точку без пароля и оставлял где-то какие-то плохие комменты. Доказывать что-то правоохранительным органам - это отдельная тема, но ведь с позиции разума - никто не может нести ответственности за то, чего не совершал.
