Настройка BGP для обхода блокировок, версия 3.1. И немного Q&A

Близится кожаная свадьба Роскомнадзора с Телеграмом, 16 апреля 2018 года начался крестовый поход, ставший фактически символом уничтожения интернета в России, хотя в глобальной войне, начавшейся в 2012 году, он был всего лишь ярким эпизодом.

Ковровые блокировки в исполнении РКН стали причиной появления на свет множества различных сервисов, помогающих пользователям сети выживать под бомбежками. Одним из них стал antifilter.download, позволяющий получать списки находящихся под блокировками IP-адресов. Далее пользователи сервиса могли использовать полученную информацию по своему усмотрению. Вариант усмотрений был описан в статье Настройка BGP для обхода блокировок, версия 3, без VPS, которая стала достаточно популярной в сети и породила несколько сотен пользователей сервиса.

Однако "Tempora mutantur et nos mutamur in illis". За прошедшие три года сервис пережил Alpharacks-gate, похоронивший вместе с собой практически все донаты, упирание в технические ограничения как следствие роста количества пользователей, упирание в те же ограничения как следствие взрывного роста количества ip-адресов в списке РКН... Да что только не пережил. Каждое из этих изменений приводило к небольшому устареванию предыдущей статьи и когда неделю назад один из хабраюзеров предложил мне поправить ее под текущие реалии, я понял, что проще родить нового, чем отмыть этого написать новую версию, заодно и ответив на часто задаваемые вопросы. Результат - ниже.

Зачем это всё

Выполнив описанные ниже действия на своем маршрутизаторе Mikrotik, вы сможете автоматически получать через уже имеющийся у вас VPN доступ к ресурсам, ip-адреса которых занесены в "Единый реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено".

Мы используем протокол BGP для доставки списка IP-префиксов из "Единого реестра" на ваш маршрутизатор и дальнейшего перенаправления трафика к этим префиксам в VPN-туннель. Здесь и далее под общим термином IP подразумевается IPv4, IPv6-адреса сервисом не обрабатываются.

Если ваш маршрутизатор не Mikrotik, но умеет протокол BGP, вы, скорее всего, сможете использовать этот сервис, адаптировав настройки под своё оборудование. Вариант для Keenetic, например, приведен в полезных ссылках в конце статьи.

Что нужно для использования

1. Маршрутизатор Mikrotik

2. подключенный к интернету

3. с VPN куда-то в зону, свободную от блокировок, и использующим протокол, создающий интерфейс (практически любой вариант, кроме чистого IPSEC - в примере используется GRE). В целом тема настройки VPN - отдельная и широкая, а поскольку я ни с одним таким сервисом не аффилирован, описывать на примере кого-либо из них не буду. Будем считать, что VPN у вас есть и работает.

Как настроить

Команды, приведенные в цитатах, необходимо выполнять в окне терминала Mikrotik. В целом никто не запрещает настраивать это всё и в Winbox, но разбирать, какие параметры в какое поле Winbox вводить, вам придется самостоятельно.

Предварительные ласки

Проверяем наш VPN. Крайне важно, чтобы он работал еще до внедрения сервиса.
Наиболее простым способом проверки будет посещение любого сайта, который показывает ваш внешний IP-адрес (например, 2ip.ru), с включенным и выключенным VPN и фиксированием факта, что отображаемый ip-адрес меняется.

Тут у нас лежит первая и частая засада. Очень часто люди с неэкспертной квалификацией настраивают подключение к VPN по шаблону из интернета с использованием routing mark, особенно когда параллельно используют multiWAN схему. В принципе, ничто не запрещает использовать BGP-префиксы и в такой конфигурации, но ее нужно тщательно продумывать и подстраивать под текущие настройки, что в статье "в общем" не описать. Так что в дальнейшем подразумевается, что вы используете только классическую маршрутизацию по префиксам.

Если у вас сильно зажаты правила файрвола, возможно вам потребуется создать отдельное правило для выпуска трафика BGP с маршрутизатора.

/ip firewall filter add action=accept chain=output protocol=tcp dst-address=163.172.210.8 dst-port=179 out-interface=gre-tunnel1

На место gre-tunnel1 нужно подставить имя вашего интерфейса VPN-туннеля.

Укрепи и направь

Прописываем маршрут до сервиса antifilter.download через ваш VPN. Это действие нам поможет от случая, когда где-то на пути какой-то из провайдеров фильтрует BGP (на удивление, таких в России достаточно много).

/ip route add dst-address=163.172.210.8/32 gateway=gre-tunnel1

На место gre-tunnel1 нужно подставить имя вашего интерфейса VPN-туннеля.

