Что ИИ-компаниям стоит знать об управлении IP-адресами

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

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

Отсюда вопрос, на который отвечает это руководство: как ИИ-компании сохранить доступность своей сети, если адрес, провайдер или регистратор становится источником риска?

Сначала отделите адресную ёмкость от идентичности

Поначалу IP-адрес может быть просто единицей адресной ёмкости. Временную среду разработки можно перенести на другой адрес почти без последствий. С рабочим API всё иначе, когда клиенты, партнёры, межсетевые экраны, системы мониторинга и документация о соблюдении требований зависят именно от этого адреса.

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

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

Четыре уровня, которые легко перепутать

Команды, работающие с ИИ, смогут принимать более обоснованные решения, если будут различать четыре уровня:

• Ресурс. Префиксы IPv4 и IPv6, а также номера автономных систем обеспечивают сетям глобально уникальные идентификаторы.
• Запись в реестре. Регистратор фиксирует, кто является держателем ресурса или контролирует его, и помогает участникам Интернета избегать противоречащих друг другу притязаний.
• Работающая сеть. Анонсы BGP, маршрутизаторы, вышестоящие провайдеры и приложения определяют, доходит ли трафик до сервиса на самом деле.
• Подтверждение полномочий для безопасности. RPKI и разрешение на анонсирование маршрута — Route Origin Authorization — помогают другим сетям проверить, разрешено ли автономной системе с данным ASN выступать источником анонса префикса.

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

Почему это становится вопросом непрерывности бизнеса

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

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

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

Покупка или аренда адреса не устраняет зависимость

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

Прежде чем рабочая среда начнёт зависеть от префикса, команда должна знать:

• Кто указан как держатель ресурса?
• Какой регистратор ведёт эту запись?
• Какой ASN вправе выступать источником анонса префикса?
• Кто может создавать или изменять ROA?
• Кто контролирует обратный DNS и административный доступ?
• Что произойдёт, если провайдер, брокер или арендодатель исчезнет?
• Что произойдёт по окончании аренды или при недоступности регистратора?

Таким образом, цена за адрес — лишь один из критериев закупки. Для критически важного префикса полезнее оценивать обеспеченную непрерывность в расчёте на адрес.

RPKI должна соответствовать реально работающей сети

Допустим, компания переводит префикс с одного ASN на другой. Конфигурация BGP может быть правильной, но прежний ROA всё ещё разрешает анонсирование только прежнему источнику. Сети, выполняющие проверку источника маршрута — Route Origin Validation, — тогда могут считать новый анонс недействительным.

Эксплуатационное правило простое: изменение маршрутизации и соответствующего подтверждения полномочий должны входить в один процесс изменений. RPKI должна отвечать на узкий технический вопрос, для которого она и создана: какому ASN разрешено выступать источником анонса этого префикса?

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

Технические основы изложены в описании архитектуры RPKI и справочных материалах IANA о номерных ресурсах.

Решение — координация с узкими полномочиями и реальной возможностью выхода

ИИ-компаниям действительно нужна координация. Адреса должны оставаться уникальными. Записи должны быть точными. Безопасность маршрутизации должна поддаваться проверке. Передачи ресурсов и изменения контроля должны допускать аудит.

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

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

Смена вывески на входе не решает структурную проблему, если компания по-прежнему не может уйти. Механизм замены должен стать частью системы до того, как кризис сделает его необходимым. Этот аргумент развит в статьях «Билль о правах в координации уникальности» и «Заблуждение о непрерывности работы регистратора».

Практический учёт для инфраструктурной команды ИИ-компании

Прежде чем масштабировать публичный ИИ-сервис, заведите единый актуальный перечень, который отвечает на следующие вопросы:

• Какие префиксы IPv4 и IPv6 обслуживают рабочую среду?
• Какие ASN используются и какой ASN выступает источником анонса каждого префикса?
• Кто контролирует учётную запись у регистратора, обратный DNS и ключи RPKI?
• Какие ресурсы арендованы, выделены провайдером или находятся в прямом держании компании?
• Какие клиенты и партнёры включили адреса в списки разрешённых?
• Во сколько обойдётся смена адресации для каждого критически важного префикса?
• Каков порядок замены провайдера или регистратора в случае его отказа?

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

Почему начинать нужно до первого сбоя

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

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

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

Вопрос для совета директоров

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

Правильный вопрос — не только «Хватает ли нам IP-адресов?». Нужно также спросить:

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

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

Продолжение основного аргумента

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

О получении ресурсов читайте в статье «Почему существует i.LEASE». Общая мысль проста: сделка может дать компании доступ к ресурсу, но только продуманная система непрерывности способна сделать этот доступ устойчивым.