Ipv6

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

В большинстве случаев произвольная смена адреса, выданного администратором, не несет абоненту практической пользы, т.к. может отсечь его от сети. Более опытный пользователь знает про коллизию адресов и может этим злоупотребить: назначить своему устройству уже занятый адрес, тем самым лишив изначального хозяина IP-адреса возможности использовать сеть. В обычных сетях за подобным хулиганством бдит администратор, а что происходит в масштабируемых сетях с автоматической маршрутизацией, где контроль за пользователями вовсе отсутствует? Разберем решение этой задачи в Yggdrasil Network масштабируемой меш-сети с оконечным шифрованием и IPv6-маршрутизацией.

Никакого мошенничества

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

Первый байт 02 адреса IPv6-Yggdrasil является константой, а дальше интереснее: от публичного ключа x25519 берется хеш SHA512, количество лидирующих единиц которого, т.е. битов, установленных в ненулевом состоянии, образует второй байт.

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

Таким образом получается бесконфликтная сеть, где при масштабировании небольшого сегмента сети, например, при подключении локального сегмента к глобальному через публичный пир, не возникает опасности коллизии адресов. Это обуславливается почти безграничным множеством вероятных ключей x25519, случайно генерируемых при первом запуске Yggdrasil.

Почва для размышлений

Хеш SHA512 составляет 64 байта, в том время как адрес IPv6 даже с учетом константы 02 всего лишь 16 байт, а изначальный ключ x25519 32 байта.

Некоторые пользователи сомневаются в практической пользе такого решения и считают, что вполне реально найти ключи с коллизией адресов, т.к. массив данных ключа увеличивается вдвое, а затем от него берется лишь небольшая часть (примерно 1/5), которая образует IPv6. При всем желании, модель угрозы нахождения разных ключей с одинаковым адресом не была подтверждена практически, что говорит о сложно исчислимом количестве вариаций адресов даже при таком на первый взгляд необычном подходе к их образованию.

Разработчики Yggdrasil постарались усложнить подбор адресов. Первые непрерывно идущие единичные биты создают дополнительный фактор уникальности адреса. Вероятность подобрать последовательность из последних 14 байт IPv6 кажется весьма реалистичной, однако общий успех менее вероятен, т.к. напрямую зависит от количества лидирующих единиц в хеше 2-го байта. Отсюда выходит понятие высокого адреса адреса с большим значением во втором байте и, следовательно, с более обширным использованием 64-байтного массива от SHA512. Исходя из этого, имеет смысл майнить высокие адреса для серьезных проектов.

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

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

• К 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-версия отчетадоступна для скачивания по ссылке.

В этом году ENOG17 и Региональная Встреча RIPE NCC будут проходить с 9 по 13 ноября в форме виртуального мероприятия.

Традиционно, главными темамиENOGявляются технологии интернет, передовые подходы к управлению сетями, взаимодействие сетей, а также вопросы сотрудничества и координации между игроками Интернет-рынка.

Впервые конференция ENOG прошла в 2011 году в Москве. С тех пор она проводилась в разных городах и странах: России (Москва, Санкт-Петербург и Казань), Украине (Киева и Одесса), Азербайджане (Баку), Армении (Ереван), Беларуси (Минск), Грузии (Тбилиси). В онлайн-формате конференция проводится впервые, хотя формат удаленных докладов для неё не нов (например, в 2018 году Женя Линькова из Google в Москве рассказывала про IPv6 в корпоративных сетях из Австралии).

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

Программному комитету конференции ищет доклады о проблемах, инструментах, опыте работы и тенденциях в таких областях, как:

• Ключевые интернет- и сетевые технологии

  • Новые протоколы и технологии: сегментная маршрутизация, QUIC, 5G и др.

  • Протоколы внутренней и внешней маршрутизации

  • Опыт внедрения новых технологий (например, IPv6 и DNSSEC), тенденции и статистика

  • Программно-определяемые сети и автоматизация сети

  • Интернет вещей (IoT)

• Тенденции развития интернета

  • Новые технологии, области их использования и эволюция экосистем Интернета

  • Интернет-измерения, аналитика и прогнозы развития Интернета

