Comments 66
Отличный сервис. Большое вам спасибо за него. Не хотите ли вы поделиться им с сообществом, раскрыв исходный код, чтобы каждый желающий мог на своих ресурсах поднять такой же? Это бы автоматом решило вопрос с масштабированием. Думаю, найдется много людей (и я в том числе), который подержат этот проект на том же гитхабе, помогая со сборками, багфиксами и прочими радостями opensource)
«Под капотом» у сервиса ровно то самое решение, которое было подробно описано в самой первой статье, на которую здесь есть линк. Это же решение может повторить на своей площадке любой желающий, просто пошагово выполняя описание.
Есть некоторые проблемы с получением дампа — своим источником дампа я поделиться не могу по очевидным причинам. Но дамп можно брать с гитхаба, как, опять же, описано в статье.
Так что делиться тут нечем, по сути. Ну не кодом же лендинга с бесплатным темплейтом.
Предполагаю, что реестр как источник IP-префиксов для обхода блокировок исчерпает себя в начале-середине 2022 года
откуда взалась эта дата середина 2022 года? Вы считаете что блокировать через год начнут в тихую, не сообщая нам какой IP заблокировали?
- государство не обязано сообщать «нам», какие IP-адреса заблокированы. Полный реестр — информация ограниченного доступа и существует постольку, поскольку операторы связи пока что обязаны обеспечивать блокировку и им для этого нужна информация;
- блокировка на операторах в целом неуспешна — большинство операторов строят системы блокировки формально, чтобы не попасть под штрафы. Контролирующие агенты («Ревизоры») большинство ставит в песочницы, чтобы уменьшить вероятность проблем, а пользователи сети продолжают иметь доступ как минимум к части заблокированных ресурсов;
- во многом именно по этой причине была придумана система ТСПУ, официальные поводы внедрения которых смехотворны и схема включения их не соответствует декларируемым целям. Но при этом законом 90-ФЗ прямо прописывается, что оператор связи, на сети которого ресурс блокируется с использованием ТСПУ, не обязан самостоятельно блокировать доступ к этому ресурсу;
- «замедление Твиттера» было первым массовым тестированием ТСПУ в продакшне и декларированное замедление показало текущее проникновение ТСПУ — 100% у мобильных операторов и 50% на фиксированных (по числу абонентов);
- расстановка ТСПУ продолжается, при этом есть второй тренд на поглощение мелких операторов (где в основном ТСПУ еще отсутствуют) крупными (где ТСПУ установлены);
- предполагаю, что к началу-середине 2022 оба этих тренда приведут к тому, что проникновение ТСПУ будет близко к 100% и участие операторов в блокировках более требоваться не будет.
Вот приблизительно такая у меня логика.
Мало того, тенденция укрупнения операторов нацелена на то, что на рынке фиксированного ШПД останется фактически один единственный оператор («угадайте кто»), и покупку Ростелекомом ЭР-Телекома я прогнозирую не позднее 2024 года, но может и в 2023 успеют.
Ein Reich, ein Führer, ein Internetdienstanbieter.
Поздравляю, первая часть вашего предсказания исполнилась. В списке выгрузки нет, например, твиттера, фейсбука или инстаграма.
Ждём вторую часть.
В выгрузку добавили AS фейсбука и твиттера вручную, но там печаль в том, что у фейсбука трафик размазан по CDN на чужих адресах. И, например, весь RETN ради этого отправлять в выгрузку было бы как-то неправильно.
Если кто-нибудь знает для фейсбука сервис, аналогичный https://www.gstatic.com/ipranges/goog.json - поделитесь ссылками.
В BGP есть поддержка flow-spec, кстати. Там можно обрабатывать отдельные порты отдельных протоколов по специальным правилам. В принципе, это предназначно для борьбы с DoS-атаками; и на мой взгляд действия РКН являются Denial-of-Service атакой чистой воды (хоть и government sponsored), так что flow spec тут строго по назначению.
А в нашем кейсе — не очень представляю, куда мы его прикрутим. Опишите подробнее мысль?
Если вы РКН анонсите на BGP, то имеет смысл так же анонсить не просто IP-адреса, а более точное указание того, что РКН блочит. Вместо списка адресов — список портов, которые надо в VPN заворачивать. Флоу-спек — это не только "блочить", но и специально маршрутизировать.
Да и RouterOS 6.*, насколько я в курсе, flowspec не поддерживает.
тогда я не понимаю причин грусти на тему "ломают на L7, а чиним на L3". Если ломают на L3, то и чинить надо тоже на L3.
Реестр по сути — это (для случая блокировки к странице или к сайту, поскольку для записей блокировки IP или подсети всё очевидно) совокупность L7-записей (URL), к которым в качестве дополнительной информации Роскомнадзор прикручивает записи L3 (IP). При этом контролируется фильтрация устройствами «Ревизор», работающими также на L7, т.е. имитирующими пользователя.
Занесенные в реестр записи L3 не отличаются достоверностью. Даже если не обращать внимания на леность и ошибки сотрудников, заполняющих реестр, есть проблема с множественными IP-адресами ресурсов — например, round robin записи в DNS или использование географически распределенных CDN/DDoS protection решений. Т.е. у вас конкретный ресурс может быть доступен совершенно не на том IP, на котором он доступен у меня и у Роскомнадзора.
Поскольку операторам штрафов не хочется, они вынуждены каким-то образом решать эту проблему. Одним из путей является получение L3-информации для фильтрации непосредственно из L7-записей на фильтре. Таким образом, фильтры L3 у операторов отличаются (обычно в сторону расширения) от набора адресов в реестре и, к сожалению, с моей стороны нет технического пути определить, какие именно L3-адреса входят в список фильтрации у каждого из провайдеров РФ.
Впрочем, есть некоторая часть фильтров, работающая на анализе SNI и являющаяся таким образом true L7, но процент с внедрением ESNI/ECH TLS 1.3 неуклонно снижается и фильтрация возвращается к грубому L3.
Так что разница существует из-за разного отображения L7 в L3 в реестре и у операторов связи.
Ага. Ясно. Т.е. есть "правильный" и "работающие" варианты.
Я бы их так и отдавал. Два BGP-фида, один из них — "правильный" (какие сказали адреса, такие и фиксим), второй "работающий", который пихает в маршруты всё, что только придумается роботу по аналогии с провайдерскими.
Ну и опять же, это резолвинг одного конкретного оператора связи и в силу вышеописанных причин он будет достаточно хорош для клиентов этого оператора и существенно хуже для всех остальных.
… Кстати, если мы знаем про выкрутасы конкретных операторов, то им можно отдавать кастомизированный фид. В нормальном виде это через AS-path само случается, но у конечных пользователей нет представления о своём AS-path, так что делать по провайдерскому диапазону...
Т.е. в принципе можно было бы запилить клиента, которого надо запускать со стороны пользователя, резолвить все домены по листу и выгружать результат в BGP, но тогда и BGP логичнее с этого же клиента забирать. Такое софтовое решение реализовать не очень сложно, но нужно быть программистом, а я — не :)
router bgp 64999
synchronization
bgp router-id 000.00.00.00
bgp log-neighbor-changes
bgp bestpath aigp ignore
neighbor 163.172.210.8 remote-as 65432
neighbor 163.172.210.8 ebgp-multihop 250
neighbor 163.172.210.8 disable-connected-check
neighbor 163.172.210.8 update-source GigabitEthernet0/0
neighbor 163.172.210.8 timers 60 240 240
neighbor 163.172.210.8 route-map BGP_NEXT_HOP in
Чтобы я не делал получаю ничего:
hq-gw-01(config-router)#do sh ip bgp summa
BGP router identifier 000.00.00.00, local AS number 64999
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
163.172.210.8 4 65432 0 0 1 0 0 never Idle
Так вообще должно работать? Буду благодарен, если всевидящий All ткнет пальцем.
При этом пинг с сервиса до вашего адреса, указанного в Router ID, проходит, так что сослаться на отсутствие маршрута не получится. Может быть, у вас ACL на внешнем интерфейсе блокирует трафик 179/tcp?
Ой наврал acl in есть но такой:
10 deny ip 37.49.230.0 0.0.0.255 any log (176 matches)
20 deny udp 37.49.230.0 0.0.0.255 any log
30 deny udp any host 185.60.44.99 eq domain (663 matches)
40 deny udp any host 185.60.44.99 eq 5353 (167 matches)
50 deny tcp any host 185.60.44.99 eq domain (116 matches)
60 permit ip any any (563453978 matches)
А сам Gi:
interface GigabitEthernet0/0
description ISP-GORKOM
ip address dhcp
ip access-group ACL-GLOBAL-IN in
no ip unreachables
no ip proxy-arp
ip accounting output-packets
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly in
ip route-cache same-interface
ip route-cache policy
load-interval 30
duplex auto
speed auto
no cdp enable
crypto map MAP-VPN-HQ
Во первых Маршрут по умолчанию для соседей(по белому ип) не работает. нужно обязательно прописывать статический маршрут руками.
Во вторых кошка на столько офигела от нагрузки — что до сих пор (уже 5-7 минут) едва дышит
CPU utilization for five seconds: 99%/11%; one minute: 99%; five minutes: 93%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
180 561000 6243 89860 57.52% 58.91% 58.04% 0 BGP Router
155 128348 5401 23763 27.72% 25.22% 18.88% 0 BGP Scheduler
Upd. З.Ы. Во втором пункте была виновата команда debug ip bgp )))
«Теоретически» потому, что в последнее время в списке появилось что-то, что роняет мне плагин на макбуке (а в windows не роняет). Ну и еще один нюанс есть — в списке url есть в частности youtube, это немного затрудняет пользование :)
Вообще, конечно, в списке 90% записей — мусор, никому даром не нужный. Вариант с BGP появился для решения проблем, которые РКН создал бизнесу, начав блокировать Телеграм крупными IP-префиксами, типа /10, что накрыло AWS и прочие полезные сервисы, сами по себе в реестре не находящиеся.
Для текущей более-менее спокойной ситуации вполне достаточно SwitchyOmega и создаваемых вручную правил в нем, благо их можно одним кликом добавлять. Попытались зайти на нужный сайт, увидели попытку переадресации на страницу блокировки — кликнули мышью и пошли через прокси.
А про то, что провайдер блочит по IP — тут есть нюансы, я вот тут попробовал раскрыть логику. Так что доменные имена в целом писать в список для прокси надежнее.
Кстати, а чем вы держите bgp? bird? exa?
Exa крайне медленно всасывает список префиксов из файла. Когда их там было около 2 миллионов — этот процесс занимал более часа, при том, что список лежал на рамдиске.
Мы используем process, и, вроде, получается быстрее.
Поделитесь ссылкой, плз, интересно.
process — это название опции exa. Не из файла читать, а кормить из stdout'а дочернего процесса. https://github.com/Exa-Networks/exabgp/wiki/Controlling-ExaBGP-:-possible-options-for-process
Хотя, если у меня когда-то расправятся rust-руки, быстрый bgp-из-файла будет одним из пунктов в моём списке добра.
ЗЫ bird мы тоже юзаем, но для других целей.
У вас какой объем префиксов и за какое время залетает, не засекали?
full view, меньше 10 минут. Большей частью ограничена производительностью принимающих железок. Параллельность достигается несколькими экзами.
У меня настроено по второй статье и всё работает, но хочу попробовать перейти на bird 2.
protocol kernel {
import none;
export none;
}то теперь стало
protocol kernel {
ipv4 { import none; export none; };
}log syslog all;
router id 192.168.42.1;
protocol kernel {
scan time 20;
ipv4 {
import none;
export none;
};
}
protocol device {
scan time 60;
}
protocol static static_bgp {
ipv4 {
include "subnet.txt";
include "ip.txt";
};
}
protocol bgp OurRouter {
ipv4 {
import none;
export where proto = "static_bgp";
};
description "Our Router";
neighbor 192.168.42.10 as 64999;
next hop self;
local as 64999;
source address 192.168.42.1;
passive off;
}
Ошибка /etc/bird/subnet.txt:1:1 syntax error, unexpected ROUTE
В subnet.txt вроде бы все правильно, с bird предыдущей версии всё работало, скорее всего в конфиге что-то неправильно.
Так что в скрипте makebgp надо поменять reject на unreachable в двух местах.
На всякий случай финальный конфиг, может быть кому-нибудь пригодится:
log syslog all;
router id 192.168.42.1;
protocol kernel {
scan time 60;
ipv4 {
import none;
export none;
};
}
protocol device {
scan time 60;
}
protocol static {
ipv4;
include "subnet.txt";
include "ip.txt";
}
protocol bgp {
local 192.168.42.1 as 64999;
neighbor 192.168.42.10 as 64999;
passive off;
ipv4 {
import none;
export all;
next hop self;
};
}
Во-первых, спасибо за ваш сервис.
И кстати, раз у у вас bird, не сталкивались с тем, что при перезагрузке файла с маршрутами сессия у клиентов зависает и отваливается? (хотя кроме как на микроте я это не проверял — возможно это его косяк)
Во-вторых, отваливание сессий — как раз следствие больших размеров файла — в процессе чтения однопоточный бёрд замирает.
Поиграйте с ускорением чтения (например, с рамдиска), включением на берде graceful restart. Можно разделить на фронт и бэк (между фронтом и бэком сделать очень длинные таймауты, в бэк подсасывать файл, а с фронта коннектить клиента).
Но в целом для одного-двух клиентов вполне достаточно просто раскрутить Hold таймер куда-нибудь в небеса (синхронно с обеих сторон).
Здравствуйте, спасибо за статью! Вы ещё не экспериментировали с ROSv7? Я делал рабочую конфигурацию для третьей беты, но в четвёртой они ещё раз поменяли routing filters — https://help.mikrotik.com/docs/display/ROS/ROSv7+Basic+Routing+Examples#ROSv7BasicRoutingExamples-RoutingFilters, вообще не понимаю, как этим сделать тоже самое, что сделано в статье.
Нет, с 7 версией еще не доводилось, у меня сейчас нет подходящих тестовых железок под нее. Впрочем, описанный в хелпе синтаксис выглядит вполне логично, надо только разобраться с конкретными ключевыми словами, что как теперь записывается.
Т.е. я бы (чисто из головы) из
/routing filter add action=accept chain=dynamic-in protocol=bgp comment="Set nexthop" set-in-nexthop=172.30.1.1сформулировал что-то типа
/routing/filter/rule
add chain=dynamic-in rule={
if true then={
ip-value set=bgp-next-hop<assign>172.30.1.1;
action accept;
}
}Но это исключительно из логики построения, сами ключевые слова надо в командной строке смотреть. Если когда-нибудь доберутся руки до v7 — проверю.
Думаю как то так. (добавилась роль BGP) в нашем случае это ebgp , внешняя
/routing bgp template add name="antifilter" ignore-as-path-len=yes routing-table=main as=64512 multihop=yes hold-time=4m keepalive-time=1m input.filter=bgp_in
/routing bgp connection add name="antifilter_bgp" remote.address=163.172.210.8/32 local.address=---впн адрес локальный ваш--- router-id=ваш ип роутера templates=antifilter
Дело полезное, спасибо. Но если раньше приходилось изредка руками добавлять маршруты для заблокированных сайтов, то теперь теперь приходится прям по несколько раз за день добавлять исключения для узлов, которые ошибочно входят в раздаваемые подсети.
РКН вообще к списку IP относится спустя рукава и пишет туда достаточно часто всякую фигню. Увы, пока другого источника нет.
Идея, как сделать ситуацию принципиально лучше, у меня есть, но для этого нужен фронтендер, который напишет интерфейс. Несложный, но чуть выше уровня моего неумения в вебдизайн. Если кому-то интересно поучаствовать - велкам в личку.
После обновления с 6.49.3 на 7.1.3 немножко всё сломалось.
Маршруты по BGP получались, фильтр отрабатывал, но трафик шел напрямую.
В новой версии фильтр преобразовался в такую конструкцию:
/routing/filter/rule> print
Flags: X - disabled, I - inactive
0 ;;; Set nexthop to VPN
chain=bgp_in rule="set gw-interface moy-vpn; accept;"
В итоге маршруту ставился gateway не vpn, а ether1 (обычный интернет).
Погуглил, поменял gw-interface на просто gw и всё заработало.
"set gw moy-vpn; accept;"
Конфиг для микротика с 7й прошивкой:
/routing bgp template
add as="ВАША ВЫДУМАННАЯ AS БЕЗ СКОБОК" disabled=no hold-time=4m input.filter=bgp_in .ignore-as-path-len=yes keepalive-time=1m multihop=yes name=antifilter routing-table=main
/routing bgp connection
add disabled=no hold-time=4m input.filter=bgp_in .ignore-as-path-len=yes keepalive-time=1m local.address= "ВАШ ВНУТРЕННИЙ ИП БЕЗ СКОБОК" .role=ebgp multihop=yes name=antifilter_bgp remote.address=45.154.73.71/32 .as=65432 router-id="ВАШ ВНЕШНИЙ ИП БЕЗ СКОБОК" routing-table=main templates=antifilter
/routing filter rule
add chain=bgp_in disabled=no rule="set gw *9; accept;" <<<===Вот тут по поводу *9 я не уверен. У емня вместо *9 название VPN интерфейса, но в конфиге именно так.
Пытаюсь нагуглить, как скормить маршруты роутеру Asus на прошивке merlin.
У кого-нибудь был такой опыт?
Теоретически туда можно bird поставить через entware, но его ещё настроить надо как-то.
Или, например, мой роутер коннектится через openvpn к VPS, который ему может скормить маршруты(ещё не факт, что роутер их съест правильно) + чтобы их обновить, это придётся переподключится по vpn.
bird сам по себе настраивается несложно (выше по тексту есть примеры конфигов), если он у вас заработает в merlin. Там есть какие-то тонкости с тем, чтобы он в принципе поднялся и начал слушать сеть, и конкретно эти тонкости лучше обсудить с пользователями этой фирмвари (я был, но очень давно).
Есть еще некоторые подозрения, что асусу может не хватить процессора или памяти, всё-таки bgp - достаточно ресурсоемкий протокол.
В целом в текущей ситуации, к сожалению, обход блокировок РКН у большинства уже перестал быть основной целью наличия VPN, поэтому и сервис в виде динамически меняющегося списка IP стал менее полезным. Для абсолютного большинства пользователей самым подходящим сейчас считаю прописать через туннель "всё, кроме РФ" (т.е. держать список российских IP статическими маршрутами в оператора, а в VPN отправлять дефолт) и отдельно корректировать то, что при этом через VPN работает хуже.
У меня Asus RT-AX86U достаточно мощный, даже не знаю, что ещё есть более мощное в этом сегменте.
Короче, я настроил в принципе. За основу взял настройку для keenetic - https://keenetic-gi.ga/2019/01/22/bgp_routing.html
Всё тоже самое: ставится entware, потом bird, который слушает маршруты через VPN с удаленного VPS.
Единственное, пока не нашёл, как сделать, чтобы после поднятия OpenVPN запускался скрипт добавления маршрута и при этом всё работало(если добавить в конфиг openvpn вызов скрипта up/down, то почему-то вообще ничего не работает). Для keenetic там скрипты можно положить в /opt/etc/ndm/, а в асусе такого нету. Но в целом некритично, т.к. роутер практически не перезагружается и на крайняк можно пока что по ssh зайти и запустить руками. Будет время ещё поковыряю, плюс нужно ещё будет зону .lib подключить, пока тоже не было времени разобраться как.
А почему обход блокировок перестал быть основной целью? Весь зарубежный трафик гонять через VPN не хочется, особенно контент. Просто заметно медленней работает.
Весь зарубежный трафик гонять через VPN не хочется, особенно контент. Просто заметно медленней работает.
работаю в таком режиме с августа, vps в nl, вообще никакой разницы не замечаю.
разве что ютуб нидерландскую рекламу показывает.
Я пробовал разные vps и я разницу вижу, особенно во всяком телеграме, ютубе, там где загрузка контента.
Был leaseweb, contabo(который, кстати, кинул всех российских клиентов на бабки просто так, перед этим попросив залить туда денег побольше на всякий случай), потом всякие разные другие, которые можно оплатить через криптовалюту.
ну не знаю, вот только что снял:
https://www.speedtest.net/result/14165298599
вам 100+ мегабит недостаточно для ютуба?
и по задержкам: de facto весь зарубежный трафик идёт через европу, сама европа не такая уж и большая, так что в случае расположения vps с vpn в хорошем датацентре задержка увеличится не так уж и сильно.
Если на VPS канал +- такой же как у тебя дома, то даже чисто теоретически уже половину канала ты потеряешь.
Ну и, видимо, не вытягивает VPS OpenVPN что ли(скорость через VPN ниже в 8-10 раз):
Из консоли VPS:
speedtest --server 5252
Retrieving speedtest.net configuration...
Testing from Host Sailor Ltd (xxx)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by signetbreedband (Arnhem) [91.51 km]: 7.301 ms
Testing download speed................................................................................
Download: 675.43 Mbit/s
Testing upload speed......................................................................................................
Upload: 416.29 Mbit/sИз дома через OpenVPN через VPS:
$ speedtest --server 5252
Retrieving speedtest.net configuration...
Testing from Host Sailor Ltd (xxxx)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by signetbreedband (Arnhem) [91.51 km]: 191.321 ms
Testing download speed................................................................................
Download: 50.98 Mbit/s
Testing upload speed......................................................................................................
Upload: 51.82 Mbit/sИз дома без VPN:
$ speedtest --server 6827
Retrieving speedtest.net configuration...
Testing from Beeline Home (yyyy)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by MGTS (Moscow) [0.38 km]: 13.348 ms
Testing download speed................................................................................
Download: 464.92 Mbit/s
Testing upload speed......................................................................................................
Upload: 461.67 Mbit/s
Тариф за 7 баксов в месяц вот такой:
SEAMAN
RAM 1GB
VSwap 1GB
RAID10 storage 30 GB HDD
NL Processor E5-2620 v3 & E5-2620 v4 & X5650 & Silver 4108
RO Processor E5-2620 v3
Cores 4
IPV4 Addresse(s) 1
IPV6 Addresse(s) /64
Bandwidth 1TB
Network Speed 1Gbit
RO DDoS protection 20Gbps
NL DBC/DBA Protection Optional
NL GreenDatacenter DDOS Protection 20Gbps
Control panel SolusVM
Location Netherlands/Romania
Подумываю, чтобы пустить трафик без шифрования как-то.
На contabo за те же деньги был VPS покруче и в плане проца и памяти вроде 8Гб было и там ситуация была получше, конечно, но всё равно скорость ощутимо ниже.
Видимо, шифрование сжирает весь процессор, хотя по мониторингу этого не видно.
Если на VPS канал +- такой же как у тебя дома, то даже чисто теоретически уже половину канала ты потеряешь.
нет, конечно же. если всё нормально работает, то в скорости фактически не теряешь, немного теряешь в latency (и из-за этого tcp-сессии будут разгоняться до максимальной скорости чуть дольше)
Подумываю, чтобы пустить трафик без шифрования как-то.
тест выше был сделан через wireguard, но и через openvpn 100+ получается.
NL Processor E5-2620 v3 & E5-2620 v4 & X5650 & Silver 4108
x5650? погуглите какого это года процессор )
есть подозрение, что у этого провайдера на всём экономят, линки/процы перегружены.
Ну мне надо было на что-то срочно перейти за несколько дней, когда контабо предупредил, чтобы разорвет контракт. И это не первый вариант, кстати, первый совсем плохой был на OpenVZ, но совсем дешевый зато)
А какой VPS есть кошерный, только чтобы криптовалюту принимал или любым другим способом платежи из России? Вы каким пользуетесь для VPS?
Вообще есть подозрение, что проблема в настройке OpenVPN, я поковырял пару часов, отключил шифрование, сжатие, попробовал разные сетевые настройки. Самое смешное, что скорость только ниже стала. Притом скорость на UDP раза в 2 меньше, чем на TCP.
Надо будет это дело доковырять...
А почему обход блокировок перестал быть основной целью?
Потому что (во всяком случае у меня и многих других) vpn теперь нужен в основном не для доступа до заблокированного РКН контента, а для доступа до заблокированных для России ресурсов. Списка которых в блеклисте РКН, разумеется, нет.
Верно, а есть такой конфиг?
Сходите в чатик при antifilter.download - там, скорее всего, найдется кто-то, кто это уже реализовал.
В текущей бета версии ROS 7.16b3 завезли
*) dns - added support for DoH with static FWD entries;
и это работает!
Добавить можно даже и лучше DoH:
/ip/dns/static add address-list=to_vpn forward-to=https://1.0.0.1/dns-query match-subdomain=yes name=site.org type=FWDТак же можно форвардить на localhost, если DoH уже настроен как основной.
Настройка BGP для обхода блокировок, версия 3.1. И немного Q&A