Русский
Русский
English
Статистика
Реклама

Bgp

Из грязи в RPKI-князи-1. Подключаем валидацию маршрутов в ВGP

10.12.2020 12:12:32 | Автор: admin

Привет! Я работаю старшим сетевым инженером в компании DataLine, занимаюсь сетями с 2009 года и успел со стороны понаблюдать, как компании подвергались атакам из-за уязвимости протокола маршрутизации BGP. Один BGP Hijacking чего стоит: пару лет назад хакеры с помощью перехвата BGP-маршрутов украли 137 тыс. долларов.

С переходом на удаленку компании организуют доступ из дома через защищенные соединения с помощью NGFW, IPS/IDS, WAF и прочих решений. Но про безопасность BGP порой забывают. Я расскажу в цикле статей, как каждый клиент сервис-провайдера может обезопасить себя с помощью RPKI средства защиты глобальной маршрутизации в сети Интернет. В первой статье на примере объясню, как это работает и как настроить защиту на стороне клиента в пару кликов. Во второй поделюсь опытом внедрения RPKI в BGP на примере маршрутизаторов Cisco.

Что важно знать про RPKI, и при чем тут холодильник

RPKI (Resource Public Key Infrastructure) это специализированная инфраструктура открытых ключей. Она помогает доказать подлинность ресурса в интернете, а также право ресурсодержателя использовать ресурсы и передавать информацию о ресурсах операторам связи.

Можно сравнить эту инфраструктуру с холодильником в общежитии или офисе. Вы получаете право пользоваться общим холодильником (интернетом), складываете еду на определенную полку (публикуете ресурсы), но обязаны определенным образом подписывать еду, чтобы ее не забрал кто-то еще.

Так и тут. RPKI использует для подписей профиль сертификата X.509 PKI, который описан в RFC3779. Операторы связи с его помощью принимают безопасные решения о маршрутизации ресурсов в сети Интернет. Чтобы увидеть, как они это делают, напомню про иерархию выделения ресурсов в интернете:

Ресурсы последовательно выделяют несколько организаций:

IANA (Internet Address Number Authority) администрация адресного пространства интернета. Интернет-ресурсы изначально принадлежат IANA, она управляет пространствами IP-адресов для доменов верхнего уровня. Она же присваивает номера для автономных систем (AS) систем IP-сетей и маршрутизаторов, которыми управляют операторы связи. Эти номера AS необходимы для маршрутизации.

RIR (Regional Internet Registry) региональные интернет-регистраторы, IANA распространяет ресурсы через них. Всего их 5 для разных регионов RIPE NCC, ARIN, APNIC, AfriNIC, LACNIC.

LIR (Local Internet Registry) локальные интернет-регистраторы, как правило, крупные сервис-провайдеры. RIR распространяет ресурсы на LIRы, которые уже распределяют их между своими клиентами.

Такая же архитектура у RPKI. После каждого распределения ресурсов создается сертификат, подписанный ключом вышестоящей организации. IANA выпускает сертификаты для доверенных RIR, а они для доверенных LIR.

Сертификаты хранятся в базе данных, по которой можно проверять достоверность информации. Базы данных расположены на публичных репозиториях RPKI у всех RIR на так называемых "точках доверия", или Trust Anchors.

Тут в игру вступают владельцы ресурсов в интернете. Чтобы подтвердить безопасность ресурсов, они создают с помощью сертификатов криптографически заверенные объекты, или ROA.

ROA (Route Origin Authorisation) это объект c цифровой подписью, который подтверждает, что конкретная AS имеет право быть источником какого-то маршрута и анонсировать его в интернете. Запись ROA имеет 3 параметра:

  • номер AS, которая является источником маршрута;

  • префикс и его длина (это IP-адрес с маской: xxx.xxx.xxx.xxx/yy);

  • максимальная длина префикса.

С помощью максимальной длины префикса указывается, может ли данная AS анонсировать более специфичный маршрут. По умолчанию это запрещено, и длина префикса равна максимальной длине. Это значит, что анонс префикса с более длинной маской будет считаться неавторизованным.

Следовательно, при проверке подлинности любой префикс можно сравнить с ROA и задать ему три состояния:

  • VALID для префикса есть ROA, и анонс маршрута совпадает по всем параметрам с референсными значениями в ROA. AS в AS_PATH совпадает с AS в записи ROA, префикс тоже как в ROA, а его максимальная длина больше или равна длине маски в анонсе.

  • INVALID для префикса есть ROA, но анонс маршрута не совпадает по одному из параметров в ROA.

  • UNKNOWN значит, что запись ROA для префикса отсутствует в Trust Anchor вашего RIR. Это возможно, если префиксы еще не завалидированы. Пока все только переходят на RPKI, многие операторы связи применяют мягкие политики и доверяют таким префиксам. При жесткой политике безопасности префикс UNKNOWN будет отклонен маршрутизатором.

Разберем проверку префикса на примере. Допустим, у меня есть префикс х.х.х.х/22, который маршрутизируется в сети Интернет и анонсируется из моей AS N. Изначально я не создал для него записи ROA. Раз запись о префиксе отсутствует в Trust Anchor, анонс префикса будет иметь статус UNKNOWN.

Далее я создал для него запись ROA c параметрами: AS N, префикс х.х.х.х/22, максимальная длина префикса /23. Теперь от имени своей AS N я могу проанонсировать апстрим-провайдерам этот префикс /22 или же две /23 подсети, которые входят в /22 подсеть. Такой анонс будет иметь статус VALID.

Если же я проанонсирую /24 от имени AS N или префикс /22 (/23+/23) от имени AS P, то такой анонс будет иметь статус INVALID. Допустим, нам необходимо проанонсировать подсеть /24 из более крупного блока адресов, который уже анонсируется в глобальную сеть. Значит, в записи ROA для более крупной подсети нужно изменить параметр максимальной длины префикса или создать для нее свой ROA.

Проверка подлинности маршрутов на маршрутизаторах происходит одним из способов:

  1. Проверка самим маршрутизатором по прямой RPKI-сессии.

  2. Загрузка на маршрутизатор готовой базы данных с локального кэш-сервера RPKI.

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

Второй способ не требует таких больших затрат. Локальный кэш-сервер RPKI загружает в себя базу ROA со всех установленных Trust Anchors по протоколу RSYNC или RRDP и поддерживает ее в актуальном состоянии. Локальный RPKI-сервер на основе своей базы данных ROA генерирует базу данных для маршрутизатора. Каждая запись базы содержит упрощенный вариант ROA, и эта база передается на маршрутизатор по протоколу RPKI-RTR. По умолчанию это TCP-порт 8282. По этим данным на маршрутизаторе настраиваются политики для маршрутизации полученных префиксов.

Как завалидировать свои префиксы

Допустим, вы клиент сервис-провайдера. У вас есть своя AS с парой /24 блоков IP-адресов, вы пиритесь по eBGP со своим провайдером, full view от него не получаете, других пирингов у вас нет. Вам приходит письмо, что провайдер внедряет на своей стороне систему валидации префиксов на основе RPKI и просит завалидировать свои анонсы.

В этом случае вам нужно подписать ROA свои префиксы, чтобы в дальнейшем ваши ресурсы были доступны из сети Интернет.

Для регионального регистратора RIPE NCC шаги такие:

  1. Зайдем на портал RIPE в личный кабинет по адресу https://my.ripe.net. В правой части страницы перейдем в Resourses, далее в RPKI Dashboard.

    Если вы раньше никогда не заходили на эту страницу, RIPE попросит вас подписать соглашение EULA.

    Затем выбираем тип центра сертификации (Certificate Authority, CA):

    - Hosted хранить сертификат на стороне RIPE;

    - Non-Hosted хранить сертификат на своей стороне.

    Быстрее и удобнее выбрать вариант Hosted. В варианте Non-Hosted вам нужно предоставить XML-файл, сгенерированный вашим ПО центра сертификации. Система RIPE NCC сгенерирует ответный XML-файл, который нужно загрузить и использовать в своем программном обеспечении RPKI CA.

  2. В RPKI Dashboard перейдем во вкладку BGP Announncements. В нижней части экрана в меню Show выберем All.

  3. Вернемся в начало страницы и выберем все префиксы по чек-боксу рядом с надписью Origin AS. Создадим ROA по кнопке Create ROAs for selected BGP announcements.

  4. Подождем, пока сформируется стейджинг ROA. Внизу появится кнопка:

    Нажмем ее и во всплывающем меню нажмем Publish!

Все, готово! Вы успешно завалидировали свои префиксы!

Для счастливых обладателей PI-адресов RIPE подготовил отдельную инструкцию для валидации префиксов. А еще удобнее использовать Wizard от RIPE NCC: https://portal.ripe.net/rpki-enduser.

Сейчас все крупные компании внедряют проверку маршрутов на базе RPKI. Рано или поздно валидацию BGP нужно подключить всем, кто хочет, чтобы приложения и сайты были доступны, а проверки маршрутов успешны.

Если же вы сами являетесь сервис-провайдером, то лучше внедрить свою валидацию и фильтрацию маршрутов на основе RPKI.

Но об этом поговорим в следующий раз, всем пока и до встречи!

Подробнее..

Активное внедрение стандарта Интернета RPKI полезно ли?

26.12.2020 10:13:54 | Автор: admin

Сейчас почитал, поразмыслил и начал понимать, что, возможно, я рано сегодня порадовался отличной статистике внедрения RPKI в массы в этом году.

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

Да, внедрение RPKI безусловно можно назвать достижением, но только для определённого круга заинтересованных организаций. Для российского телекома это может стать началом конца.

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