Также очень полезно иметь маршрут до VPN-сервера, жестко указывающий в вашего провайдера, но если у вас работает VPN - вероятно, такой маршрут у вас уже прописан.

Для работы VPN обычно используют маршрут по умолчанию, указывающий в VPN-туннель - после активации сервиса в этом маршруте смысла нет и его нужно удалить или задизаблить.

Глубокое проникновение

Настраиваем пиринг с сервисом.

/routing bgp instance set default as=64512 ignore-as-path-len=yes router-id=81.117.103.94 /routing bgp peer add hold-time=4m in-filter=bgp_in keepalive-time=1m multihop=yes name=antifilter remote-address=163.172.210.8 remote-as=65432 ttl=default
/routing filter add action=accept chain=bgp_in comment="Set nexthop to VPN" set-in-nexthop-direct=gre-tunnel1

Первой командой мы создаем процесс BGP на вашем устройстве. В ней:

• 64512 - 16-битный номер автономной системы. Заменяем на любой по вашему желанию, кроме ASN сервиса (65432). В нашем конкретном случае нам не важно, какой там будет указан номер в диапазоне от 1 до 65534, но если делать все правильно - RFC6996 говорит нам, что для частного использования выделен диапазон 64512-65543.

• 81.117.103.94 - router ID (32 бита) в формате IPv4-адреса. В общем случае нам, опять же, не важно, какой там будет указан ID, но чтобы уменьшить вероятность пересечения с другим пользователем - лучше использовать ваш текущий внешний IP-адрес (посмотрев его на том же 2ip.ru). При его изменении менять router ID совершенно не обязательно.

Второй командой мы создаем BGP соединение с сервисом antifilter.download. В ней ничего менять не надо.

Третьей командой мы указываем, что для всех маршрутов, полученных от сервиса, нужно установить в качестве next-hop интерфейс нашего VPN. В ней на место gre-tunnel1 нужно подставить имя вашего интерфейса VPN-туннеля.

... и обоюдный оргазм

Если всё настроено правильно - через несколько десятков секунд, в течение которых процессор маршрутизатора будет на 100% загружен обработкой списка полученных префиксов, все заработает и трафик до полученных IP-адресов будет отправляться в VPN.

То, что пиринг поднялся, можно посмотреть по пути Routing - BGP - Peers в Winbox:

State должен быть Established, а в поле Count - отличное от нуля количество полученных префиксов.

Также характерным признаком того, что префиксы получены, является следующая картинка по пути IP - Routes в Winbox:

По клику где указано можно раскрыть весь список полученных префиксов и увидеть что-то вроде:

Важно, чтобы в поле Gateway было указано имя вашего интерфейса VPN и слово reachable (Distance при этом у вас будет другим, это нормально).

Если что-то не работает - проверьте прежде всего доступность сервиса. Сервер откликается на пинг, так что команда ping antifilter.download вполне себе покажет, все ли хорошо со связностью. Если пинг проходит - проверьте соответствие IP-адреса в пинге 163.172.210.8, потому что вы вполне можете читать эту статью в момент, когда сервис уже куда-то мигрировал.

Далее перепроверьте настройки и прочитайте Q&A ниже. А потом спросите в комментариях здесь или на канале MikrotikRus, там я тоже иногда поддерживаю решение, да и кроме меня там очень много грамотных людей.

А поговорить? (Q&A)

• Решение перекрывает не все проблемы с блокировками

  • Конечно нет. Нужно понимать, что поскольку действие (блокировка) лежит фактически на 7 уровне модели ISO/OSI, то и противодействие (обход блокировки) наиболее эффективно работает на том же уровне модели. Сервис же предоставляет возможность борьбы на 3 уровне модели, что автоматически означает неидеальное совпадение. Если хочется более точного варианта - плагин для браузера, автоматически отправляющий некоторые сайты через прокси-сервер (например, SwitchyOmega для Chrome), будет работать гораздо лучше.

• Я всё настроил, а мой любимый ресурс все равно блокируется. При этом подходящего префикса для его адреса в списке нет

  • Вероятно, РКН внес другой IP-адрес ресурса в реестр. Список IP-адресов генерируется полностью автоматически и не может редактироваться со стороны сервиса под каждый отдельный кейс вручную. Самое простое решение - прописать до любимого ресурса статический маршрут в VPN на маршрутизаторе.

• Я всё настроил, а мой любимый ресурс все равно блокируется. При этом подходящий префикс для его адреса в списке есть, но nslookup выдает другой адрес из сети моего провайдера

  • Вероятно, ваш оператор связи использует многоуровневую систему блокировки контента, в том числе перехватывающую DNS-запросы с соответствующей коррекцией ответа. В этом случае вам может помочь перенаправление DNS в VPN или более интеллектуальные способы решения, описанные в частности в статье Переводим на DoH домашнюю сеть.

