Решение проблемы пересечения IP-адресов: Automatic Return Routing

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

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

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

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

Сегодня мы представляем функцию Автоматической Обратной Маршрутизации (ARR) в режиме Закрытой Бета-версии. ARR — это опциональный инструмент для клиентов Cloudflare One, который даёт гибкость маршрутизировать трафик обратно к точке его происхождения, не требуя записи IP-маршрута в таблице маршрутизации. Эта возможность позволяет сосуществовать перекрывающимся сетям без единой строки конфигурации Преобразования Сетевых Адресов (NAT) или сложной настройки Виртуальной Маршрутизации и Трансляции (VRF).

В корпоративных сетях перекрытие IP-адресов — это данность. Мы видим это в трёх распространённых сценариях, которые традиционно создают рутину для администраторов:

• Слияния и поглощения: Две компании объединяются, и обе используют подсеть 10.0.1.0/24 для своих основных сервисов.

• Экстранеты: Партнёры, поставщики или клиенты безопасно подключаются к вашей сети, используя свои собственные внутренние IP-схемы, что приводит к неизбежным конфликтам.

• Типовые архитектуры: Поставщики SaaS или розничные сети используют одинаковое IP-пространство для каждого филиала, чтобы упростить развёртывание и эксплуатацию.

Проблема возникает, когда эти сайты пытаются связаться с Интернетом или центром обработки данных через Cloudflare. Если два разных сайта отправляют трафик с одного и того же исходного IP, ответный пакет упирается в архитектурную стену. Администратор должен принять решение о маршрутизации трафика на основе неоднозначного адреса назначения. Если администратор добавит оба маршрута в таблицу маршрутизации, выбор пути станет недетерминированным: правильный путь или неправильный. С точки зрения стандартной таблицы маршрутизации нет способа различить два идентичных пути.

^{На этой диаграмме показаны два филиала (Сайт A и Сайт B), оба использующие подсеть 10.0.1.0/24. Они отправляют пакеты в Cloudflare. Ответный пакет из Интернета достигает граничного сервера Cloudflare, и этот обратный трафик иногда отправляется не на тот сайт, потому что в таблице маршрутизации есть два идентичных варианта исходящего пути.}

Существует множество способов разрешить эту неоднозначность, и мы стремимся решить их самым простым для управления нашими клиентами способом. Традиционные «отраслевые стандартные» решения функциональны, но они вносят значительные административные накладные расходы и сложность, от которых мы стремимся избавиться:

1. Виртуальная Маршрутизация и Трансляция (VRF): Это предполагает создание «виртуальных» таблиц маршрутизации для изоляции трафика. Хотя эффективно для разделения, это добавляет административной нагрузки. Управление коммуникацией между VRF (утечка маршрутов) — хрупкий и сложный процесс в масштабе.

2. Преобразование Сетевых Адресов (NAT): Вы можете применять NAT к каждой перекрывающейся подсети, преобразуя её из неуправляемого IP-пространства в управляемый диапазон, уникальный в вашей сети. Этот подход хорошо работает, но сопоставление создаёт административную рутину для каждого нового сайта или партнёра.

Как правило, вариант использования, о котором мы слышим от клиентов, — это необходимость перекрывающейся сети получить доступ к Интернету или частному центру обработки данных. Как нам решить эту проблему без административных накладных расходов?

Мы разработали ARR как решение этой проблемы, не требующее вмешательства («zero-touch»). ARR переносит интеллект из таблицы маршрутизации в отслеживание с сохранением состояния.

Так что же такое отслеживание с сохранением состояния?

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

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

Вместо вопроса к сети: «Где находится этот IP?» ARR спрашивает: «Откуда начался этот конкретный разговор?»

Логика работы:

1. Входящий трафик: Пакет прибывает на граничный сервер Cloudflare от сайта через определённое соединение, т.е. через IPsec туннель, GRE туннель или прямое сетевое соединение.