• Координация, управление и регулятивная практика в интернете

  • Относящееся к Интернету законодательство и его влияние, многосторонняя модель, препятствия и возможности

  • Общественные инициативы и проекты в области управления использованием Интернета, координации, исследования и внедрения новых технологий

• Пиринг и точки обмена трафиком

  • Коммерческие, технические и социальные аспекты сетевого взаимодействия

• Эксплуатация сетей и сетевая безопасность

  • Практический опыт и лучшие передовые методы, тенденции в сетевой безопасности и сопутствующих технологиях, обзор рисков.

  • Предотвращение DDoS-атак

• Доставка контента (CDN)

  • Технологии, архитектура и бизнес-модели

Если вы хотите предложить свой доклад для включения в программуENOG17, пожалуйста, предоставьте тезисы доклада и черновой вариант презентации с помощью онлайн-системы:
https://www.enog.org/ru/submit-topic/submission-form/.

Докладчики должны указать, сколько времени требуется на доклад. Обычно время выделяется согласно формату доклада:

• Пленарный доклад: 20-25 минут презентации и 5-10 минут обсуждения

• Учебные курсы и мастер-классы: до трех часов

• BoF-сессия: приблизительно один час в вечернюю сессию

• Блиц-доклад: 10 минут в сумме на презентацию и обсуждение

(Конечно, при необходимости можно обсудить и создание нового формата)

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

Правила подачи заявок и форматы презентаций опубликованы здесь.

Для участия с докладом в пленарной части конференции или семинаром просим вас прислать тезисы не позднее 11 октября. Тезисы и доклады принимаются на русском и английском языках. Во время конференции обеспечивается синхронный перевод всех пленарных докладов. Доклады рекламного или коммерческого характера не принимаются.

Если вы можете порекомендовать интересный доклад и докладчика, пришлите, пожалуйста, свое предложение в Программный комитет.

С начала этого года в России стала эксплуатироваться Национальная Система Доменных Имён - НСДИ, о чём уже можно почитать на Хабр, а провайдерам и владельцем автономных систем РКН рассылает письма с требованиями к ней подключиться. По своей сути это набор из публичных DNS серверов, доступный всем желающим и предлагаемый к использованию как провайдерам так и конечным пользователям Интернет. К своему сожалению, я слабо представляю как конкретно организована и функционирует глобальная система доменных имён, или как организована работа серверов обслуживающих, например, зону RU., и надеюсь это статьёй, в том числе, привлечь внимание к этому вопросу людей которые в этом разбираются или участвуют в этом процессе - это должно быть очень интересно и познавательно, для того чтобы об этом рассказать всем. Поэтому мой первый взгляд будет про адресацию, маршрутизацию, задержки, для чего будет использованы, в том числе, средства RIPE Atlas, и, конечно, про DNS, но ровно настолько насколько я в этом понимаю. Отличительной особенностью именно этой национальной системы является её доступность для исследований, поэтому надеюсь мой первый взгляд, будет продолжен и подхвачен, чтобы рассмотреть этот вопрос со всех сторон.

Из уже упомянутой выше статьи по ссылкам можно найти оригинальное письмо РКН, из которого мы знаем что существуют:

• 194.85.254.37 - корневой DNS сервер позволяющий, помимо прочего, выполнять запрос AXFR, то есть получать корневую зону "как есть", но для этого надо попасть в список доверенных серверов и такой возможности у меня нет

• a.auth-nsdi.ru, b.auth-nsdi.ru - тоже корневые DNS, позволяющие не рекурсивно запрашивать записи из корневой зоны

• a.res-nsdi.ru, b.res-nsdi.ru - рекурсивные резолверы, позволяющие запрашивать любую запись

Сразу обращу ваше внимание на то, что система находится в очень подвижном состоянии, как и положено любой системе на начальном этапе эксплуатации, да и вообще системе в Интернет. И дотошный читатель наверняка уже нашёл, что существуют, например, c.auth-nsdi.ru и d.auth-nsdi.ru, пока не отвечающие на запросы. Но это значит, что через пару месяцев или недель ситуация, как она описывается в этой статье, может поменяться кардинально. Помните об этом.