Проблема вот в чем. Мы, получается, переходим к иерархической схеме управления, к древовидной. И сам протокол, и принципы, на которых он основан, суть древовидные структуры. А это идёт в разрез с философией Интернета, который создавался и, тьфу-тьфу, функционирует в распределённом режиме. Интернет -это структура произвольного графа (за исключением некоторых сервисов типа DNS, уже названной системы сертификатов PKI и той же раздачи адресов), без ориентированности на строгую иерархию, без единственной головы.

Голов у Интернета в этом смысле много - если считать ими точки концентрации трафика. Теперь давайте разберёмся, что же это за "головы" мирового Интернета. Это в первую очередь телеком операторы т.н. бэкбона интернета - самых скоростных и широкополосных каналов связи. (Их принято называть операторами Tier 1, т.е. первого высшего уровня. Эти операторы никому не платят за интернет, поскольку они и являются его основой. К ним подключаются средние операторы Tier 2 и т.д.).

Связность в европе и окрестностяхСвязность в европе и окрестностях

Также в группу голов можно смело заносить крупных поставщиков контента, типа Netflix, Amazon, Vkontakte и Google. А также их крупнейших посредников - точки обмена трафиком, или пиринг-центры, представляющие из себя ассоциации разных интернет- и контент-провайдеров разного уровня. Именно во многом благодаря их существованию Интернет более-менее распределён, а значит устойчив к сбоям и, что немаловажно, к монополиям.

Во многом за счёт последних скорости интернета выше, а цены ниже. Именно они вносят значительный вклад в представление Сети как графовой распределённой структуры, у которой нет основных 3-4 владельцев, в основном американских (хотя надо отдать должное, скандинавская Telia Sonera на первом месте сейчас). Так вот, внедряемый стандарт основан на иерархии подписей маршрутов, аналогично иерархии подписей сертификатов сайтов.

Основа протоколаОснова протокола

И выдача маршрутов (как мне сейчас представляется) соотносится с современным положением вещей примерно так же как сама нынешняя система сертификатов PKI соотносится с распределёнными системами типа блокчейна. Ну или другая аналогия, политическая - как однополярный мир соотносится с многополярным. Программистская аналогия - как централизованный и распределённый контроли версий ПО. Финансовая: как Бреттон-Вудская, ныне Ямайская, система (золотодолларовый стандарт) соотносится с золотым стандартом начала 20-го века.

Вернёмся к Интернету.

Дерево связей протокола RPKIДерево связей протокола RPKI

По принятому протоколу доверие маршрутам обеспечивается только согласно иерархическим лицензиям, выданным от основных их владельцев - крупнейших телекомов бэкбона Интернета. То бишь из тех "голов", что я перечислял, влияние перетекает только к первой немногочисленной группе "владельцев" интернета. А различные региональные игроки остаются в стороне. Существующие ассоциации (пиринговые центры) наподобие российских MSK-IX или DATAIX, пока что довольно влиятельные, потеряют возможность обмениваться трафиком, так как их участники не смогут обмениваться маршрутами, нарушая границы своих иерархий, то есть обмен налево будет затруднён. А это и был основной смысл существования этих точек обмена. В результате контроль над трафиком уйдёт к крупнейшим телекомам. Российские телекомы не глобальны и впадут в зависимость от западных. Точки обмена трафиком просто распадутся. Установится монополия (или если хотите олигополия) в сфере коммуникаций, маршруты будут прокидываться через головы, они станут длиннее, а значит связь будет во многих случаях медленнее. Ну и конечно вырастут цены. За большую цену вы получите худшую связь.

И ещё один аспект - в целом под предлогом защиты Интернета зарубят связность и распределённость (свойства графа интернета), количество интерконнектов, что не только скажется на качестве и скорости, но и уменьшит надёжность связи.


Я надеюсь, что на Хабре найдутся специалисты, которые могут развеять мои сомнения и опасения. Или объяснят, что, например преимуществ у новой технологии больше чем недостатков (если они есть).

Удачного всем дня!

Подробнее..

Отчет о сетевой безопасности и доступности в 2020 году

22.03.2021 16:16:43 | Автор: admin

Краткое содержание

  • К 2021 году сеть фильтрации Qrator Labs расширилась до 14 центров очистки трафика общей пропускной способностью в 3 Тбит/с с точкой присутствия в Сан-Паулу, Бразилия, вводящейся в эксплуатацию в начале 2021 г.

  • Новые сервисы, предоставляемые партнерами компании (SolidWall WAF и RuGeeks CDN) за 2020 год были полностью интегрированы в инфраструктуру Qrator Labs и личный кабинет.

  • Улучшенная логика фильтрации позволяет Qrator Labs удовлетворить потребности даже самых крупных заказчиков с глобально распределенной инфраструктурой, обеспечивая полное покрытие услуг кибербезопасности и нейтрализации DDoS-атак.

  • Qrator Labs активно использует новейшие процессоры AMD для задач, связанных с обработкой трафика.

За 2020 год количество DDoS-атак лишь увеличилось, самые опасные можно описать просто: короткие и обескураживающе интенсивные.

Тем не менее, инциденты BGP оставались той областью, в которой очевидна необходимость изменений, так как количество серьёзных инцидентов, таких как перехваты трафика и утечки маршрутов, оставалось высоким в течение всех последних лет и 2020 не был исключением.

В 2020 году компания Qrator Labs начала предоставлять услуги в Сингапуре в рамках нового партнерства, а также запустила центр очистки трафика в Дубае, где находится укомплектованный профессионалами офис, готовый отвечать на любые запросы потребителей в регионе.

Вторая декада Qrator Labs

С началом 2021 года Qrator Labs отметила собственное десятилетие. Некоторым коллегам, работающим в компании с самого начала, было сложно поверить, что прошло уже столько времени.

Немного о том, чего компания достигла за эти 10 лет:

  • От 1 до 14 центров очистки трафика на 4 континентах, островах Сингапура и Японии, а также Аравийском полуострове;

  • В начале 2021 года сеть фильтрации Qrator приближается к 3 Tbps кумулятивной емкости, используемой для нейтрализации DDoS-атак;

  • С 7 до 70 сотрудников в одиннадцати городах;

  • Тысячи спасённых клиентов. Буквально.

И все это без каких-либо сторонних инвестиций! Десять лет мы следовали пути самодостаточности в росте и развитии компании. Конечно, не принимая во внимание усилия каждого вовлеченного все эти годы.

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

2021 год начался взрывным образом с DDoS-атаки интенсивностью 750 Гбит/с, состоящей в основном из DNS-амплифицированного трафика. Этот вектор атак является одним из старейших и наиболее изученных, что не мешает ему сеять хаос с огромной эффективностью.

Улучшения логики фильтрации

В течение последних двух лет в Qrator Labs приложили множество усилий для обновления логики фильтрация трафика, лежащей в основе услуги нейтрализации DDoS-атак. В итоге, в зависимости от параметров конкретного трафика и задач, нам удалось повысить общую эффективность в 4-8 раз, при этом используя на 25-33% меньше оперативной памяти. Это означает, что теперь мы можем принимать на борт еще больше легитимного трафика, а также работать с крупнейшими потенциальными клиентами в мире.

Мы значительно обновили детектор атак алгоритм, призванный подтвердить наличие атаки. Теперь у нас есть более широкий набор параметров, доступных пользователю для выбора, каждый из которых может служить источником для наполнения черного списка. Это позволяет нам нейтрализовать атаки ближе к уровню L7 модели OSI, по сравнению с L3-L4.

Ещё одно нововведение это брокер запросов. Он позволяет упростить процесс адаптации WAF потенциальным пользователем. Мы улучшили процессы взаимодействия с различными Web Application Firewall продуктами в сети фильтрации Qrator, реализовав асинхронную схему принятия решений по сомнительным, а значит потенциально вредоносным запросам.

В 2020 году в сети фильтрации Qrator также была реализована поддержка Proxy Protocol. Этот протокол облегчает подключение и дальнейшую нейтрализацию DDoS-атак для приложений, использующих, например, WebSockets. Помимо упрощения подключения прокси-сервера к сети Qrator, такого как HAproxy или NGINX, Proxy Protocol упрощает настройку любого решения, работающего поверх TCP, позволяя легко установить под защиту сети фильтрации Qrator любой ресурс, поддерживающий его.

AMD внутри Qrator Labs

По нашему мнению, новые процессоры AMD отлично подошли к аппаратной архитектуре сети Qrator. Уникальная характеристика ЦПУ AMD иерархическое разделение ядер на кристалле вполне эффективна для задач, решаемых в Qrator Labs. Блоки ядер с раздельными контроллерами памяти представляют собой отдельную задачу с точки зрения корректной настройки, потому что мы меняем то, каким образом операционная система видит ядра центрального процессора. Огромное преимущество новых процессоров AMD заключается в том, что теперь мы в Qrator Labs можем построить однопроцессорную серверную машину с мощностью большей, чем у старой двухпроцессорной установки. С одной сетевой картой внутри каждой машины, подключенной с помощью PCIe, два процессора вносят большую сложность в задачу изначального разделения нагрузки, в дополнение к задержке переключения между ними. Замена двух ЦПУ одним решает эту задачу, оставляя необходимость настраивать только ядерную (иерархическую) архитектуру в одном процессоре, что значительно легче.

