Настройка BGP для обхода блокировок, версия 3, без VPS

Да, можно и так. Но тут еще могут некоторые ограничения вылезти. Например, IP моего VPS забанен на одном нужном ресурсе (к сожалению, обнаружил слишком поздно). А IP ресурса попадает как раз в одну из /24 подсетей… А желания писать дополнительную программу, которая будет исключать из списка подсетей эти IP у меня нет. Тут-то полная выгрузка и помогает.

UPD. Уже исправлено, работает с динамикой, см. текст статьи.

Потому и спросил, что мне до них «ближе», чем до he.net-овских точек приземления. С другой стороны, he.net работает давно и надежно, а здесь нет уверенности, что сервис не сдуется деградирует, когда на него зацепятся не 5, а 50000 клиентов, и каждый из них начнет не тестовый пинг по туннелю гонять, а, спасибо слову из трех букв, через туннель будет работать со своими обычными сайтами (с теми из них, кто уже смог стать dual-stack). Что актуально, как раз самые посещаемый сайты (как Гугл, так и ВК с FB) давно уже сделали поддержку IPv6, так что на туннель может лечь приличный % от обычного потребления трафика клиентов (от профиля потребления каждого, конечно, зависит), так что как бы не оказалось, что канал(ы) брокера такой трафик просто не осилят.

Посмотрим, конечно. Тут иначе как опытом не проверить.

Так Микротик отлично держит BGP как протокол, вопрос только, что на слабых машинках расчет занимает мно-о-ого времени (ну и нет в нем многих мелких фич, которые помогают в ПО крупных вендоров — нам на такой задаче они и не нужны). Ну и смысл держать «в голове» столько лично мне не ясен, если вы только не провайдер и не имеете много аплинков. Как по мне, для простых применений проще грубо агрегировать таблицу в меньшее число менее точных маршрутов.

У Микротиков BGP обрабатывается одним ядром, так что, грубо говоря, важна не многоядерность, а именно «тупая» вычислительная сила одного ядра. В hAP AC2 в проце 4 ядра, на частоте 716 Мгц, и 128 Мб ОЗУ, а у более старых моделек было одно ядро и 600 Мгц частоты, и 128 же Мб ОЗУ — в этом смысле hAP не сильно быстрее старых машинок (если не учитывать, возможно, разную архитектуру процов и скорость ОЗУ). По практике так и есть, 951 девайс жует таблицу те же несколько секунд.

Проблему владельцев динамики этот вариант решит, да. Но не уверен, что она настолько массовая, чтобы строить такие конструкции. Неизящно и много шевелений с клиентской стороны требует, а значит и квалификации.

Очень даже массовая. Физикам крайне редко бесплатно дают статические белые IP адреса. Либо плати денежку, либо опция вообще не предусмотрена.
Дома я плачу 150 руб/мес за статический IP, у родителей провайдер вообще не предоставляет такой опции.

Красивым решением было бы переписать часть кода bird, чтобы он просто устанавливал BGP сессию с любым ее запросившим динамически, так, как будто она уже сконфигурирована.

Можно сделать финт — ловить все попытки установления сессии (да хоть wireshark'ом декодировать пакет) и на их основе прописывать пира в конфиге bird'а.

В этом случае требуется, чтобы у вас был статический IP на VPS, где вы терминируете туннель. Мы обсуждали ситуацию, в которой собственной VPS нет, туннель берется у стороннего VPN-сервиса и там тоже выделяется серый адрес под NAT или динамика. В этом случае просто нет IP, который будет одинаков всё время существования стыка.

В моей конфигурации, когда используется loadbalancing на двух одинаковых каналах и третий как резервный (через него только при падении двух основных) Данная схема нереализуема без появлкния нормальных пиров. Источник префикса, повторюсь, хорош для одного прова, для двух и более — только адресслист. Да и нагрузка меньше. Плюс, каким образом вы промаркируете маршруты с одной BGP сессии на второго провайдера. Это не реально, сам протокол этого не позволяет. Только несколько пиров позволит нормально маркировать маршруты и пользователь сможет ходить.
Я не говорю что данная конфигурация не жизнеспособна. Она не жизнеспособна в моём конкретном случае.

На микротике на закладке Routing — BGP — Peers должен быть пир (вероятно, один), у которого в столбце State справа должно быть написано Established, а в предыдущем столбце prefix count — какое-то число (прямо сейчас 13808).
На закладке IP — Routes должно быть больше этого числа маршрутов, у большинства из которых в столбце Gateway написано «имя вашего интерфейса reachable».

Если порт 179/tcp на in открыт — то теперь сервис сам будет стучаться к зарегистрированным. Это должно помочь для таких случаев.
Ну и можно, конечно, скриптовать передергивание пира при долгом зависании. Но всё это костыли. Единственное правильное решение — исправление бага в ROS.

Этот список создается провайдером (предполагаю, что для системы фильтрации абонентского трафика) и главное его достоинство — что IP-адреса в нем не только берутся из листа РКН напрямую, но и резолвятся через доменные имена в том же листе. Т.е. если, условно, РКН внес в лист какой-то порносайт с IP 2.2.2.2, а порносайт после этого переехал на адрес 3.3.3.3, то в основном списке антифильтра будет только 2.2.2.2, а в этом — и 2.2.2.2, и 3.3.3.3.

С кастомными списками, насколько я понимаю, очень узкая зона востребованности. Если делать подгружаемые списки «общими» — очень возрастает вероятность саботажа (например, подгрузить свой список с 0.0.0.0/0 и отправить всех пользователей сервиса в туннели полностью). Если делать их доступными только конкретному IP, с которого подгружается — тогда непонятно, зачем они вообще; этому человеку гораздо проще будет вести список на своем роутере, дописывая соответствующие записи статикой в таблицу маршрутизации.

Но если вы видите какой-то другой потенциально более полезный вариант — опишите, можно будет подумать, как его реализовать. В целом основная сложность внедрения лежит в необходимости некоего «личного кабинета пользователя», где будет заложена логика управления этими кастомными списками. Добавить анонсирование готовых списков к конкретным пирам нетрудно.

Спасибо за идею с фильтром, взлетело в итоге вот так:

log stderr all;

router id 127.0.0.127;

protocol bgp antifilter {
    neighbor 192.3.134.152 as 65432;
    import all;
    export none;
    local as 64999;
    hold time 240;
    multihop;
}

protocol kernel {
    import none;
    export filter {
        gw = 10.0.0.17;
        accept;
    };
}

protocol device {
    scan time 0;
}

Спасибо за предложение. Но, несмотря на то, что сервис формально ничего не нарушает, я всё же не думаю, что размещать его внутри России будет хорошей идеей. Мало ли как оно повернется завтра.
Думаю, в течение завтрашнего дня что-то с ним произойдет в хорошем смысле.

Furriest подскажите, может быть в курсе, в чем может быть дело. VPN работает норм, копирую несколько роутов /24, выключаю bgp peer. Все работает, трасировка с клиентов роутера идет куда и как надо. Если включаю bgp peer, то трасировка по адресам из роутов дальше моего роутера никуда не идет. Роутер по классике для дома hap ac. В списке роутов периодически появляется unreachable на всех роутах и пропадает. Более того, теряется сеть vpn, так-же нет возможности достучаться до внешнего ip vpn.

т.е. я правильно понимаю, что при наличии двух провайдеров (второй резервный, в т.ч. и для BGP), я не смогу использовать резервный канал для скачивания обновлений на WSUS, банально помечая трафик и маршрутизируя?