Корневые серверы

194.85.254.37 принадлежит блоку 194.85.254.0/24, который появился отдельной строчкой в RIR и тогда же стал анонсироваться в глобальную таблицу Интернет маршрутизации меньше года назад - в августе 2020 года, источником анонсов является AS62135. Отвечает на CHAOS TXT запросы:

• version.bind - "PowerDNS Authoritative Server 4.4.0-alpha3.125.master.g6835270cd (built Nov 16 2020 18:13:24 by root@b6b5979d40d3)"

• id.server - mu.cmu.msk-ix.ru

Есть поддержка NSID - "mu.cmu.msk-ix.ru", и насколько можно судить по данным RIPE Atlas этот сервер представлен в единственной точке присутствия в центральной европейской части России.

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

a.auth-nsdi.ru и b.auth-nsdi.ru представлены в IPv4 и IPv6 и входят в блоки 195.208.6.0/24, 2a0c:a9c7:a::/48,195.208.7.0/24 и 2a0c:a9c7:b::/48, которые появились отдельными строчками в RIR и начали анонсироваться в конце осени, начале зимы 2020. Все от имени AS41740 c as-name NDNS. Всего с той же AS анонсируется 12 префиксов, которые мы ещё встретим дальше:

193.232.147.0/24, 193.232.253.0/24, 195.208.5.0/24, 195.208.4.0/24, 195.208.6.0/24, 195.208.7.0/24, 2a0c:a9c7:a::/48, 2a0c:a9c7:253::/48, 2a0c:a9c7:147::/48, 2a0c:a9c7:b::/48, 2a0c:a9c7:9::/48, 2a0c:a9c7:8::/48

Также поддерживается NSID и запрос CHAOS TXT id.version. На основе которых по отчётам RIPE Atlas (30376498, 30376499, 30376500, 30376501) можно сделать выводы что задействовано несколько точек присутствия и механизмы распределения трафика между ними.

Здесь мы уже видим подвижность. Несколько NSID в ответах в разное время, даже за не очень большой период сбора данных. Полужирным шрифтом отмечен последний из ответов NSID. Вторая ячейка это ответы на IPv6 запросы где тоже видим разницу по сравнению с IPv4. Что-то можно будет списать на отличную от IPv4 связность в IPv6, не всё ещё с этим в порядке, а где-то, вероятно, это особенности реализации, время ответов и выбор серверов, иногда, уж очень сильно отличаются. Впрочем, запросы к разным серверам НСДИ и разные NSID, даже в IPv4, могут возникнуть по причинам маршрутизации и связности в Интернет, а не по причинам изменений внутри НСДИ, но для этого нужен более детальный анализ нежели мы здесь приводим. Всего попалось 14 разных идентификатора, с говорящими названиями.

auth1-ekt.ix.ru, auth1-khouse.ix.ru, auth1-kzn.ix.ru, auth1-nsk.ix.ru, auth1-rnd.ix.ru, auth1-spb.ix.ru, auth1-vlv.ix.ru, auth2-ekt.ix.ru, auth2-khouse.ix.ru, auth2-kzn.ix.ru, auth2-nsk.ix.ru, auth2-rnd.ix.ru, auth2-spb.ix.ru, auth2-vlv.ix.ru

Несмотря на то, что у меня нет возможности сделать AXFR запрос и сравнить корневые зоны на идентичность Root Zone File, можно сделать обычные запросы по каждой из записей в корневой зоне и сравнить результаты. Несколько однострочников в Bash, чтобы убедиться что корневая зона отдаваемая серверами НСДИ идентична эталонной. В этом мне помогла одна особенность на которую я обратил внимание, возможно, присущую конкретной версии используемых серверов и которая касается DNSSEC и записей NSEC. Не все корневые серверы, возвращают эту запись по прямому запросу, а только в случае NXDOMAIN,корневые НСДИ серверы - возвращают. Таким образом задача решается одним запросом dig +dnssec для каждой строчки из Root Zone File с последующим сравнением. Совсем чуть-чуть придётся поработать с представлением отдаваемых данных, например, привести адреса IPv6 к одному формату, в эталонном файле они приводятся без применения правил сокращения, запретить dig форматировать base64 строчки +nosplit и ещё не забыть про IDN - +noidnout. Результат, насколько я могу судить, не отличается от эталонного. Конечно, интересно было бы следить за этим постоянно, измерять, например, задержки между публикациями зоны и распределением её по серверам НСДИ, но оставим это для следующих авторов.