У процессора AMD обнаружилась еще одна интересная особенность. Используемая нами модель поддерживает работу с памятью на частоте 3200 ГГц. Когда мы начали тестировать упомянутый ЦПУ, то обнаружили, что, хотя формально контроллер памяти и допускает рабочие нагрузки на частоте 3200 ГГц, но внутрипроцессорная шина, соединяющая ядра, работает на частоте ниже. Фактически это означает, что если мы используем тактовую частоту процессора 3200 ГГц, пропускная способность снижается из-за низшей частоты контроллера памяти. Приложение, которое выиграет от этой особенности, должно быть исключительно однопоточным и работать только с одним каналом памяти.

В завершение данного раздела хочется отметить, что сейчас мы используем процессоры AMD на всех новых точках присутствиях, в том числе по соображениям экономической эффективности.

Интеграция партнерских технологий

В течение прошедшего года мы интегрировали новые партнерские технологии в структуру сети фильтрации Qrator.

Новый WAF от SolidWall теперь представлен в составе услуг Qrator Labs. SolidWall WAF интегрирован в панель управления Qrator, что позволяет клиентам полностью управлять всеми настройками межсетевого экрана в одном месте, вместе с другими услугами Qrator Labs.

Другая новинка это CDN-сервис от RuGeeks, стал доступен всем клиентам Qrator Labs после периода интеграции и обширного тестирования.

Личный кабинет клиента претерпел значительные изменения и обновления в течение 2020 года. Мы приложили много усилий, чтобы предоставить нашим пользователям как можно больше параметров настройки для эффективного управления услугами для ресурсов под защитой Qrator.

Фильтрация IPv6-трафика

По данным компании Google, к концу 2020 года глобальное внедрение IPv6 превысило 30%. Сейчас протокол находится на решающим этапе и будет либо всеобще принят, либо так и останется лишь частичной заменой IPv4. Мы считаем, что за IPv6 будущее сетей, поэтому в течение последних нескольких лет наша команда инвестировала время и усилия в полную поддержку 6-й версии протокола IP в сети Qrator.

Одна из важных задач сетевой инженерии, решаемая в Qrator Labs это поиск тяжелых элементов в потоке. На самом деле подразумеваются наиболее интенсивные подпотоки, но в академической англоязычной литературе термин heavy hitters уже устоялся, потому и в русском языке мы говорим о задаче поиска "тяжелых" элементов. Для начала стоит объяснить, почему мы решаем конкретно эту задачу: наша основная цель как компании, предоставляющей нейтрализацию DDoS-атак, доставлять легитимный и очищенный трафик его владельцу, одновременно отсекая вредоносный и нелегитимный трафик.

В случае IPv4-трафика мы можем решить задачу без поиска самого тяжелого элемента достаточно проанализировать весь поток до цели, чтобы определить "вес" каждого отдельного отправителя.

С IPv6 ситуация совершенно иная.

"Сохранение в памяти полного пула IPv6-адресов потребовало бы огромного ее объема. Если на хранение каждого IPv6-адреса выделять по одному биту памяти, то потребуется примерно 2^128 бит для всего пула IPv6-адресов. Это больше, чем количество атомов на Земле.

Если же на хранение целого префикса /64 брать по одному биту памяти, то для всего адресного пространства IPv6 уже потребовалось бы всего лишь 2^64 бит памяти. Это число не настолько астрономическое по сравнению с предыдущим, и его можно сравнить со всей произведенной до настоящего момента оперативной памятью всех устройств в мире."

Рассматривая задачу в IPv6, с самого начала нетрудно заметить, что количество возможных источников пакетов может быть невообразимо велико. То же самое с их потенциальными адресами назначения.

Поскольку специализацией Qrator Labs является поддержание необходимого уровня доступности сервиса потребителя, задачу можно рассматривать как поддержание определенного порога интенсивности как с точки зрения количества пакетов в единицу времени, так и канальной емкости, которую заказчик в состоянии принять и обработать. Мы не можем пропустить трафик, превышающий данные ограничения, так как это скорее всего приведет к пагубным для потребителя услуги последствиям.

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

Мы решаем эту задачу с помощью нескольких инструментов, так как одного способа недостаточно. Это позволяет нам переключаться между отдельными инструментами или использовать их все вместе в случае необходимости. Наш подход заключается в комбинации алгоритмов и методов, которые ограничивают либо скорость передачи пакетов (pps), либо пропускную полосу от отдельного источника (bps).

А поскольку IPv6 не допускает сведения задачи к понятиям черного и белого списка, задача оказывается действительно интересной.

Изучая соответствующую литературу по теме, мы встретим большое количество исследований по разнообразным алгоритмам, таким как "поиск тяжелых элементов" в потоке событий. Но ограничение скорости передачи пакетов и/или пропускной полосы гораздо более широкая задача, вот почему мы вводим понятия "порога" и его "превышения" или "удержания". При этом мы хотим максимизировать собственный параметр качества сервиса, чтобы обеспечить наименьшее количество ложноположительных срабатываний.

Qrator Labs разработала полномасштабный симулятор для тестирования среды в IPv6. Он генерирует потоки трафика, позволяя применять различные комбинации алгоритмов фильтрации и измерения результатов и качества их работы. Со временем, когда симулятор будет готов с нашей точки зрения, мы планируем сделать его код общедоступным.

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

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

Чтобы успешно решить эту нетривиальную задачу, нам пришлось экспериментировать с разными типами счетчиков, которые позволяют учитывать недавние события с большим весом, чем те, которые произошли давно, и стали малоинтересными.

Другая проблема, связанная со счетчиками, ресурсная. Для наших задач требуется огромное количество счетчиков, чтобы из всего потока уметь выделять подпотоки и измерять их интенсивность. Много счетчиков много памяти. Мы пытаемся экономить память, уменьшая количество бит, выделенных на счетчик. Это не просто, но возможно.

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

Статистика и дальнейший анализ данных по DDoS-атакам

Медианная продолжительность DDoS-атаки составляет около 5 минут, что не сильно изменилось с тех пор, как мы изменили методологию подсчета и разделения атак. DDoS-атака с DNS-амплификацией, которую мы нейтрализовали в феврале 2021 года, длилась 4 минуты.

Распределение векторов DDoS-атак демонстрирует преобладание атак на основе UDP-флуда в 2020 году, составляя 40,1% от всех наблюдавшихся атак. На втором месте стоит IP-флуд с 38,15%, а SYN-флуд замыкает тройку наиболее популярных векторов по L3-атакам с 16,23% за 2020 год.

График пропускной способности отдельных векторов атак иллюстрирует различия между ними и показывает, что IP-флуд начинается с самого высокого уровня начальной интенсивности, по сравнению с остальными векторами, со средним уровнем атаки выше 1 Гбит/с.

Сравнение пакетной интенсивности векторов атак демонстрирует, что DDoS-атаки на основе UDP-флуда могут начинаться с самых низких уровней возможной скорости передачи пакетов, а TCP-флуд обладает противоположной характеристикой. Их медианные уровни pps составляют 113,5 тысяч и 1,2 млн соответственно.

А вот иллюстрация комбинаций векторов атаки:

Как видите, в реальном мире DDoS-атак основные векторы смешиваются мало и, по большей части, остаются "чистыми"от комбинаций. Так UDP-флуд и IP-флуд преобладают среди всех DDoS-атак 2020 года.

Погружение в BGP

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

Иначе обстоит ситуация с перехватами трафика и утечками маршрутов. В отчете, который мыпубликовали в мае 2020 по первому кварталу прошлого года, мы указали на статистику утечек маршрутов BGP:

Январь 2020: 1
Февраль 2020: 4
Марта 2020: 6
Апрель 2020: 6 +1 в IPv6

Теперь мы можем взглянуть на цифры за 4 квартал 2020 года с дополнительными данными по январю 2021 по тем же утечкам маршрутов:

Обратите внимание, что мы учитываем в данной статистике только такие инциденты, которые команда Qrator.Radar считает глобальными то есть превышающими определенные пороговые значения. Сравнивая данные 4-го квартала с 1-м кварталом 2020 года, создается впечатление, что наблюдается некоторое снижение абсолютного числа инцидентов, связанных с утечкой маршрутов. Что будет справедливо только при условии, что мы примем как факт то, что все инциденты имеют одинаковый размер. На практике же это совершенно противоположно как и всегда, более крупные сети способны быстрее и сильнее влиять на клиентов и соседей. Фактически же это означает, что шансов на изменение ситуации с утечками маршрутов не так много, пока у нас не будет рабочего решения для полного их предотвращения. Мы надеемся, чтоASPAивсе связанныес данным нововведением черновики, рассматриваемые внутри IETF, будут приняты и получат RFC статус в ближайшем будущем.

PDF-версия отчетадоступна для скачивания по ссылке.

Подробнее..

Перевод BGP redistribute-internal ещё один рецепт петли маршрутизации

14.05.2021 18:17:37 | Автор: admin

Иногда можно наткнуться на такое поведение по умолчанию, обнаружение и понимание которого требует определённой медитации. Для меня одной из таких особенностей была команда bgp redistribute-internal. Первоначально назначение этой функции не вызывало у меня каких-либо вопросов, как и то, что её использование может привести к петлям маршрутизации; раз знающие люди написали, что может, значит, так оно и есть. Однако спустя неопределённое время в голове начало скрестись желание получить наглядный пример такой петли. Беглый поиск, впрочем, не дал ничего конкретного, только упоминание в документации:

Note: By default, only eBGP-learned information is candidate to be redistributed into IGP when the redistribute bgp command is issued. The iBGP routes is not redistributed into IGP until the bgp redistribute-internal command is configured under the router bgp command. But precautions must be taken in order to avoid loops within the Autonomous System when iBGP routes are redistributed into IGP.

