Почему работающая сеть может стать недоступной после изменения данных реестра?

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

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

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

Сначала выясните, какая запись изменилась

IP-префикс — это блок адресов. Номер автономной системы, или ASN, идентифицирует сеть, которая обменивается маршрутами с другими сетями. BGP — протокол, с помощью которого эти сети объявляют, какие направления им доступны.

Наряду с этим обменом существуют несколько видов записей. Они отвечают на разные вопросы:

• Регистрационные записи: какая организация указана для адресного блока и с кем можно связаться. Документация базы данных RIPE разграничивает регистрацию ресурсов, сведения о маршрутизации и контактные записи, хотя они хранятся в одной базе данных.
• Записи Internet Routing Registry (IRR), реестра маршрутизации интернета: информация, на основе которой операторы могут составлять списки принимаемых маршрутов. Запись описывает предполагаемую маршрутизацию; сама по себе она не анонсирует маршрут.
• Записи Resource Public Key Infrastructure (RPKI), инфраструктуры открытых ключей для ресурсов: к ним относятся подписанные разрешения на объявление маршрутов — ROA, из которых валидаторы формируют данные для проверки исходной сети и допустимой длины префикса.

Устаревший контактный адрес электронной почты не отзывает маршрут BGP напрямую. Отсутствие маршрута в сформированном провайдером фильтре может привести к тому, что провайдер перестанет его принимать. Если называть и то и другое «недействительными данными реестра», теряется важнейшее различие.

Как запись приводит к отклонению маршрута

Рассмотрим провайдера, который строит фильтры для клиентов на основе данных IRR. Возможна следующая последовательность сбоя:

1. Запись маршрута удаляют либо она больше не входит в набор маршрутов клиента.
2. При следующем формировании фильтра провайдер не включает в него этот маршрут.
3. Новый фильтр поступает на маршрутизаторы провайдера, и они отклоняют анонс клиента.
4. Если пригодной альтернативы не остаётся, пользователи, зависящие от этого пути, теряют доступ.

Чтобы эта цепочка сработала, данные должны действительно использоваться при построении данного фильтра. Опубликованная политика NTT DATA по реестру маршрутизации даёт конкретный пример клиентских фильтров на основе IRR и их автоматического обновления. В ней также описаны отклонение маршрутов со статусом RPKI Invalid и исключение конфликтующих записей IRR. Это конкретные операционные механизмы, а не универсальный выключатель в руках регистратора.

Что на самом деле означает статус RPKI Invalid

При проверке источника маршрута анонс сопоставляют с проверенными данными разрешений. RFC 6811 определяет три результата:

• Valid: как минимум одно разрешение, охватывающее маршрут, соответствует исходному ASN и допускает анонсируемую длину префикса.
• Invalid: данные разрешений, охватывающих маршрут, существуют, но ни одно из них не удовлетворяет обоим условиям.
• NotFound: данных разрешений, охватывающих маршрут, нет.

Например, маршрут, анонсируемый сетью A, может получить статус Invalid, если соответствующее ему разрешение исчезнет, а разрешение для сети B, охватывающее этот маршрут, сохранится. Если же не останется ни одного охватывающего разрешения, результатом будет NotFound. Здесь Invalid — результат проверки маршрутизации, а не заключение о праве собственности или легитимности института. Проверка источника также не подтверждает подлинность всего пути, по которому, согласно анонсу, прошёл маршрут.

Следующий шаг определяется политикой, настроенной оператором. RFC 8481 разделяет присвоение статуса проверки и действия на его основе: политику должен настроить оператор. Сеть, настроенная на отклонение маршрутов Invalid, может затем отклонить этот анонс. Изменение реестра и отклонение связаны через этот механизм; это не одно и то же событие.

Почему одни пользователи теряют доступ раньше других

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

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

Найдите нарушенное звено, прежде чем менять что-либо ещё

Полезный вопрос для восстановления должен быть конкретным: какая система перестала принимать какой анонс и почему? Оператор может разобраться в этом вместе с провайдером:

1. Определите анонс. Зафиксируйте затронутый префикс и исходный ASN и проверьте, продолжает ли анонсироваться ожидаемый маршрут.
2. Найдите место отклонения. Сопоставьте установленный у провайдера фильтр и результат проверки с маршрутом. Выясните, какой источник данных и какое обновление привели к этому решению.
3. Сохраните свидетельства. Сохраните соответствующие записи, наблюдения и временные отметки, чтобы можно было отличить ошибочное обновление от несанкционированного анонса.
4. Исправьте и проверьте. Согласуйте точечное исправление записи или конфигурации, убедитесь, что оно дошло до использующих данные систем, и проверьте доступ из сетей, где он пропал.

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

Более глубокая проблема: полезные подтверждения могут превратиться в сосредоточенную власть

Здесь техническая цепочка пересекается с аргументом Лу Хэна. Администратору не нужно пересылать чьи-либо пакеты, чтобы влиять на доступность соответствующей сети. Если другие системы зависят от записей, которые он контролирует, его решения могут возлагать издержки на операторов и клиентов далеко за пределами его офиса.

В заметке 65 «Приоритет работающего кода» Лу Хэн утверждает, что координация должна быть ограничена потребностями работающих сетей. Роль в ведении записей не может сама по себе перерасти в постоянный политический мандат. Наличие подписи у записи отвечает на технический вопрос об утверждении; оно не устанавливает право управлять всеми, кого это утверждение затрагивает.

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

Для непрерывности нужен путь выхода, которым смогут воспользоваться другие сети

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

Заметка 72 прямо формулирует желаемый результат: точные записи, непрерывность работы и реальная возможность уйти от координатора, который перестал справляться со своей задачей. Практическая трудность — создать эту возможность, не утратив общую уникальность и совместимость, благодаря которым независимые сети могут взаимодействовать.

Руководство по экспорту состояния реестра рассматривает ту часть этой работы, которая связана с переносом записей. Это один из компонентов перехода наряду с проверкой, принятием новой системы операторами и тестированием непрерывности работы.

Готовьтесь, пока сервис ещё работает

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

Чтобы установить ответы совместно с другими организациями, нужно время. Если найти их до сбоя, появится пространство для действий; если выяснять их во время аварии, расплачиваться придётся клиентам. Срочная задача — создать практическую независимость, пока непрерывность ещё можно защитить.

Продолжите чтение с заметки 65 «Приоритет работающего кода», чтобы познакомиться с полным аргументом Лу Хэна в пользу координации, основанной на работающих сетях, локальной проверке и добровольном принятии.