Рекурсивные резолверы

a.res-nsdi.ru и b.res-nsdi.ru - тоже представлены в IPv4 и IPv6: 195.208.4.0/24, 2a0c:a9c7:8::/48,195.208.5.0/24 и 2a0c:a9c7:9::/48 уже знакомой нам AS41740. В анонсах появились также в конце 2020. Поддерживается только CHAOS TXT id.version, NSID - нет. Но так как это рекурсивные серверы то можно воспользоваться сервисом предоставляемым PowerDNS, чтобы определить с какого реального адреса был отправлен запрос. Это даёт нам технически более строгий способ, так как мы выявляем адреса непосредственно участвующие в запросах со стороны НСДИ, а не идентификаторы, которые можно менять без каких-либо последствий. Опять смотрим на RIPE Atlas (30376488, 30376489, 30376490, 30376491, 30376492, 30376493, 30376494, 30376495).

Отметим ещё один момент.AAAA запросы используют IPv6 в качестве адреса источника, даже если обращения было сделано на клиентский публичный IPv4 адрес сервера. Для A запросов на IPv6 адрес это тоже верно. В таблице приведены уже преобразованные к доменным именам адреса, там где они были в PTR, каждый из них имеет и A и AAAA запись. Всего получилось 17 уникальных адресов доменных имён у каждого в наличии IPv4 и IPv6. Для двух адресов видимо забыли завести записи в обратную зону, хотя в прямой они есть (я их привёл в скобках).

193.232.139.82(res2-rnd-lb.ix.ru), 193.232.231.82(res2-ekt-lb.ix.ru), res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-smr-lb.ix.ru, res1-spb-lb.ix.ru, res1-vlv-lb.ix.ru, res2-ekt-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-smr-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

Для примера, надеюсь остальное многие посмотрят сами, сошлюсь на RIPE DB для сети 193.232.139.0/24, запись о которой и маршруты появились в марте этого года, когда уже фактически провайдеры обязаны были использовать НСДИ в своей работе, что во многом говорит что мы находимся в моменте внедрения и обкатки системы, пусть и на хорошей базе. Не знаю какие планы в дальнейшем, но явно в некоторых точках страны видно провалы по задержкам ответов, другими словами есть много что ещё делать.

Для этих серверов уже действует ограничение на выдачу ресурсов присутствующих в списке запрещённых - NXDOMAIN в ответ.

На этом - всё. Как я уже сказал в самом начале, цель этой статьи начать техническое обсуждение построенной системы. Можно свободно использовать те измерения которые я реализовал в RIPE Atlas и ссылки на которые есть в статье, они останутся настолько долго, насколько не потеряют актуальность. Совсем незатронутым остался вопрос DNSSEC, также как и возможные пересечения с существующей системой поддержки национальных TLD. Можно порассуждать про обратные зоны в ARPA., которые не менее важны чем прямые, но они не реализованы в НСДИ, в отличие от прямой корневой зоны. Вопрос устойчивости и работы под нагрузкой, вопрос безопасности... Другими словами больше осталось за кадром, чем в статье - много интересной работы и вопросов, надеюсь, что кого-то я этим заинтересовал.

Мне пришлось пересечь экватор на велосипеде, чтобы стать сетевым инженером

Все начиналось в небольшом сибирском городке, где крутой чувак CCIE по всем канонам построил городскую сеть для интернет-провайдинга. Каким-то чудом меня взяли на работу в эту компанию. Помню как я сидел в кабинете, собеседовался с этим экспертом и пялился на черную табличку за его спиной. Спустя год я записался в Cisco Networking Academy, созданную им же и прошел курс R&S. Это было очень сложно, очень непонятно. Я с трудом продержался до конца 4-х месячного обучения и еле-еле сдал внутренний экзамен. Все было на английском, я тогда и двух слов связать не мог.

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