(Вольный перевод: по умолчанию только внешние BGP маршруты можно рассматривать как кандидаты для импорта в IGP при использовании команды redistribute bgp. Внутренние BGP маршруты не являются такими кандидатами, пока не выполнена команда bgp redistribute-internal в режиме router bgp. Однако стоит соблюдать осторожность при использовании последней команды, чтобы избежать возникновения петель маршрутизации внутри автономной системы, когда внутренние BGP маршруты могут быть импортированы в IGP)

Попробуем изобрести нужный нам пример петли. Рассмотрим следующую схему:

R1 объявляет 1.1.1.1/32 как внутренний маршрут; в то же время R2 суммаризует его до 1.1.1.0/24 и добавляет 1.1.1.1/32 в BGP:

R2#sho ip ro 1.1.1.1 longer-prefixes<output omitted>      1.0.0.0/32 is subnetted, 1 subnetsO        1.1.1.1 [110/2] via 192.168.12.1, 00:03:09, FastEthernet0/0R2(config)#router ospf 1R2(config-router)#area 0 range 1.1.1.0 255.255.255.0R2(config-router)#router bgp 1R2(config-router)#network 1.1.1.1 mask 255.255.255.255

Импортируем 1.1.1.1/32 из BGP в OSPF в зоне 1:

R4(config)#router ospf 1R4(config-router)#redistribute bgp 1 subnets

Впрочем, ничего плохого не происходит:

R4#ping 1.1.1.1 source lo0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 4.4.4.4!!!!!

1.1.1.1/32 есть в таблице маршрутизации R4, однако OSPF не импортирует маршрут из BGP, несмотря на настройки. Изменим это поведение и понаблюдаем за происходящим:

R4(config-router)#router bgp 1                  R4(config-router)#bgp redistribute-internal  R4#ping 1.1.1.1 source lo0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 4.4.4.4.....Success rate is 0 percent (0/5)

Связность между R4 и R1 пропала. R3 теперь считает, что маршрут до 1.1.1.1/32 лежит через R4, который в свою очередь шлёт пакеты обратно в сторону R2, что приводит к петле:

R4#traceroute 1.1.1.1 source lo0Type escape sequence to abort.Tracing the route to 1.1.1.1VRF info: (vrf in name/id, vrf out name/id)  1 192.168.34.3 28 msec 36 msec 16 msec  2 192.168.34.4 24 msec 20 msec 16 msec  3 192.168.34.3 32 msec 40 msec 44 msec  4 192.168.34.4 44 msec 36 msec 40 msec<output omitted>

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

Спасибо за рецензию: Анастасии Куралёвой

Подробнее..

BGPexplorer машина времени для IPMPLS сетей

10.06.2021 18:12:02 | Автор: admin
Предисловие

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

Современные сети, основанные на маршрутизации IP-пакетов, а точнее сервисы, которые они предоставляют, по факту управляются протоколом BGP. Этот протокол был спроектирован в конце 80-хх на трех салфетках. Да, с тех пор в этот протокол добавили массу возможностей, в том числе обмен маршрутной информацией VPN, правилами фильтрации трафика и всяким прочим полезным, но основа там осталась все той же, описанной на трех салфетках. И в этом есть свой плюс, потому что этот протокол в своей сути очень прост.

Но я хотел поговорить не о его простоте, а о "махании кулаками после драки", с которой частенько приходится сталкивать любой службе эксплуатации сети, или NOC - network operation centre (а может быть и center).

Поступает жалоба "а у меня вот сайт не открывается", или "вот час тому назад плохо работал сайт такой-то, а 5 минут тому назад он починился". Инженер идет на маршрутизатор и смотрит что маршрут к адресу рекомого сайта изменился 5 минут тому назад. И что с этим можно сделать? Чаще всего мало чего. Маршрутизатор знает, что вот такой маршрут "прилетел" 5 минут тому назад, а вот что было раньше? Может быть ничего существенного и не произошло, у маршрута обновились какие-нибудь информационные параметры, а пакеты как летели, так и летят в том же направлении. А может быть наоборот - маршрут изменился существенно и пакеты летят совсем в другом направлении. И узнать историю без дополнительного инструментария (или машины времени) нет возможности. И опять же - хорошо бы узнать, что же именно менялось. Да, есть глобальный инструмент bgplay. Но он рассчитан на использование в Интернете и запоминает изменения при перестроении маршрута между разными провайдерами. А вот изменения внутри сети одного провайдера он не ловит, да и не должен, так как не все то что происходит внутри автономной системы, должно быть видно снаружи.

И вот захотелось мне заиметь такой инструмент. Поиски готового ни к чему не привели (ни на что тут не претендую, может плохо искал). Соответственно, если нет готового решения - почему бы и не попробовать сделать самому? Все вроде понятно, собираем маршрутную информацию и храним историю изменений.

А вот дальше я подзавис. Самая лучшая библиотека, даже я бы сказал целый фреймворк, для обработки BGP - это пакет exabgp. Всем хорош и удобен. Один, на мой взгляд, существенный минус - он на python. Не то чтобы я был питононенавистником, отнюдь. Но каждый инструмент хорош, когда применяется по назначению. А python имеет всем известные особенности (интерпретатор, GIL), которые препятствуют эффективной обработке данных, если алгоритмы реализовывать именно на нем. И в данном случае мне хотелось бы иметь реализацию инструмента на компилируемом (как минимум) языке, с управляемыми политиками блокировок. А также иметь возможность выделить обработку протокола BGP в виде библиотеки и желательно чтобы применяемый язык мог позволить библиотеке жить без своего неотделимого и неотъемлемого рантайма (привет, golang!). Для чего? Ну, например, для того чтобы в перспективе применять эту библиотеку для других bgp-шных приложений. Ну и для скорости. Далеко не для всех видов запросов для поиска маршрутной информации возможно построить эффективный индекс.

Решил я попробовать в качестве основного языка по этой теме Rust и в общем все что хотел получилось. Работу с протоколом BGP выделил в библиотеку. В отличие от exabgp реализовывать логику работы BGP FSM в библиотеке я не стал, по той простой причине что в Rust для сети используется не одно API, std там строго синхронное, а в реальных задачах лучше иметь возможность применять по желанию и потребности асинхронные библиотеки. Библиотеку разумеется назвал zettabgp, а приложение bgpexplorer.

Принцип работы прост. Bgpexplorer может как выступать в роли bgp-спикера, то есть роутер (лучше всего route reflector) устанавливает с сервером bgp-соседство, и отдает в сторону сервера всю маршрутную информацию. Приложение накапливает в своей RIB (Routing Information Database) как актуальную маршрутную информацию, так и историческую. Для просмотра и поисковых запросов доступен веб-интерфейс. Сейчас все хранится в оперативной памяти и ее нужно достаточно много - в зависимости разумеется от того, какого объема таблицу маршрутизации нужно отслеживать.


Если интересно попробовать - то это просто. Нужна сеть, которую нужно мониторить и комп (сервер) с достаточно большим объемом ОЗУ чтобы маршрутная информация туда поместилась.

На сервере нужно взять исходники с гитхаба, предполагается что уже есть git и rust.

$ git clone https://github.com/wladwm/bgpexplorer...$ cd bgpexplorer$ cargo build...

Приложение собрано. Теперь на роутере настроим соседство с сервером.

Если это Cisco, то:

! Номер автономки тут 65535 разумеется для примера, как и адресаrouter bgp 65535 ! указываем адрес сервера с той же автономкой, чтобы сессия была IBGP neighbor 10.1.1.1 remote-as 65535 ! указываем с какого адреса соединяться neighbor 10.1.1.1 update-source Loopback0 ! будем ждать попыток соединения с сервера neighbor 10.1.1.1 transport connection-mode passive address-family ipv4 ! для паблик инета активируем  neighbor 10.1.1.1 activate ! отправляем на сервер вообще все что есть  neighbor 10.1.1.1 route-reflector-client ! Активируем если нужно ipv4 labeled-unicast  neighbor 10.1.1.1 send-label address-family vpnv4 ! включаем VPNv4  neighbor 10.1.1.1 activate  neighbor 10.1.1.1 send-community extended

Возвращаемся на сервер и подготовим конфигурационный файл для приложения

$ cat > bgpexplorer.ini <<EOF[main]httplisten=0.0.0.0:8080httproot=contribsession=s0whoisjsonconfig=whois.json[s0]mode=bmpactivebgppeer=10.0.0.1peeras=65535EOF

В секции main указываем:

  • httplisten на каком адресе и порту будет работать протокол http

  • httproot где лежит корень файлового сервиса. Там лежит index.html и все такое прочее.

  • Whoisjsonconfig указывает на файл конфигурации сервиса whois

  • Session это имя секции, описывающей режим работы bgp, в данном примере s0

В секции сессии (s0 в данном примере) указано:

  • bgppeer адрес роутера BGP для активного режима

  • Peeras номер автономной системы

  • protolisten адрес:порт, где ожидать входящего соединения по протоколу BGP или BMP

  • Mode варианты работы протокола

В mode можно указать:

  • bgppassive ждать входящего подключения от роутера

  • bgpactive инициировать подключение к роутеру

  • bmpactive инициировать подключение к роутеру по протоколу BMP

  • bmppassive ждать входящего подключения от роутера по протоколу BMP

После написания ini-файла можно запустить bgpexplorer, например, командой

cargo run

После чего можно открыть браузер и направить его на адрес сервера с указанием порта.

На самом верху будет выбор RIB для просмотра - IPv4, IPv6, VPN разные всякие и т.п.

Далее строка для фильтра, а уже после нее - пейджинг и собственно маршрутная информация.

Неактивные маршруты будут отображены серым курсивом. У маршрутов, у которых есть история изменений будет кнопка разворачивания истории.