• После включения сервиса в VPN отправляется трафик на IP-адреса, отсутствующие в реестре. Дефолт в VPN я отключить не забыл

  • Вероятно, в реестре есть IP-адрес из той же IP-подсети /24. По BGP сервис отдает только суммаризованные вверх префиксы /24 (т.е. даже если в реестре есть только адрес 1.2.3.4 - вы получите префикс 1.2.3.0/24, перекрывающий весь диапазон от 1.2.3.0 до 1.2.3.255).
    Вы всегда можете исправить эту ситуацию для себя и конкретных адресов, прописав маршрут на них через провайдера в вашем роутере статически (статика по умолчанию побеждает динамику).

• Раньше сервис можно было настроить для получения отдельных IP-адресов (по /32). Как получать их сейчас?

  • К сожалению, сервис банально уперся в проблему масштабирования. После появления нескольких сотен пользователей и заполнения реестра в отдельные моменты более чем 2 миллионами префиксов схождение BGP-процесса сервиса могло занимать десятки минут, со всеми вытекающими в виде разрыва сессий по таймауту. Many Bothans died to... Многие оптимизации были сделаны в попытках решить эту проблему, включая миграцию с VPS на выделенный сервер, разделения на фронт- и бэкенды и т.п., но кардинально проблема была решена только отказом от раздачи по BGP списка отдельных IP-адресов.
    
    Если вам необходим список отдельных адресов, вы можете получать их с сайта по HTTPS и далее внедрять в свое решение, например, как описано в статье Настройка BGP для обхода блокировок, или «Как я перестал бояться и полюбил РКН». Мало того, с сайта доступно гораздо больше разных списков, в том числе и в формате Mikrotik Address List, что позволяет более гибко использовать решение.

• РКН замедляет Twitter, решение может помочь?

  • По сути - нет, потому что все эти замедления не отражаются в реестре (хотя законность такого действия спорна, но who cares). Для замедления используются ресурсы расставленных у операторов связи ТСПУ (DPI от компании RDP.RU), управление которыми идет централизованно и закрыто от постороннего взгляда. И высока вероятность, что в недалеком будущем вся фильтрация уйдет в эту сторону и реестр перестанет быть источником данных для нас.
    
    Мысль о развитии кастомных списков "Вот эти IP-адреса надо сделать доступными для обхода замедления" есть, но для бесплатного пет-проджекта нахрапом это требует чересчур много постоянных инвестиций. Если удастся придумать форму, в которой я смогу тратить на этот сервис разумное количество собственных сил и средств - обязательно реализую и опишу. Кстати, если у кого-то есть идеи, как это сделать, пишите в комментариях, обсудим. Ибо одна голова - хорошо, а две - мутация.

• У меня есть вопрос, ответа на который нет в Q&A

  • Задайте его в комментариях к статье. Постараюсь ответить на все там же, а если вопрос будет интересен большому числу читателей - добавлю в Q&A.

Заключение

Предполагаю, что реестр как источник IP-префиксов для обхода блокировок исчерпает себя в начале-середине 2022 года, поэтому вряд ли эта статья потребует новой версии, скорее просто уйдет в архив как неработающее решение.

Мечтаю, впрочем, что это и подобные решения станут иметь исключительно историческую ценность и интернет будет тем, чем был раньше - транспортом для информации вне политики. Но эти мечты вряд ли сбудутся.

Так что, как обычно, буду рад, если статья кому-то поможет или, что еще лучше, сподвигнет более глубоко изучать сетевые технологии. Потому что в грамотности - наша сила.

Полезные ссылки

• Прежде всего статья Настройка BGP для обхода блокировок, или «Как я перестал бояться и полюбил РКН» - она была наиболее полной и подробно описывающей логику решения. Если вам хочется более глубоко погрузиться в концепцию - эта статья практически идеальна (разве что сейчас уже имеет смысл внедрять это на bird v2, с соответствующей коррекцией конфигураций решения). И еще более полезны комментарии к ней.

• Если вам интересно более глубоко понять, что такое и с чем едят BGP в частности и сетевые технологии вообще - не могу не порекомендовать "Сети для самых маленьких" от проекта LinkMeUp

• Если вам хочется решение на Address List - NeoBeZ опубликовал короткий скрипт для выгрузки нужного с сервиса. Не забудьте, что потом по этому листу нужно реализовать набор правил для перенаправления трафика.

• Для роутеров Keenetic есть решение от Александра Рыжова. Оно, конечно, базируется на старой версии сервиса, но легко корректируется под новую.