Цена вопроса была 325 долларов, плюс перелет до Москвы и обратно со всеми сопутствующими расходами. Я решил, что должен сделать это. Именно должен, а не хочу или попробую. Должен и точка.

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

Первое, за что я взялся - это NetAcad курс, к которому у меня остался доступ со времен обучения в сетевой академии. Он был очень большим, и очень бесполезным. Я корпел над ним на работе и после работы, но казалось, что гуляю по лабиринту. Нитью стала книга Тодда Ламмле (Todd Lammle). Спасибо Тодд! Она покрыла, наверное, 60 процентов всего, что нужно было знать для CCNA.

В апреле я полетел в Москву и в "Ланите" успешно сдал экзамен, и уже через три недели получил предложение переехать в Санкт-Петербург.

В Санкт-Петербурге все было более или менее благополучно. Первый год я занимался динамической маршрутизацией на Cisco-Mikrotik, а на второй эту компанию поглотил тот же федеральный оператор. Снова, да, тот же самый! Задачи немного изменились, я стал частью команды, занятой миграцией сервисов с ядра старой компании на ядро новой компании. Новое ядро работало полностью на Huawei.

В феврале Cisco изменил свою программу сертификации, лишив источников для подготовки: старые книги больше не годились, а новые еще написаны не были. Вместо этого Сiscopress предложил официальный гайд. Я нашел pdf версию в интернете и начал готовиться с CCNP ENCOR 350-401, подключив к нему старые книги по CCNP от того же Todd Lammle и Chris Bryant. Позже к ним присоединился David Bomble c бесплатным курсом на YouTube, один индус на Udemy за 20 долларов, ребята с ITproTV за 40 долларов в месяц и Boson практический тест за 99 долларов. Я готовился полгода и в феврале этого года завалил экзамен, набрав только 730 баллов.

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

На данный момент я толком не знаю, что такое HCIA. Я скачал официальный bluprint с сайта Talent Huawei, в котором сказано, что для успешной сдачи нужно набрать 600 очков из 1000. При этом экзамен длится 90 минут и включает 60 вопросов. Не очень высокая планка, правда? Для сравнения CCNA требует 830 и 1000 и он включает более 100 вопросов. Длительность его тоже 90 минут, но для не носителей английского или японского языков дается дополнительных 30 минут. Стоимость HCIA - 200 долларов. CCNA на 100 дороже.

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

Интересно, что IPv6 занимает лидирующее место по количеству вопросов, третье - LAN технологии (L2, видимо), ну а второе - Routing (L3). Что ж, значит, Huawei всерьез видит своих будущих инженеров мастерами по IPv6!

Blueprint рекомендует использовать для подготовки курс V2.5. Он доступен на https://ilearningx.huawei.com.

Я зашел на этот курс и оказалось, что это не текстовый курс, а видео. При этом читают его Xiaofeng Tu, Dong Wang и Lican Liu. На хорошем английском между прочим! Но я не фанат видеокурсов. А те, которыми я пользовался для CCNP, были по платной подписке и на недостижимо высоком уровне исполнения, и с native спикерами, которые не повторяют слово ok после каждого сказанного предложения. Вы понимаете о чем я? Но курс хорошо структурирован и дает взгляд Huawei на сетевые технологии, что тоже нужно понимать. Тем не менее я не стал использовать его как основной источник информации, а только как прикладной. Для основы я выбрал уже упомянутых Тодда Ламмле, Криса Брайанта, видео-материалы из моих платных подписок, таких как cbtnuggets и ITptoTV.

После того как я прочитал материалы по первой теме, я подумал, что мог бы структурировать их в удобный для чтения формат и выразить в виде главы для самопоготовки к HCIA, снабженной также всей информацией из официального курса Huawei. Так получился первый эпизод. Вы можете взглянуть на него на форуме Huawei, пройдя по этой ссылке: Индиана HCIA. Он может быть интересен тем, кто хочет получить начальные знания о сетях или собирается сдавать экзамен.

По этой ссылке вы также найдете два других эпизода. Новые эпизоды будут выходить каждый вторник.