В фильтре можно задавать кроме собственно подсетей фильтрацию по community, aspath, nexthop, route-target, route-distinguisher.

При наведении курсора на ASn, адреса роутеров будет выполняться запрос к whois или DNS, и полученная информация будет отображаться в попапе. Иногда это долго, но бывает полезно.


Буду рад, если этот инструмент пригодится еще кому-нибудь. Найденные проблемы, пожелания, идеи, конструктивная критика приветствуется.

Подробнее..

Из ничего к ЦОД с VXLANEVPN или как готовить Cumulus Linux. Часть 2

13.11.2020 04:15:27 | Автор: admin

Всем привет. Вот и подошло продолжение первой части. Как и обещал, в данной статье, я хочу затронуть основные варианты реализации фабрики на VXLAN/EVPN, и рассказать почему мы решили выбрать то или иное решение в нашем ЦОД.

Выбираем дизайн Underlay

Предисловие

Первое, с чем приходится сталкиваться при строительстве фабрики, это проработка дизайна Underlay - как мы хотим строить наши VXLAN туннели (точнее организовать поиск VTEP)?

Варианта у нас 3:

1.Статические туннели, в которых мы задаем каждый VTEP руками - это сразу не наш вариант, но, скажу по секрету, все еще есть провайдеры, которые ручками строят RSVP-TE туннели под каждый сервис. Так что не удивлюсь, если есть такие реализации в промышленном масштабе. Ну и никто не отменял SDN.

2.Multicast - в целом, простая реализация, но для нас вариант отпал сразу, т.к. Cumulus не умеет в подобную реализацию, да и Juniper в своих материалах говорит о его resourse-intensive и медленной сходимости.

3.BGP или BGP, или все-таки BGP? Как обычно, в случае когда нам нужен какой-нибудь широкий функционал, который был бы гибким, мы приходим к BGP, точнее в нашем случае к EVPN с сигнализацией по BGP. На нем и остановимся подробней. Так как бывает iBGP и eBGP, то и реализации underlay могут быть с каждым из них.

iBGP

При использовании iBGP у нас сразу же появляется потребность в IGP, будь то OSPF или IS-IS (хоть статика), т.к. строить мы будем до Loopback, а сообщать маршруты о том, как дойти до них, нам кто-то должен. Так же не забываем о том, как iBGP распространяет маршруты, что вынуждает нас строить full-mesh (в такой реализации Spine совсем ничего не знает о существовании BGP).

Или можем сделать Spine в роли Route-Reflector.

По итогу мы получаем как минимум 2 протокола маршрутизации и плюсом к этому full-mesh или RR. Это, конечно, не самое худшее что могло бы быть, но следующий вариант мне нравится больше.

eBGP

Данная реализация, на мой взгляд, самая понятная и надежная, и в итоге мы остановились на ней. Как только мы переходим к eBGP, потребность в Route-Reflector отпадает (надеюсь, все понимают почему), и продолжать использовать IGP тоже не имеет большого смысла, т.к. мы можем начинать строить соседства с p2p адресов. Так же в данном дизайне MLAG имеют более понятную реализацию. Про нее бы я остановился подробней. Оба MLAG свича помещаются в одну AS, т.к. при правильной реализации для всего остального VXLAN/EVPN домена они будут казаться одним устройством, что делает логичным их помещение в одну AS. Само соседство мы строим на peerlink'e, и это действительно необходимо, т.к. в случае, если у одного коммутатора упадут линки в сторону Spine, то он начнет дропать весь входящий трафик из-за того, что не будет маршрутов.

Единственное, что может кого-то спугнуть, это то, что нужно вести адресный план с номерами AS. Но счастливые обладатели Cumulus с версией 4.2(т.к. именно в ней это вышло) могут пойти другим путем, т.к. он теперь умеет автоматическое назначение AS, основываясь на MACе, что гарантирует вам уникальность (берет он из приватного пула 32-bit AS).
Так же стоит затронуть почему оба Spine находятся в одной AS. Т.к. каждый Spine имеет прямой линк к каждому Leaf, то трафик через него не может пройти дважды. Следовательно, мы можем использовать одинаковый номер AS на всех Spine, что собственно и советует Cumulus.
P.S. при использовании коротких AS можно все грамотно и красиво разделить, чтобы по номеру AS было понятно где был создан префикс. Так что использовать 32-bit AS совсем необязательно.

BGP Unnumbered

Думаю, многие не очень любят сталкиваться с адресным планированием p2p сетей, и как бы хотелось иметь только loopback и больше ничего. Если такие мысли вас когда-либо посещали, то стоит присмотреться к использованию Unnumbered. Реализация данного функционала в Cumulus отличается от Cisco, где у вас происходит заимствование адреса с интерфейса. Вместо этого у Cumulus выделен отдельный пул IPv6 адресов, которые динамически назначаются на интерфейс и по факту на них строится eBGP соседство. Так же на самом соседстве обязательно должен быть настроен extended-nexthop (для того, чтобы вы могли маршрутизировать IPv4 Family поверх IPv6 сессии).

P.S. Если на интерфейсах уже назначен какой-либо IPv4 /30 или /31 адрес, то BGP пиринг будет с них. Так же он не может работать в broadcast сетях, только p2p.

BGP+BFD

Как бы вы не хотели, но в любом случае таймеры самого BGP всегда будут измеряться секундами. И с учетом того, что сейчас появляются iSCSI, VSAN и т.д. такие задержки никто не может себе позволить. Как и во всех других протоколах маршрутизации нас спасает BFD. У Cumulus минимальные значения это 2x50 мс, насколько я знаю Cisco уже умеет 2х33 мс, так что данный функционал нам обязателен.

Что имеем в итоге?
1.Маршрутизация на eBGP с автоназначением AS + iBGP для MLAG пары
2.Из адресации нужны только loopback, все остальное нам заменяет Unnumbered
3.BFD

Настало время все настроить и посмотреть как оно работает

1.Как выглядит автоназначение AS у Cumulus

#Вариации у Cumulus при выборе AS#P.S. Для всех Spine мы можем использовать одну AS, т.к. тут не будет возникать петли по AS-pathcumulus@Switch1:mgmt:~$ net add bgp autonomous-system    <1-4294967295>  :  An integer from 1 to 4294967295    leaf            :  Auto configure a leaf ASN in the 4-byte private range 4200000000 - 4294967294 based on the switch                       MAC    spine           :  Auto configure a spine AS-number in the 4-byte private ASN range. The value 4200000000 is always                       used#Что по факту происходит при выборе "net add bgp autonomous-system leaf"cumulus@Switch1:mgmt:~$ net add bgp autonomous-system leafcumulus@Switch1:mgmt:~$ net pending+router bgp 4252968529 #Процесс BGP с автоматически сгенерированным AS+end

2.Конфигурация BGP+Unnumbered

#loopbacknet add loopback lo clag vxlan-anycast-ip 10.223.250.30 #При MLAG добавляется общий для пары IP (Он как раз и будет светится в маршрутахnet add loopback lo ip address 10.223.250.1/32#AS+Router IDnet add bgp autonomous-system leafnet add bgp router-id 10.223.250.1#Создаем стандартную конфигу для соседей через peer-groupnet add bgp neighbor fabric peer-group #Создаем саму peer группуnet add bgp neighbor fabric remote-as external #Обозначаем что это eBGPnet add bgp neighbor fabric bfd 3 50 50 #Классический BFDnet add bgp neighbor fabric capability extended-nexthop # IPv4 over IPv6#Задаем соседей через интерфейсы(Unnumbered)net add bgp neighbor swp2 interface peer-group fabric net add bgp neighbor peerlink.4094 interface remote-as internal #iBGP через Peerlinknet add bgp ipv4 unicast neighbor peerlink.4094 next-hop-self #Не забываем про next-hop для iBGPnet add bgp ipv4 unicast redistribute connected #Отдаем в BGP все свои сетки#EVPNnet add bgp l2vpn evpn neighbor fabric activate #Активируем family для eBGPnet add bgp l2vpn evpn neighbor peerlink.4094 activate #Активируем family для iBGPnet add bgp l2vpn evpn advertise-all-vni #Сообщаем BGP соседям о своих VNI 

3.BGP Summary

cumulus@Switch1:mgmt:~$ net show bgp summary#IPv4show bgp ipv4 unicast summary=============================BGP router identifier 10.223.250.1, local AS number 4252968145 vrf-id 0BGP table version 84RIB entries 29, using 5568 bytes of memoryPeers 3, using 64 KiB of memoryPeer groups 1, using 64 bytes of memoryNeighbor                       V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcdSwitch3(swp2)              4 4252424337    504396    484776        0    0    0 02w0d23h            3Switch4(swp49)             4 4208128255    458840    485146        0    0    0 3d12h03m            9Switch2(peerlink.4094) 4 4252968145    460895    456318        0    0    0 02w0d23h           14Total number of neighbors 3#EVPNshow bgp l2vpn evpn summary===========================BGP router identifier 10.223.250.1, local AS number 4252968145 vrf-id 0BGP table version 0RIB entries 243, using 46 KiB of memoryPeers 3, using 64 KiB of memoryPeer groups 1, using 64 bytes of memoryNeighbor                       V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcdSwitch3(swp2)              4 4252424337    504396    484776        0    0    0 02w0d23h          237Switch4(swp49)             4 4208128255    458840    485146        0    0    0 3d12h03m          563Switch2(peerlink.4094) 4 4252968145    460895    456318        0    0    0 02w0d23h          807Total number of neighbors 3

4.net show route

