Зачем всё это делается в принципе и как оно устроено логически — описано в первой и второй статьях.
После их публикации я получил несколько вопросов от людей, которые пользуются VPN с не принадлежащих им ресурсов (например, приобретающих коммерческую услугу VPN). Этим людям раньше я советовал завести VPS для развертывания BGP-сервиса или каким-то еще образом получить доступ к серверу на Linux.
Но с сегодняшнего дня для них (и для всех остальных) есть более удобный вариант — на бесплатном сервисе antifilter.download появилась возможность автоматически настраивать BGP-сессию с вашим маршрутизатором.
Для его использования вам необходимо иметь всего лишь:
фиксированный маршрутизируемый IP-адрес (т.н. "белый". Он может выделяться динамически, но должен быть всегда одним и тем же);UPD. Уже не важно, см. ниже по тексту.- маршрутизатор с поддержкой протокола BGP (в статье, традиционно, пример построен на базе RouterOS маршрутизаторов Mikrotik);
- уже настроенный туннель VPN с этого маршрутизатора.
Умолчания в тексте статьи
- имя интерфейса туннеля на маршрутизаторе — gre-tunnel1
- номер автономной системы с вашей стороны — 64512 (выбираете сами в соответствии с RFC6996 — из диапазона 64512-65534 включительно).
- внешний IP-адрес вашего маршрутизатора — 81.117.103.94
Последовательность действий, если вы хотите управлять сервисом и у вас есть фиксированный маршрутизируемый IP-адрес
Делаем раз
заходим из вашей сети (это важно) на сайт antifilter.download, проматываем до раздела BGP, нажимаем "Активировать управление BGP".
Делаем два
проверяем, что сайт показывает именно наш IP, вводим выбранный номер своей автономной системы, помечаем чекбоксы, какие именно маршруты отдавать, подтверждаем капчу, нажимаем "Создать пиринг". После этого сайт покажет, что для вашего адреса настройки существуют. Время применения настроек в сервисе — не более 5 минут.
Делаем три
заходим на свой маршрутизатор Mikrotik и настраиваем на нем BGP-пиринг с сервисом:
/routing bgp instance set default as=64512 ignore-as-path-len=yes router-id=81.117.103.94
/routing bgp peer add in-filter=bgp_in multihop=yes name=antifilter remote-address=192.3.134.152 remote-as=65432 ttl=default
/routing filter add action=accept chain=bgp_in comment="Set nexthop to VPN" set-in-nexthop-direct=gre-tunnel1Не забываем поменять умолчательные AS, IP и имя интерфейса на ваши. В вышеприведенных командах должно быть сделано три замены — не больше и не меньше.
… и всё работает
Если с момента нажатия кнопки "Создать пиринг" прошло более 5 минут и вы всё правильно настроили — у вас уже всё работает.
Если вы захотели поменять список выгружаемых в вашу сторону префиксов — это делается через удаление настроек на веб-странице и создание их вновь, благо — из настроек там одно число и три галочки.
Префиксы от сервиса маркируются соответствующими комьюнити, поэтому если захочется строить более сложные правила обработки — всё в ваших руках.
Настоятельно не рекомендую подключать список одиночных IP — даже топовым SOHO-маршрутизаторам Mikrotik от него не очень хорошо, а средние, например hAP lite, ведут себя крайне непредсказуемо.
UPD. Последовательность действий, если у вас нет фиксированного IP или вас устраивают настройки по умолчанию
Делаем раз
заходим на свой маршрутизатор Mikrotik и настраиваем на нем BGP-пиринг с сервисом:
/routing bgp instance set default as=64999 ignore-as-path-len=yes router-id=81.117.103.94
/routing bgp peer add in-filter=bgp_in multihop=yes name=antifilter remote-address=192.3.134.152 remote-as=65432 ttl=default
/routing filter add action=accept chain=bgp_in comment="Set nexthop to VPN" set-in-nexthop-direct=gre-tunnel1Не забываем поменять умолчательные router-id и имя интерфейса на ваши. В вышеприведенных командах должно быть сделано две замены — не больше и не меньше. В качестве router-id можете написать в принципе любое шестнадцатибитное число в формате IP-адреса, но чтобы не вызвать спецэффектов при совпадении, я бы рекомендовал использовать ваш текущий внешний IP-адрес. При его изменениях менять его необходимости не будет.
Номер AS в этом случае фиксированный, как и набор анонсируемых префиксов (ipsum+subnet), если кому-то этого чересчур много — всегда можно при приеме фильтровать по комьюнити или другими способами манипулировать анонсами.
… и всё работает
Если после активации настроек на вашем роутере прошло более 5 минут и вы всё правильно настроили — у вас уже всё работает.
При смене IP-адреса сессия будет восстанавливаться ориентировочно в течение 5 минут.
Заключение
Да, я понимаю, что уже "горшочек, не вари", и надеюсь, что на этом для меня тема обхода блокировок закрыта.
На вопросы в комментариях, традиционно, отвечу, с настройкой помогу.
Комментарии (44)
haos
03.06.2018 15:14Спасибо!
Выбрал полный список, прилетело 100к+ маршрутов. Mikrotik CCR1009 впал в ступор(с отвалом WinBox) на 2 минуты потом полет нормальный.Furriest Автор
03.06.2018 15:28Пожалуйста.
Там, кстати, неочевидно — список subnet в любом случае имеет смысл забирать тоже, пусть вместе со списком хостов. Потому что они не полностью взаимно перекрыты. Т.е. в вашем случае лучше ставить первую и третью галки.
pha
03.06.2018 17:54Кстати, ввиду последней тактики РКН «забанил 1000 ip, а потом через 15 минут разбанил почти всё» имеет смысл юзать список с /24 подсетями, а не со 100к единичных ip.
Там все равно баны и разбаны по одним и тем же подсетям идут, к тому же не известен «лаг провайдера», как быстро он получает и применяет правила.zikasak
03.06.2018 18:47Да, можно и так. Но тут еще могут некоторые ограничения вылезти. Например, IP моего VPS забанен на одном нужном ресурсе (к сожалению, обнаружил слишком поздно). А IP ресурса попадает как раз в одну из /24 подсетей… А желания писать дополнительную программу, которая будет исключать из списка подсетей эти IP у меня нет. Тут-то полная выгрузка и помогает.
Furriest Автор
04.06.2018 08:31Тут можно не дополнительную программу, а просто статический маршрут на своем роутере на этот IP через ваш дефолт. Статика всегда победит динамику, если не принять для обратного специальных мер.
ValdikSS
04.06.2018 11:39+1Я на антизапрете для VPN сделал собственный DNS-сервер, который, при попытке резолва зоны заблокированного домена, добавляет в iptables соответствие (маппинг) свободного адреса из внутреннего выделенного диапазона в настоящий IP-адрес, и отдает клиенту адрес из внутреннего диапазона.
Т.е.
Клиент: rutracker.org? Сервер: rutracker.org? 195.82.146.214! 10.224.0.1>195.82.146.214 Клиент: rutracker.org>10.224.0.1
Такой способ работает с «неправильными» DPI, которые блокируют всю доменную зону целиком, а не только заблокированный домен (блокируется *.domain.com, если в реестре есть только domain.com, такое, например, у Yota), работает с доменами, которые ротируют IP-адреса с целью обхода блокировок, а также не создает проблем при частом обновлении адресов.
zikasak
03.06.2018 15:57-1А как сервис переживает динамические IP-адреса у клиентов? Если вдруг оператор поменяет IP — все отвалится?
Furriest Автор
03.06.2018 16:30Да, bgp хочет связки с IP.
Можно, если vpn со статикой, делать пиринг прямо через туннель, с того адреса (для этого надо сначала статикой прописать маршрут на сервис через туннель). А вот если ни там, ни там — тогда печаль.
pha
03.06.2018 17:29Почему-то с роутера пингуется запрещенка, а с компьютера нет.
Что может быть?pha
03.06.2018 17:51Разобрался.
Заголовок спойлеране все костыли убрал после «обычного списка ip и mangle правила, с проставлением routing mark».
В masquerade правиле был фильтр по routing mark.achekalin
03.06.2018 18:20Спасибо за сервис!
А вот зачем загружать себе список отдельных IP — «шоб было», because I can?
Технически даже если, скажем, в черном списке один адрес из /24 подсети, а трафик полетит через ВПН для всей этой подсети, сильно большой проблемы, наверняка, не будет. Зато маршрутизатору будет полегче, факт.
Хотя я понимаю владельцев CCR1009 железок: имея (при такой-то цене!) 2 Гб ОЗУ, прямо уже не знаешь, на что их потратить еще (там FV помещается много десятков раз, не то что список блокировок. Но — чем больше список, тем больше вынужден «думать» над ним ЦП роутера, а это не всегда то, за чем следует гнаться).
Пользуясь случаем: никто не знает, что за туннельный брокер ipv6.ip4market.ru? Очень они вовремя появились!Furriest Автор
03.06.2018 18:56У каждого свои хотелки по дискретности, потому что свои модели использования. Большой список можно суммаризовать и фильтровать по желанию на своем конце, а из суммаризованного отдельные уже не выковыряешь. Поэтому пусть будут возможности для всех.
Про брокера — есть такая компания, торгует адресами по ценам повыше рынка. На хайпе решили использовать часть своего пула IPv6 для такого вот сервиса. У всех брокеров 6in4 не рядом с тобой одна проблема — резкий рост латентности, потому что оно сначала должно по v4 до него долететь, а уже потом начинается выбор оптимальных маршрутов и прочие вкусности. Если вы недалеко от их точки терминации — удобно. Мне 75 мс до них, долго.achekalin
03.06.2018 19:04Потому и спросил, что мне до них «ближе», чем до he.net-овских точек приземления. С другой стороны, he.net работает давно и надежно, а здесь нет уверенности, что сервис не
сдуетсядеградирует, когда на него зацепятся не 5, а 50000 клиентов, и каждый из них начнет не тестовый пинг по туннелю гонять, а, спасибо слову из трех букв, через туннель будет работать со своими обычными сайтами (с теми из них, кто уже смог стать dual-stack). Что актуально, как раз самые посещаемый сайты (как Гугл, так и ВК с FB) давно уже сделали поддержку IPv6, так что на туннель может лечь приличный % от обычного потребления трафика клиентов (от профиля потребления каждого, конечно, зависит), так что как бы не оказалось, что канал(ы) брокера такой трафик просто не осилят.
Посмотрим, конечно. Тут иначе как опытом не проверить.Furriest Автор
03.06.2018 19:20Я давно завел себе v6, но серьезных всплесков трафика по нему не наблюдаю. Единицы мегабит в 5-минутном усреднении. Правда, торрент-машина у меня не дуалстек, возможно когда я рискну и туда затащить v6 — потребление подрастет.
achekalin
03.06.2018 19:23Я проверки ради конторский прокси сделал dual-stack, и наблюдаю, что чуть не 70% входящего трафика теперь приходится на IPv6. Это, конечно, от юзеров и их профиля использования зависит, но целый немаленький офис сидит.
difiso
03.06.2018 21:58У меня на RouterOS v6.42.2 (stable) почему-то долго висит в состоянии Connect. С чем может быть связано? Вроде все правильно делал. Все перерыл.
Furriest Автор
04.06.2018 03:37Возможно, у вас ip firewall настроен так, что не выпускает пакеты на неизвестный порт от роутера. Попробуйте 1) попинговать с роутера 192.3.134.152 (должен отзываться) и 2) прислать мне в личку ваш IP-адрес — можно посмотреть, что там с настройками и доступностью.
vp7
04.06.2018 20:40Очень интересная идея, вот прямо супер-мега, спасибо.
Попробовал, действительно всё поднялось почти мгновенно.
Единственное, что расстраивает — на микротике все эти адреса идут вперемешку с собственными маршрутами и банально мешаются. Да, можно отфильтровать BGP маршруты, но это тоже не то.
Сейчас на микротике использую AddressList, mark routing/connection + routing mark в таблице маршрутизации. Но у меня в bypass'е в VPN настроено буквально десяток адресов тех ресурсов, которые мне нужны.
Никто не в курсе, насколько вариант с маркировкой mark connection кушает больше ресурсов по сравнению с прогрузкой таблицы маршрутизации для VPN bypass'а? У меня относительно старый RB951G, но его до сих пор хватает на все задачи (кроме WiFi 5G, которого у него нет).
maxman
05.06.2018 03:32Роутер 951G-2HnD. 13+к BGP маршрутов держит играючи, сильного потребления оперативки не замечено, лагов с установлением соединения не наблюдается. В целом это более удачное решение (BGP) чем Layer 7 -> Address list -> mark connection -> mark routing -> route routing mark
vp7
05.06.2018 10:19Есть предложение по улучшению сервиса и отвязки от необходимости иметь статический IP адрес на стороне клиента:
Поднять VPN сервер, на нём выдавать статические серые IP адреса и поднимать пиринг с этими адресами. Через VPN пропускать только BGP трафик до роутера.
В этом случае клиент с динамическим белым или даже с динамическим серым IP сможет воспользоваться этим сервисом:
— одна VPN сессия для поднятия BGP сессии
— вторая VPN сессия для терминации трафика через альтернативный маршрутFurriest Автор
05.06.2018 10:36Проблему владельцев динамики этот вариант решит, да. Но не уверен, что она настолько массовая, чтобы строить такие конструкции. Неизящно и много шевелений с клиентской стороны требует, а значит и квалификации.
Красивым решением было бы переписать часть кода bird, чтобы он просто устанавливал BGP сессию с любым ее запросившим динамически, так, как будто она уже сконфигурирована. Однако тут моих способностей точно не хватит.
Если попадется грамотный сишник, желающий поучаствовать — допилим.vp7
05.06.2018 11:03Проблему владельцев динамики этот вариант решит, да. Но не уверен, что она настолько массовая, чтобы строить такие конструкции. Неизящно и много шевелений с клиентской стороны требует, а значит и квалификации.
Очень даже массовая. Физикам крайне редко бесплатно дают статические белые IP адреса. Либо плати денежку, либо опция вообще не предусмотрена.
Дома я плачу 150 руб/мес за статический IP, у родителей провайдер вообще не предоставляет такой опции.
Красивым решением было бы переписать часть кода bird, чтобы он просто устанавливал BGP сессию с любым ее запросившим динамически, так, как будто она уже сконфигурирована.
Можно сделать финт — ловить все попытки установления сессии (да хоть wireshark'ом декодировать пакет) и на их основе прописывать пира в конфиге bird'а.Furriest Автор
05.06.2018 11:38Про финт понимаю, возможно. Но для его реализации в продакшн всё равно нужно реализовывать какой-то проксирующий сервис. Если даже принимать сессии можно через netcat, то всю остальную обработку реализовать (если нет конфига — создать, если есть — просунуть сессию в bird) я так сходу и не придумаю как. Без кодера не обойтись.
vp7
05.06.2018 12:33+1Зачем проксировать?
Клиент же постоянно делает повторные попытки переподключения.
В пассивном режиме прослушивать трафик tshark'ом и им же декодировать в любом удобном формате (можно нужные поля в тексте, можно даже в JSON'е).
Отдельным скриптом-демоном принимать входящий поток, вытаскивать оттуда IP адрес пира и проверять наличие пира в конфиге bird'а. Если пира нет, то добавлять в конфиг и делать bird'у reload.
Сейчас у вас уже есть скрипт, который добавляет пира в конфиг bird'а на основе HTTP запроса на страницу, нужно будет его буквально совсем чуть-чуть модифицировать и всё готово :)Furriest Автор
05.06.2018 14:17Спасибо за идею, натолкнула на мысль покопаться в дебаге bird'а. Как найду пару часов (вероятнее всего на ближайших выходных) — попробую реализовать схему.
Для таких клиентов, очевидно, выбирать, что именно анонсировать, не получится, поэтому для них будет дефолтный номер AS и дефолтный набор из суммаризованных хостов+подсетей.
Furriest Автор
06.06.2018 12:37Вроде бы и с динамических адресов теперь всё работает и можно пользоваться, смотрите апдейты по тексту статьи.
nestyurkin
05.06.2018 18:45решение для динамических IP, опробовано на hac2 сегодня
/ip route
# роутить трафик до своего VPS напрямую (мой случай когда VPS не заблокирован, но прилетает подсеть /19 от BGP)
add distance=1 dst-address=YOU_VPS_IP/32 gateway=rostelecom
# путь до antifilter.download чтобы зарегить пир BGP
add comment=antifilter distance=1 dst-address=192.3.134.152/32 gateway=ovpn-linode
# добавить hold-time=4m для соответствию удаленному пиру и чтобы в лог ошибки не валились
/routing bgp peer
add hold-time=4m in-filter=bgp_in multihop=yes name=antifilter remote-address=192.3.134.152 remote-as=65432 ttl=defaultFurriest Автор
05.06.2018 18:56В этом случае требуется, чтобы у вас был статический IP на VPS, где вы терминируете туннель. Мы обсуждали ситуацию, в которой собственной VPS нет, туннель берется у стороннего VPN-сервиса и там тоже выделяется серый адрес под NAT или динамика. В этом случае просто нет IP, который будет одинаков всё время существования стыка.
nestyurkin
05.06.2018 19:44ну тогда потребуется маленький скрипт с вашей стороны
чтобы при поднятии туннеля дергать его с микротика например так:
/tool fetch antifilter.download/add_me_to_peers/?list=2&list=1&key=blabla
и добавлять IP в пиры bird
а в самом микротике при поднятии vpn
/routing bgp instance set default router-id=VPN-IP
конечно тут нужно отслеживать поднятие туннеля и поиск VPN-IP — но это решаемоFurriest Автор
05.06.2018 20:17Я думаю, что описанный чуть выше в треде вариант — когда со стороны сервиса детектируется попытка присоединения и под нее создается конфиг — наиболее комфортен для использования большинству потенциальных пользователей. Попробую его реализовать, если не получится — можно будет перейти к сервису, аналогичному DDNS по принципу работы.
Sir_Prikol
05.06.2018 18:45Всё хорошо, всё отлично, вот только при наличии 2-х и более провайдеров эта задумка не имеет смысла. Стандарт BGP требует минимум 2-х пиров для успешной реализации. Да, для обычного домашнего пользователя — ситема работать будет (немного подшпмпнить с фильтрами и вуаля), но для использования с несколькими провайдерами (у меня их 3 на входе и все с белыми IP) начинается переколбашивание сети. Необходимо подключать других пиров, но нельзя, так как со стороны antifiltr только одна AS.
Furriest Автор
05.06.2018 18:51Вы можете легко управлять маршрутизацией по провайдерам со своей стороны. Рассматривайте этот пир только как источник префиксов, но не как источник дестинейшнов. Для выбора дестинейшна можно устраивать на своем маршрутизаторе раут фильтры любой сложности, проверяя доступность и прочие параметры.
Если же вы про то, что при падении одного провайдера вам нужно пириться с другого — так и тут все элементарно просто. Наличие одной AS с противоположной стороны никоим образом не мешает, просто вам нужно последовательно настроить отдельные сессии с каждого из ваших IP (например, перекладывая статику на antifilter в разные интерфейсы). Тогда одна из сессий всегда будет поднята. Только включайте периодически другие адреса (опять же, можно статикой), потому что настройки пиров, с которыми сессий не было более 3 месяцев, будут удаляться.Sir_Prikol
05.06.2018 19:00В моей конфигурации, когда используется loadbalancing на двух одинаковых каналах и третий как резервный (через него только при падении двух основных) Данная схема нереализуема без появлкния нормальных пиров. Источник префикса, повторюсь, хорош для одного прова, для двух и более — только адресслист. Да и нагрузка меньше. Плюс, каким образом вы промаркируете маршруты с одной BGP сессии на второго провайдера. Это не реально, сам протокол этого не позволяет. Только несколько пиров позволит нормально маркировать маршруты и пользователь сможет ходить.
Я не говорю что данная конфигурация не жизнеспособна. Она не жизнеспособна в моём конкретном случае.Furriest Автор
05.06.2018 19:24Я не понимаю, что конкретно вы не можете реализовать с одним источником? Вам в любом случае надо заворачивать трафик на эти адреса в туннель — у вас несколько туннелей или один перестраивается через разных провайдеров? В обоих случаях можно реализовать их использование. В первом случае вам, например, поможет рекурсивный роут на некстхоп, во втором вообще ничего дополнительного реализовывать не надо.
Опишите подробнее пример, какая именно ситуация у вас не реализуется?Sir_Prikol
05.06.2018 19:31Схема в двух словах:
3 uplink
1 ovpn tunnel
Это основной маршрутизатор.
За ним клиенты будут ходить по Вашей схеме — почти без проблем, ну некоторые адреса всё равно не открываются. Мелочи, подмену DNS в этом случае ни кто не отменял (при условии глубокого dpi)
Но, при вашей схеме сам рутер не может отрезолвить нужные параметры и уйти через нужные маршруты, ибо в прерутинге нет понятия префикса. Через адреслист — проблем нет, прерутинг работает. И ни одного сбоя по проблемным сайтам. Заворачивает как надо. Причём, я смотрю лог маршрутизации, да, он уходит куда надо, в нужный интерфейс, но тут-же прилетает ответ от провайдера, что ресурс закрыт. При использовании адреслиста такой проблемы нет.
Ради хохмы (чтоб убедиться что я не накосячил) поднял разные BGP сессии на свои сервера. И, как я и говороил, при наличии 2-х и более провайдеров просто необходимо использовать несколько пиров. Просто так префиксы не передать. И сам маршрутизатор не будет ходить на заблокированные адреса.Furriest Автор
05.06.2018 20:07Всё равно не совсем понимаю. Вы про то, что рутер не может обнаружить, что какие-то адреса не открываются, несмотря на то, что трафик на них уходит в туннель, и перемаршрутизировать их в другое место (какое другое, другой туннель?)? Что вы подразумеваете под «отрезолвить нужные параметры»? Какие параметры нужные — опишите, пожалуйста, подробнее.
Проблемы с операторской подменой DNS решаются использованием внешних DNS-серверов (гугл, cf и т.п.) и обязательным заворачиванием их в туннель, прямо статикой.
Вопрос про «несколько пиров» мне пока тоже непонятен, я не могу разобраться, что у вас не получается с одним пиром. Конечно, не разделяя контексты маршрутизации, вы не можете поднять к одному и тому же IP две одновременных сессии с двух разных адресов — но тут ключевое слово «одновременных», а в этом применении одновременность не особо важна, время схождения BGP можно и потерпеть. Мало того, если у вас один ovpn-туннель — вы можете просто поднимать сессию с внешнего адреса туннеля (у вас же там NAT), так что при перекладывании туннеля на другого оператора у вас даже BGP развалиться не успеет.Sir_Prikol
05.06.2018 20:38Вот моя конфа:
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address-list=ddosed new-routing-mark=ddoser-route-mark passthrough=no src-address-list=ddoser
add action=mark-routing chain=output comment="Telegram (router) throuth Tor" dst-address-list=tor-traff log-prefix=telega new-routing-mark=to_tor passthrough=no
add action=mark-routing chain=prerouting comment="Email throuth ISP1" dst-port=25 in-interface=WiFi+LAN log-prefix=email new-routing-mark=route_isp_01 passthrough=no protocol=tcp
add action=mark-routing chain=prerouting comment="throuth Tor" dst-address-list=tor-traff log-prefix=tor new-routing-mark=to_tor passthrough=no
add action=mark-routing chain=prerouting comment="throuth Tor" dst-address-list=blocked-addr log-prefix=tor new-routing-mark=to_tor passthrough=no
add action=accept chain=prerouting dst-address=192.168.7.0/24
add action=accept chain=prerouting dst-address=192.168.0.0/24
add action=accept chain=prerouting dst-address=198.51.100.1
add action=mark-connection chain=input comment=PCC connection-state=new in-interface=00.pppoe-ISP01 new-connection-mark=conn_isp_01 passthrough=yes
add action=mark-connection chain=input connection-state=new in-interface=00.pppoe-ISP02 new-connection-mark=conn_isp_02 passthrough=yes
add action=mark-connection chain=input connection-state=new in-interface=09.SXT new-connection-mark=conn_backup passthrough=yes
add action=mark-connection chain=prerouting connection-state=related in-interface=00.pppoe-ISP01 new-connection-mark=conn_isp_01 passthrough=yes
add action=mark-connection chain=prerouting connection-state=related in-interface=00.pppoe-ISP02 new-connection-mark=conn_isp_02 passthrough=yes
add action=mark-connection chain=prerouting connection-state=related in-interface=09.SXT new-connection-mark=conn_backup passthrough=yes
add action=mark-routing chain=output connection-mark=conn_isp_01 new-routing-mark=route_isp_01 passthrough=yes
add action=mark-routing chain=output connection-mark=conn_isp_02 new-routing-mark=route_isp_02 passthrough=yes
add action=mark-routing chain=output connection-mark=conn_backup new-routing-mark=route_backup passthrough=yes
add action=mark-connection chain=prerouting dst-address-type=!local new-connection-mark=IT39_PCC_1 passthrough=yes per-connection-classifier=both-addresses:2/0 src-address-list=BOGONS
add action=mark-connection chain=prerouting dst-address-type=!local new-connection-mark=IT39_PCC_2 passthrough=yes per-connection-classifier=both-addresses:2/1 src-address-list=BOGONS
add action=mark-routing chain=prerouting connection-mark=IT39_PCC_1 new-routing-mark=IT39_1 passthrough=yes src-address-list=BOGONS
add action=mark-routing chain=prerouting connection-mark=IT39_PCC_2 new-routing-mark=IT39_2 passthrough=yes src-address-list=BOGONS
add action=mark-connection chain=prerouting connection-mark=no-mark new-connection-mark=oTher passthrough=yes
/ip route
add comment="Local IP throught Tor" distance=1 gateway=00.to-Pi routing-mark=to_tor
add distance=1 routing-mark=ddoser-route-mark type=blackhole
add check-gateway=ping comment=PCC distance=1 gateway=00.pppoe-ISP01 routing-mark=route_isp_01
add check-gateway=ping distance=1 gateway=00.pppoe-ISP02 routing-mark=route_isp_02
add check-gateway=ping comment=BACKUP distance=1 gateway=198.51.100.1 routing-mark=route_backup
add check-gateway=arp distance=1 gateway=00.pppoe-ISP01 routing-mark=IT39_1
add check-gateway=arp distance=2 gateway=00.pppoe-ISP02 routing-mark=IT39_1
add check-gateway=arp comment=BACKUP distance=3 gateway=198.51.100.1 routing-mark=IT39_1
add check-gateway=arp distance=1 gateway=00.pppoe-ISP02 routing-mark=IT39_2
add check-gateway=arp distance=2 gateway=00.pppoe-ISP01 routing-mark=IT39_2
add check-gateway=arp comment=BACKUP distance=3 gateway=198.51.100.1 routing-mark=IT39_2
add comment="Local IP to backuplink" distance=1 gateway=198.51.100.1 routing-mark=to_backuplink
add check-gateway=arp distance=1 gateway=00.pppoe-ISP01
add check-gateway=arp distance=2 gateway=00.pppoe-ISP02
add check-gateway=arp distance=3 gateway=198.51.100.1
add distance=1 dst-address=198.51.100.0/24 gateway=198.51.100.1 pref-src=198.51.100.254 scope=10
/ip route rule
add action=lookup-only-in-table dst-address=149.154.167.220/32 interface=00.to-Pi routing-mark=to_tor table=main
add action=lookup-only-in-table routing-mark=ISP1 table=ISP1
add action=lookup-only-in-table routing-mark=ISP2 table=ISP2
При такой конфигурации работает всё.
Когда переделываю на получение префиксов от BGP то работает всё только через того провайдера, на котором поднята BGP сессия, не смотря на то, что я маркирую пакеты от на конкретный маршрут. При поднятии 2-х пируов — всё работает с маркировками.Furriest Автор
06.06.2018 08:09Теперь я понял, вы пытаетесь совместить и классическую маршрутизацию, и маршрутизацию на уровне файрвола по раут маркам.
Поскольку это разные уровни модели — там надо внимательно просчитывать, в какой последовательности маршрутизатором будут приниматься решения о дестинейшне для пакета.
Так что вам лучше либо оставить эту схему и прогружать в нее адрес-листы с сайта через API микротика (тоже вполне себе решение), либо полностью переходить на маршрутизацию на L3 и делать балансировку вариацией nexthop в таблице маршрутизации.
maxman
05.06.2018 22:35Расскажите пожалуйста поподробней про настройки. Почему рекомендуются суммаризованные хосты+подсети? Подсети не перекрывают и расширяют суммаризованные хосты?
Furriest Автор
06.06.2018 12:42Подсети — это отдельная сущность в блеклисте РКН, они специально для этого изобрели новый тэг в своем xml. В какой-то момент им просто захотелось банить сразу подсетями.
Хостовые адреса — это те, которые РКН пишет в соответствующем поле рядом с доменными именами. Тут есть нюанс, что если у вас этот же хост разрезолвится в другой адрес — трафик к нему пойдет не через туннель и, соответственно, попадет в фильтры вашего провайдера. Но пытаться решить эту проблему на L3 — неэффективно, она уже решается через доступ к хостам через прокси в браузере (всякие там SwitchyOmega и подобные плагины).
Polyuretan
Сколько памяти займут 13 тысяч префиксов на микротике?
zikasak
на hap ac2 у меня после подключения BGP свободная оперативка уменьшилась на мегабайт 40. Правда после перехода на полную выгрузку дополнительно ушло лишь 10.
Furriest Автор
На hap ac у меня сейчас свободно 51.1 MB из 128. При задизабленном BGP (т.е. процесс в памяти, но префиксы не подгружены) — 53.8 свободно. Так что не в памяти там проблемы :)