2. Сопоставление потока: Виртуальная сеть Cloudflare сначала проверяет (путём анализа заголовков), соответствует ли этот пакет существующему потоку.

   1. Проксирование: Если пакет соответствует — отлично! Все решения относительно этого трафика уже приняты и сохранены в нашей памяти. Все, что нам нужно сделать, — это передать этот пакет по уже установленным путям.

   2. Настройка потока: Если он не соответствует существующему потоку, мы решаем, через какие компоненты стека Cloudflare One его пропустить (например, Шлюз, DLP, Фаервол), а также определяем его конечный пункт назначения. Мы сохраняем всё это состояние в памяти. С ARR именно в этот момент мы записываем, какой туннель инициировал поток.

3. Симметричный возврат: Когда ответный трафик прибывает от адресата, Виртуальная сеть Cloudflare использует своё существующее состояние в памяти для проксирования трафика. Что важно, она делает это без необходимости проверять IP-адрес назначения трафика, который вполне может быть повторно использован на разных сайтах. Это полностью исключает необходимость обращения к таблице маршрутизации. Мы видим исходный туннель в состоянии потока и доставляем пакет прямо обратно в него.

^{Пример перекрывающихся исходных IP-адресов, отслеживаемых состоянием потока в памяти, с пометкой о точке входа для информирования решения об обратной маршрутизации.}

Запоминая исходный туннель для каждого потока, ARR обеспечивает маршрутизацию без вмешательства. Если трафик вашего сайта предназначен только для связи клиентов с Интернетом, нет необходимости настраивать обратные маршруты вообще, что снижает трудозатраты при развёртывании новых филиалов или организации «Сетей в кофейнях».

Чтобы реализовать ARR в масштабах Cloudflare, мы подключились к другой инициативе, над которой работаем: Единая Маршрутизация.

Исторически Cloudflare Zero Trust (пользователи/прокси) и Cloudflare WAN (сетевой уровень/сайты) существовали на разных уровнях системы. Cloudflare WAN полагался на примитивы ядра (сетевые пространства имён Linux, маршруты, eBPF и т.д.). Zero Trust работал в пользовательском пространстве, где прокси могли выполнять глубокий анализ и обеспечение безопасности на уровне приложений. Этот подход с «раздвоением личности» часто требовал сложной логики для перемещения трафика между компонентными сервисами, и часть этой сложности превратилась в ограничения продукта, которые могли заметить клиенты.

С нашим новым режимом Unified Routing мы перенесли первоначальное решение о маршрутизации из плоскости данных сетевого уровня в нашу существующую логику маршрутизации пользовательского пространства Zero Trust — то же самое защищенное программное обеспечение, которое используется клиентами Cloudflare One и Cloudflare Tunnel в нашем решении Zero Trust. Это изменение имеет много преимуществ для того, как мы позволяем клиентам использовать свои частные сети с продуктами по всей платформе Cloudflare, поскольку оно устраняет давние проблемы совместимости между Cloudflare WAN и Zero Trust. Unified Routing означает, что вы можете использовать Cloudflare Mesh, Cloudflare Tunnel и точки входа IPsec/GRE вместе в одной учетной записи без единого конфликта.

В сентябре 2025 года мы развернули режим Unified Routing внутри компании для всех сотрудников и сайтов Cloudflare. Мы сразу же увидели улучшение производительности в 3-5 раз для клиентов Cloudflare One, как видно на графике выше.

При проектировании ARR мы знали, что нам необходимо отказаться от маршрутизации на основе ядра и строить на основе нашей новой структуры Unified Routing.

Когда Unified Routing включен, весь трафик Cloudflare WAN проходит через Apollo, наш хаб Zero Trust. В отличие от стандартной таблицы маршрутизации ядра Linux, наша плоскость данных пользовательского пространства полностью программируема. Мы можем прикреплять метаданные, такие как исходный идентификатор туннеля, непосредственно к записи потока в Apollo.

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

ARR легко включить для каждого отдельного туннеля или соединения:

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

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

На сегодняшний день ARR находится в закрытой бета-версии и поддерживает доступ в Интернет через наш Secure Web Gateway для перекрывающихся IP-адресов. Мы уже работаем над расширением этой поддержки для доступа к частным дата-центрам, добавляем отказоустойчивость в середине потока (привязку потока к основной точке входа и плавное определение момента переключения потока на резервную точку входа), а также продолжаем инвестировать в архитектурные возможности, необходимые для того, чтобы проблема перекрытия IP-адресов не затрагивала даже самые сложные глобальные развертывания.