cumulus@Switch1:mgmt:~$ net show routeshow ip route=============Codes: K - kernel route, C - connected, S - static, R - RIP,       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,       F - PBR, f - OpenFabric,       > - selected route, * - FIB route, q - queued route, r - rejected route#Как видим все IPv4 адреса доступны через IPv6 (И да у Cumulus есть weight, аналогичный Cisco)C>* 10.223.250.1/32 is directly connected, lo, 02w0d23h #LoopbackB>* 10.223.250.2/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d23hB>* 10.223.250.6/32 [20/0] via fe80::ba59:9fff:fe70:e5c, swp49, weight 1, 3d12h19mB>* 10.223.250.7/32 [20/0] via fe80::ba59:9fff:fe70:e5c, swp49, weight 1, 3d12h19mB>* 10.223.250.9/32 [20/0] via fe80::ba59:9fff:fe70:e5c, swp49, weight 1, 3d12h19mC>* 10.223.250.30/32 is directly connected, lo, 02w0d23h #MLAG LoopbackB>* 10.223.250.101/32 [20/0] via fe80::1e34:daff:fe9e:67ec, swp2, weight 1, 02w0d23hB>* 10.223.250.102/32 [20/0] via fe80::1e34:daff:fe9e:67ec, swp2, weight 1, 02w0d23hB>* 10.223.250.103/32 [20/0] via fe80::1e34:daff:fe9e:67ec, swp2, weight 1, 02w0d23hB>* 10.223.252.11/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.12/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.20/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.101/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.102/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.103/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06h

5.traceroute + BFD

#traceroute полностью линуксовый (при желании можно пускать трассировку по TCP порту)cumulus@Switch1:mgmt:~$ traceroute -s 10.223.250.1 10.223.250.6vrf-wrapper.sh: switching to vrf "default"; use '--no-vrf-switch' to disabletraceroute to 10.223.250.6 (10.223.250.6), 30 hops max, 60 byte packets 1  10.223.250.7 (10.223.250.7)  1.002 ms  1.010 ms  0.981 ms # Все ответы идут с loopback интерфейсов 2  10.223.250.6 (10.223.250.6)  0.933 ms  0.917 ms  1.018 ms#Проверяем BFDcumulus@Switch1:mgmt:~$ net show bfd------------------------------------------------------------------------------------------port   peer                       state  local                      type       diag  vrf------------------------------------------------------------------------------------------swp2   fe80::1e34:daff:fe9e:67ec  Up     fe80::1e34:daff:fea6:b53d  singlehop  N/A   N/Aswp49  fe80::ba59:9fff:fe70:e5c   Up     fe80::1e34:daff:fea6:b510  singlehop  N/A   N/A

На данном этапе Underlay уже полностью готов к использованию, теперь можем перейти к Overlay.

Выбираем дизайн Overlay

Как понятно из названия статьи, Overlay у нас на VXLAN с поиском VTEP через EVPN. Но и тут не все так просто. Существуют 3 основных дизайна маршрутизации трафика между SVI, на них как раз и остановимся.

Centralized IRB

В данной реализации у нас появляется единая точка выхода из подсети, это centralized switch. Зачастую это несколько отдельных коммутаторов (active-active пара), которые занимаются только L3 форвардингом, а все остальные Leaf коммутаторы занимаются только L2. Дополнительно ко всему в такой реализации сentralized switch должен анонсировать EVPN type-2 маршрут (MAC+IP) c расширенным Default Gateway community(0x03). Так же не забываем что на centralized switch должны присутствовать VNI со всей фабрики.

*Все Leaf коммутаторы в MLAG паре*Все Leaf коммутаторы в MLAG паре

В моем понимании, данный дизайн выглядит хорошо только в том случае, когда взаимодействие между разными подсетями минимальны, или Leaf не умеют в L3. Но т.к. у нас в целевой фабрике планировалось очень много L3 взаимодействия, данный дизайн был отброшен сразу, чтобы не гонять лишний раз трафик.

Asymmetric IRB

Очень схожая по настройке реализация с Symmetric IRB (о которой ниже), но с одним исключением. Вся маршрутизация происходит на первом же VTEP, и последующим устройствам остаётся только отдать пакет по L2. При такой реализации необходимо, чтобы на каждом Leaf были все VNI+Vlan, что является платой за отказ от L3VNI.

P.S. На самом деле, средствами автоматизации можно прийти к тому, что конфигурация у всех устройств фабрики всегда одинаковая (следовательно есть все VNI). При таких условиях данный дизайн может быть очень даже не плох, с учетом избавления от необходимости выделения VLAN под каждый VRF. Но в условиях того, что на текущий момент автоматизация у нас только в зачаточном состоянии, вероятноcть человеческой ошибки слишком высока.

Symmetric IRB

При симметричной модели для всех L3 коммуникаций у нас создается отдельная сущность L3VNI, с которой ассоциируется VLAN. Именно данный функционал избавляет нас от необходимости иметь все VNI на каждом VTEP.

Для того, чтобы было понятно что происходит, давайте рассмотрим то, как пойдет пакет с VM2 на VM3. При попадании пакета на Leaf03/04, он делает route-lookup, в котором видит что VM3 доступна через Leaf05/06, а nexthop является L3VNI интерфейс. Далее уже Leaf05/06 получает данный пакет, снимает VXLAN заголовок и передает уже чистый пакет в SVI20. То есть помещение в нужный SVI идет именно на конечном устройстве, что как раз и избавляет нас от необходимости иметь его на всех устройствах, но L3VNI у нас должен быть везде.

Как итог мы выбирали именно этот дизайн для Overlay.

Заканчиваем с настройкой фабрики

Пора настроить уже сам Overlay и посмотреть, как у нас будет работать поиск VTEP и распространение маршрутов.

1.Создаем L3VNI

#VRF+VNInet add vrf Test vrf-table auto #Cоздаем VRF и автоматически назначаем RD+RTnet add vrf Test vni 200000 #Добавляем VNI к VRFnet add vxlan vniTest vxlan id 200000 #Создаем L3VNInet add vxlan vniTest bridge learning off #Отключаем изучение Маков, т.к. используется EVPNnet add vxlan vniTest vxlan local-tunnelip 10.223.250.1 #Адрес откуда строим туннель#VLANnet add vlan 2000 hwaddress 44:38:39:BE:EF:AC #Делается только для MLAG, что бы у Active-Active пары был один MACnet add vlan 2000 vlan-id 2000 #Номер вланаnet add vlan 2000 vlan-raw-device bridge #Добавление в bridgenet add vlan 2000 vrf vniTest #Ассоциация с VRFnet add vxlan vniTest bridge access 2000 #Ассоциируем VLAN с L3VNI

2.Создаем VNI

#VNInet add vxlan vni-20999 vxlan id 20999 net add vxlan vni-20999 bridge arp-nd-suppress on #Включаем функционал ARP-supress - уменьшаем BUM трафикnet add vxlan vni-20999 bridge learning off #Отключаем изучение Маков, т.к. используется EVPNnet add vxlan vni-20999 stp bpduguard # Включаем bpduguardnet add vxlan vni-20999 stp portbpdufilter # Включаем bpdufilternet add vxlan vni-20999 vxlan local-tunnelip 10.223.250.1 #Адрес откуда строим туннель#Создаем VLANnet add vlan 999 ip address 10.223.255.253/24 # IP на VLANnet add vlan 999 ip address-virtual 44:39:39:ff:01:01 10.223.255.254/24 #Виртуальный адрес (Для единого gateway на всех Leaf)net add vlan 999 vlan-id 999 #Номер вланаnet add vlan 999 vlan-raw-device bridge #Добавление в bridgenet add vlan 999 vrf Test #Ассоциация с VRFnet add vxlan vni-20999 bridge access 999 #Ассоциируем VLAN с VNI#P.S. Это конфига если нам нужен L2 only vlan (Конфигурация VNI не меняется)net add vlan 999 ip forward offnet add vlan 999 vlan-id 999net add vlan 999 vlan-raw-device bridge

3.Настройка соседства с внешней инфраструктурой

#Создаем самый обычный BGP процесс в VRFnet add bgp vrf Test autonomous-system 4252424337net add bgp vrf Test router-id 10.223.250.101net add bgp vrf Test neighbor 100.64.1.105 remote-as 35083net add bgp vrf Test ipv4 unicast redistribute connectednet add bgp vrf Test ipv4 unicast redistribute staticnet add bgp vrf Test ipv4 unicast neighbor 100.64.1.105 route-map Next-Hop-VRR_Vl997 out #Конфига для корректной работы MLAG+VSS через BGP+SVI, это стоило пару дней мучений для понимания#P.S. Стоит так же заметить что в инфру будут отдаваться /32 префиксы которые генерирует EVPN, в нашем случая я их фильтровал на принимающей стороне.net add bgp vrf Test l2vpn evpn  advertise ipv4 unicast #Отдаем полученные маршруты в EVPN

На данном этапе с конфигурацией мы закончили, теперь предлагаю посмотреть как это все выглядит:

#VNIcumulus@Switch1:mgmt:~$ net show evpn vniVNI     Type VxLAN IF      MACs   ARPs   Remote VTEPs  Tenant VRF20995   L2   vni-20995     5        3        1               default #VNI, если нет IP на SVI20999   L2   vni-20999     26       24       4               Test    #VNI200000  L3   vniTest        3        3        n/a             Test    #Сам L3VNI#VNI подробнейcumulus@Switch1:mgmt:~$ net show evpn vni 20999VNI: 20999 Type: L2 Tenant VRF: Test VxLAN interface: vni-20999 VxLAN ifIndex: 73 Local VTEP IP: 10.223.250.30 #При наличии MLAG, будет использоватся vxlan-anycast-ip Mcast group: 0.0.0.0 #Не используется Remote VTEPs for this VNI: #Те у кого так же есть данный VNI  10.223.250.9 flood: HER #Используем Head-end Replication (Так же известно как Ingress replication)  10.223.252.103 flood: HER  10.223.252.20 flood: HER  10.223.250.103 flood: HER Number of MACs (local and remote) known for this VNI: 26 Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 24 Advertise-gw-macip: No #Community при centralized IRB
#Таблица с тем откуда изучены макиcumulus@Switch3:mgmt:~$ net show evpn mac vni 20999Number of MACs (local and remote) known for this VNI: 28Flags: B=bypass N=sync-neighs, I=local-inactive, P=peer-active, X=peer-proxyMAC               Type   Flags Intf/Remote ES/VTEP            VLAN  Seq #'s0c:59:9c:b9:d8:dc remote       10.223.250.30                        0/00c:42:a1:95:79:7c remote       10.223.250.30                        0/0#Таблица MAC,где видим Interface VNIcumulus@Switch3:mgmt:~$ net show bridge macs vlan 999VLAN  Master  Interface  MAC                TunnelDest  State      Flags         LastSeen----  ------  ---------  -----------------  ----------  ---------  ------------  ----------------- 999  bridge  bridge     1c:34:da:9e:67:68              permanent                24 days, 04:35:13 999  bridge  bridge     44:39:39:ff:01:01              permanent                14:26:45 999  bridge  peerlink   1c:34:da:9e:67:48              permanent                31 days, 17:22:36 999  bridge  peerlink   1c:34:da:9e:67:e8              static     sticky        24 days, 04:14:16 999  bridge  vni-20999  00:16:9d:9e:dd:41                         extern_learn  19 days, 04:17:21 999  bridge  vni-20999  00:21:1c:2e:86:42                         extern_learn  19 days, 04:17:21 999  bridge  vni-20999  00:22:0c:de:30:42                         extern_learn  19 days, 04:17:21#Маки самих VTEPcumulus@Switch3:mgmt:~$ net show evpn rmac vni allVNI 200000 RMACs 3RMAC              Remote VTEP44:38:39:be:ef:ac 10.223.250.3044:39:39:ff:40:94 10.223.252.10344:38:39:be:ef:ae 10.223.250.9#Arp-cachecumulus@Switch3:mgmt:~$ net show evpn arp-cache vni 20999Number of ARPs (local and remote) known for this VNI: 28Flags: I=local-inactive, P=peer-active, X=peer-proxyNeighbor                  Type   Flags State    MAC               Remote ES/VTEP                 Seq #'s10.223.255.242            local        active   1c:34:da:9e:67:68                                0/010.223.255.13             remote       active   0c:42:a1:96:d2:44 10.223.250.30                  0/010.223.255.243            local        inactive 06:73:4a:02:27:8a                                0/010.223.255.7              remote       active   0c:59:9c:b9:f8:fa 10.223.250.30                  0/010.223.255.14             remote       active   0c:42:a1:95:79:7c 10.223.250.30                  0/0
#Таблица маршрутизацииcumulus@Switch1:mgmt:~$ net show route vrf Test | grep "10.3.53"//Как видим все next-hop vlan2000, который мы отдали раньше под L3VNIC * 10.223.255.0/24 [0/1024] is directly connected, vlan999-v0, 03w3d04hC>* 10.223.255.0/24 is directly connected, vlan999, 03w3d04hB>* 10.223.255.1/32 [20/0] via 10.223.250.30, vlan2000 onlink, weight 1, 02w5d04hB>* 10.223.255.2/32 [20/0] via 10.223.250.30, vlan2000 onlink, weight 1, 02w5d04hB>* 10.223.255.3/32 [20/0] via 10.223.250.30, vlan2000 onlink, weight 1, 02w5d04h#Пример вывода EVPN маршрутаcumulus@Switch3:mgmt:~$ net show bgp evpn route vni 20999BGP table version is 1366, local router ID is 10.223.250.101Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incompleteEVPN type-1 prefix: [1]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP]EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]   Network          Next Hop            Metric LocPrf Weight Path*> [2]:[0]:[48]:[00:16:9d:9e:dd:41]                    10.223.250.30                          0 4252968145 i                    RT:9425:20999 RT:9425:200000 ET:8 Rmac:44:38:39:be:ef:ac*> [2]:[0]:[48]:[00:22:56:ac:f3:42]:[32]:[10.223.255.1]                    10.223.250.30                          0 4252968145 i                    RT:9425:20999 RT:9425:200000 ET:8 Rmac:44:38:39:be:ef:ac

Заключение

Как итог, мы получили готовую VXLAN/EVPN фабрику. В Underlay у нас Unnumbered BGP и больше ничего, а в качестве Overlay мы имеем VXLAN/EVPN c Symmetric IRB, чего для решения наших задач в ЦОД более чем достаточно. Данный дизайн так же можно растянуть и на сами сервера, что бы строить туннели непосредственно с них.

Конечно, я не затронул всех возможных дизайнов по типу маршрутизации на Spine, но такой цели и не преследовалось. Надеюсь, статья кому-нибудь придётся по душе и будет полезна в планировании или эксплуатации собственного ЦОД. В случае, если есть идеи по улучшению или заметили критическую ошибку, прошу в комментарии.

Подробнее..

Внедрение Multicast VPN на Cisco IOS (часть 4 BGP сигнализация)

27.11.2020 00:13:20 | Автор: admin
В предыдущих выпусках:

Profile 0
Profile 1
Profile 3

В этой части статьи мы рассмотрим с Вами вариант замены сигнализации в рамках наложенной сети с протокола PIM на BGP.

Как рассматривалось ранее (см статью про BGP Auto-Discovery), для того чтобы передавать аналоги PIM сообщений, в BGP было придумано несколько типов маршрутов, каждый из которых несёт в себе определённый функционал. При этом типов маршрутов больше, чем есть типов сообщений у PIM.



Зачем натягивать сову на глобус? можете спросить Вы, ведь всё прекрасно работает и с PIM. И, в общем-то, будете правы. Основной причиной эдакого ходя конём является масштабируемость. PIM, являясь по сути своей Soft Driven протоколом, требует для своей работы постоянной рассылки служебных сообщений, что при определённом размере внедрения (если количество узлов начинает переваливать за пару сотен или тысяч) привносит ограничения в связи с неизбежной загрузкой CPU. BGP же является Hard Driven протоколом т.е. если что-то было сказано однажды, то не повторяется; любые BGP обновления вызваны исключительно изменениями в сети.

Сегодня мы с Вами рассмотрим два сценария: использование PIM SSM и PIM ASM в рамках C-VRF.

C-PIM SSM


Для более простого понимания BGP сигнализации для построения многоадресных деревьев, начнём наш разговор с более простого PIM SSM.

Прежде всего, уберём текущие настройки точки рандеву и отключим получателей трафика:

CE4(config)#interface Loopback0CE4(config-if)#no ip igmp join-group 231.1.1.2CE4(config-if)#CE15(config)#no ip pim bsr-candidate Loopback0 0CE15(config)#no ip pim rp-candidate Loopback0 group-list 1

На всех РЕ укажем, что для сигнализации вместо PIM будет работать BGP. Это делается следующей командой:

ip vrf C-ONEmdt overlay use-bgp

Отправной точкой наблюдений будет ситуация без наличия источников и получателей многоадресного трафика. В BGP таблице должны присутствовать только type-1 маршруты:

PE1#show bgp ipv4 mvpn allBGP table version is 406, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Подключим получателя:

CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11

На ближайшем РЕ создаётся BGP маршрут 7-го типа это эквивалент сообщения PIM (S, G) Join:

PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>  [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/220.0.0.0              32768 ?

По логике вещей, данный маршрут должен присутствовать только на РЕ4 и на РЕ1 (т.к именно через них должен проходить трафик) и отсутствовать на РЕ2 и РЕ3. Проверим:

PE1#show bgp ipv4 mvpn all | b \[7\]*>i [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/224.4.4.4         0  100   0 ?PE2#show bgp ipv4 mvpn all | b \[7\]PE2#PE3#show bgp ipv4 mvpn all | b \[7\]PE3#

Как так получается, что маршрут, изначальной порождённый на РЕ4, импортируется только на РЕ1?

Посмотрим на запись в BGP-таблице чуть детальнее:

PE4#show bgp ipv4 mvpn all route-type 7 1.1.1.1:1 65001 11.11.11.11 230.1.1.1BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:7Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

В записи префикса присутствует расширенное коммьюнити Route-target = 1.1.1.1:1, которое было добавлено в vpnv4 префикс маршрутизатором, который с точки РЕ4 является RPF соседом:

PE1#show bgp vpnv4 unicast rd 1.1.1.1:1 11.11.11.11/32BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1     17Refresh Epoch 465011172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)Origin IGP, metric 0, localpref 100, valid, external, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1mpls labels in/out 10018/nolabelrx pathid: 0, tx pathid: 0x0PE1#PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 15265011, imported path from 1.1.1.1:1:11.11.11.11/32 (global)1.1.1.1 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10018rx pathid: 0, tx pathid: 0x0

Проверим связность:

CE1#ping 230.1.1.1 so 11.11.11.11 rep 3Type escape sequence to abort.Sending 3, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11Reply to request 0 from 14.14.14.14, 7 msReply to request 0 from 14.14.14.14, 8 msReply to request 1 from 14.14.14.14, 7 msReply to request 1 from 14.14.14.14, 9 msReply to request 2 from 14.14.14.14, 7 msReply to request 2 from 14.14.14.14, 7 ms

C-PIM ASM


В случае работы C-PIM в режиме SSM всё довольно просто. Для корректной работы mVPN достаточно создания двух дополнительных (типов) BGP маршрутов.

А как обстоят дела, если внутри C-VRF используется более комплексный ASM PIM?

Прежде всего мы видим, что на всех СЕ известна информация о точке рандеву:

CE2#show ip pim rp mappCE2#show ip pim rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 231.1.1.0/24RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 1d04h, expires: 00:02:09CE2#

Как? Если мы посмотрим BGP таблицу, то не найдём там никакого намёка на эту точку:

PE1#show bgp ipv4 mvpn allBGP table version is 682, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Не надо забывать о том, что у нас есть PMSTI, на котором активирован PIM:

PE1#show ip pim vrf C-ONE interfaceAddress     Interface        Ver/  Nbr  Query DR     DRMode  Count Intvl Prior172.1.11.1    GigabitEthernet2.111   v2/S  1   30   1     172.1.11.11172.1.15.1    GigabitEthernet2.115   v2/S  1   30   1     172.1.15.151.1.1.1     Tunnel2         v2/S  0   30   1     1.1.1.1



Отсюда можно сделать важный вывод некоторые сообщения PIM (даже при BGP сигнализации) передаются поверх опорной сети в рамках Default MDT.


Представим, что в сети появился источник (за маршрутизатором СЕ2). Поскольку на СЕ2 на данный момент нет записей в mRIB, то PIM Designated Router (в нашем случае это сам СЕ2) отправляет сообщение Register на точку рандеву, тем самым сигнализируя о наличии активного источника в сети.


На точке рандеву создаётся дерево (12.12.12.12, 231.1.1.1):

CE5#show ip mroute | b \((*, 231.1.1.1), 00:00:19/stopped, RP 15.15.15.15, flags: SPIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list: Null(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: PIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing interface list: Null

И, поскольку, в сети нет активных получателей трафика (отсутствует дерево (*, 231.1.1.1)), то со стороны CE5 создаётся сообщение Register-Stop



В ответ на получение Register-Stop, CE2 приостанавливает передачу данных (нет интерфейсов в OIL):

CE2#show ip mroute 231.1.1.1(12.12.12.12, 231.1.1.1), 00:00:07/00:02:54, flags: PFTIncoming interface: Loopback0, RPF nbr 0.0.0.0Outgoing interface list: Null

Теперь представим, что в сети появился получатель, заинтересованный в трафике для группы 231.1.1.1. На РЕ4 появляется маршрут внутри C-VRF:

PE4#show ip mroute vrf C-ONE 231.1.1.1 | b \((*, 231.1.1.1), 00:00:44/00:02:45, RP 15.15.15.15, flags: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:44/00:02:45

И создаётся BGP маршрут 6-го типа, который является эквивалентом PIM Join (*, 231.1.1.1):

PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>  [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/220.0.0.0              32768 ?PE4#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

В приведённом выше выводе необходимо обратить внимание на расширенное коммьюнити Route-target = 1.1.1.1:1. Что это и откуда взялось?

Проверим наличие данного префикса на других РЕ:

PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1% Network not in tablePE3#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1% Network not in tablePE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698Paths: (1 available, best #1, table MVPNv4-BGP-Table)Not advertised to any peerRefresh Epoch 2Local4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:1.1.1.1:1Originator: 4.4.4.4, Cluster list: 8.8.8.8rx pathid: 0, tx pathid: 0x0

Т.е. префикс существует только на РЕ1. Что интересно, так это тот факт, что точка рандеву (15.15.15.15) находится именно на сайте за РЕ1.

Зная назначение Route-target (импорт маршрутов внутрь определённой VRF) напрашивается вывод RT = 1.1.1.1:1 известен РЕ1 и неизвестен РЕ2/PE3. Т.е очевиден факт, что РЕ4 сгенерировал BGP маршрут, описывающий PIM Shared Tree Join таким образом, чтобы он был обработан только на том РЕ, за которым в действительности находится точка рандеву (по факту, это аналог передачи PIM Join через RPF интерфейс). Но каким образом РЕ1 и РЕ4 согласуют между собой значения Route-target?

PE4 проводит RPF для адреса точки рандеву:

PE4#show ip rpf vrf C-ONE 15.15.15.15RPF information for ? (15.15.15.15)RPF interface: Tunnel0RPF neighbor: ? (1.1.1.1)RPF route/mask: 15.15.15.15/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 1.1.1.1RPF topology: ipv4 multicast base, originated from ipv4 unicast base

В качестве RPF соседа виден РЕ1. Значит, РЕ4 должен поместить внутрь маршрута 6-го типа такой Route-target, который будет импортирован только РЕ1. Чтобы ответить на вопрос откуда РЕ4 его знает? посмотрим, для начала, на vpn маршрут:

PE4#show bgp vpnv4 unicast vrf C-ONE 15.15.15.15/32BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 165015, imported path from 1.1.1.1:1:15.15.15.15/32 (global)1.1.1.1 (metric 3) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10013rx pathid: 0, tx pathid: 0x0

Обратите внимание на дополнительное коммьюнити MVPN VRF:1.1.1.1:1. Это ничто иное, как коммьюнити Route Import, сгенерированное РЕ1. Именно это значение копируется как Route-target внутрь многоадресного маршрута, что позволяет РЕ1 импортировать полученный апдейт от РЕ4.

Результатом обработки BGP маршрут 6-го типа на РЕ4 является создание записи в многоадресной таблице маршрутизации:

PE4#show ip mroute vrf C-ONE(*, 231.1.1.1), 00:23:31/00:02:33, RP 15.15.15.15, flags: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:23:31/00:02:33

Прим обратите внимание, что входным интерфейсом указан Tunnel0 (PMSTI).

На точке рандеву завершается создание общего дерева:

CE5#show ip mroute | b \((*, 231.1.1.1), 00:25:42/00:03:22, RP 15.15.15.15, flags: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.115, Forward/Sparse, 00:25:42/00:03:22



Теперь, если в сети опять появится активный источник трафика, точка рандеву будет знать как совместить (*, 231.1.1.1) и (12.12.12.12, 231.1.1.1) деревья.

CE5#show ip mroute | b \((*, 231.1.1.1), 00:47:12/stopped, RP 15.15.15.15, flags: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.115, Forward/Sparse, 00:47:12/00:02:31(12.12.12.12, 231.1.1.1), 00:00:23/00:02:43, flags: PTIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing interface list: Null

Точка рандеву создаёт PIM Join (12.12.12.12, 231.1.1.1), отправляя его в сторону CE2. PE1 получает указанный PIM Join и создаёт BGP маршрут 7-го типа:

PE1#show bgp ipv4 mvpn allRoute Distinguisher: 2.2.2.2:1*>  [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/220.0.0.0              32768 ?PE1#show bgp ipv4 mvpn all route-type 7 2.2.2.2:1 65001 12.12.12.12 231.1.1.1BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (1.1.1.1)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:2.2.2.2:1rx pathid: 1, tx pathid: 0x0

Обратите внимание, что в качестве Remote VPN RD выставляется значение 2.2.2.2:1, т.к. именно через РЕ2 завершается RPF проверка маршрута:

PE1#show ip rpf vrf C-ONE 12.12.12.12RPF information for ? (12.12.12.12)RPF interface: Tunnel2RPF neighbor: ? (2.2.2.2)RPF route/mask: 12.12.12.12/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 2.2.2.2RPF topology: ipv4 multicast base, originated from ipv4 unicast base

И RT 2.2.2.2:1 был добавлен в VPNv4 префикс со стороны РЕ2:

PE1#show bgp vpnv4 unicast vrf C-ONE 12.12.12.12BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 265012, imported path from 2.2.2.2:1:12.12.12.12/32 (global)2.2.2.2 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1Originator: 2.2.2.2, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 2.2.2.2:1:2.2.2.2mpls labels in/out nolabel/31rx pathid: 0, tx pathid: 0x0

На этом шаге, по сути, завершается построение дерева (12.12.12.12, 231.1.1.1) на участке между источником и точкой рандеву:


После получения маршрута 7-го типа, РЕ2 генерирует маршрут 5-го типа, сигнализируя о наличии активного источника трафика в сети. Маршрут импортируется всеми РЕ устройствами.

PE2#show bgp ipv4 mvpn allRoute Distinguisher: 2.2.2.2:1 (default for vrf C-ONE)*>  [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/180.0.0.0              32768 ?PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (2.2.2.2)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestCommunity: no-exportExtended Community: RT:65001:1rx pathid: 0, tx pathid: 0x0

При получении маршрута 5-го типа, на РЕ4 (где находится получатель) завершается создание многоадресного дерева:

PE4#show ip mroute vrf C-ONE(12.12.12.12, 231.1.1.1), 00:22:24/00:02:51, flags: TnQIncoming interface: Tunnel0, RPF nbr 2.2.2.2Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19

Прим обратите внимание на флаг Q, который говорит о том, что запись была создана благодаря сообщению BGP Source-Active


Рассмотренный вариант организации mVPN носит кодовое имя Profile 11. Его основные характеристики:

  • для передачи многоадресного трафика наложенной сети используется Default MDT
  • в качестве метода организации транспорта выступает протокол mGRE
  • для сигнализации многоадресного дерева в рамках наложенной сети используется протокол BGP
Подробнее..

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

05.04.2021 22:14:08 | Автор: admin

Близится кожаная свадьба Роскомнадзора с Телеграмом, 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 есть решение от Александра Рыжова. Оно, конечно, базируется на старой версии сервиса, но легко корректируется под новую.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru