На протяжении большей части истории Интернета публичная и частная инфраструктура существовали как отдельные миры. Публичные приложения работали за сетями доставки контента (CDN) и веб-брандмауэрами (WAF). Частные приложения работали за виртуальными частными сетями (VPN), брандмауэрами и отдельными операционными стеками. Мы считаем, что это различие устаревает.
Многие приложения, которые важны для организаций, не являются публичными веб-сайтами. Это внутренние API, бэкенды AI-агентов, MCP-серверы, операционные инструменты и сервисы, которые никогда не предназначались для доступа из публичного Интернета. Тем не менее эти приложения по-прежнему нуждаются в современных сервисах безопасности, производительности и программируемости. Безопасность должна быть свойством трафика, достигающего приложения, а не случайностью того, где приложение расположено.
До сих пор применение этих сервисов к частным приложениям часто требовало публичных IP-адресов, исключений в брандмауэре, соединительного программного обеспечения или сложной сетевой инфраструктуры. В результате многие частные приложения оставались без таких возможностей, как WAF, управление ботами, ограничение скорости, кэширование, ускорение трафика, перезапись и Workers, хотя им требовались те же меры защиты и контроля, что и публичным приложениям.
Сегодня мы запускаем Application Services for Private Origins в закрытом бета-тестировании для подходящих корпоративных клиентов. Клиенты теперь могут безопасно направлять трафик к частным источникам, не раскрывая эти источники для публичного Интернета. Это позволяет сервисам безопасности, производительности и программируемости Cloudflare защищать приложения, работающие в частных сетях, так же, как они делают это для приложений в публичном Интернете.
Правила WAF, управление ботами, ограничение скорости, кэширование, перезапись и Workers теперь могут располагаться перед частными источниками без необходимости в публичном IP-адресе, правилах входящего брандмауэра или запуске cloudflared на источнике.
Четыре варианта использования, один уровень приложений
Эта модель маршрутизации основана на шаблонах подключения, которые Cloudflare уже поддерживает сегодня через Cloudflare Tunnel, Cloudflare One Client и интеграции с частными сетями. В течение многих лет Cloudflare Tunnel позволял клиентам направлять публичный трафик к частным приложениям через cloudflared. Новая возможность расширяет ту же модель на существующие Cloudflare WAN или Cloudflare Mesh без необходимости запуска соединительного ПО на источнике.
Большая часть этого подключения координируется через уровень маршрутизации частной сети Cloudflare, который определяет, как трафик достигает частных пунктов назначения через Cloudflare Tunnels, Virtual Networks, Cloudflare Mesh и другие модели подключения. Клиенты могут определять свое поведение маршрутизации через API и панель управления вместо управления отдельными сетевыми стеками для каждого продукта.
Мы расширили уровень частной сети Cloudflare непосредственно в стек прикладных сервисов, позволяя инфраструктуре прокси-серверов безопасности и производительности рассматривать частные IP-адреса как допустимые цели источников для публичных имен хостов. В результате те же частные IP-адреса, ранее доступные только через Cloudflare Tunnel, Cloudflare One, Cloudflare Mesh или Cloudflare WAN, теперь могут находиться за сервисами безопасности, производительности и программируемости Cloudflare так же, как это уже делают публичные источники.
Это также создает более унифицированную модель для продуктов Cloudflare. Привязки Workers VPC и маршрутизация частных источников Spectrum теперь полагаются на один и тот же базовый уровень частного подключения, предоставляя клиентам единый источник достоверной информации для контроля того, как частный трафик перемещается в их среде Cloudflare.
Трафик приложений теперь делится на четыре комбинации в зависимости от того, откуда приходят пользователи и где находятся приложения:
Комбинация в правом верхнем углу — это то, что Cloudflare всегда делал: пользователи в Интернете обращаются к приложениям в Интернете, а Cloudflare находится посередине. Нижняя правая — это Cloudflare One: пользователи в частных сетях безопасно обращаются к публичным сервисам.
Верхняя левая — это то, что мы поставляем сегодня. Нижняя левая, частное-к-частному, — это то, к чему мы стремимся в следующую очередь.
Что поставляется сегодня
До сих пор направление публичного трафика к частному источнику часто означало поиск компромиссов. Клиенты могли использовать Cloudflare Tunnel, который запускает cloudflared, наше соединительное ПО, на источнике или рядом с ним, или Cloudflare Load Balancing с пулами частных источников для проверок работоспособности и отказоустойчивости. Во многих случаях организации также поддерживали параллельную инфраструктуру, такую как публичные балансировщики нагрузки, обратные прокси, mTLS между переходами и завершение TLS на нескольких уровнях. В результате применение полного стека Application Services от Cloudflare к частным приложениям часто требовало дополнительной сложности, операционных издержек или отдельных продуктов. Application Services for Private Origins устраняет эти компромиссы.
Чего не хватало, так это пути для клиентов, которые уже используют Cloudflare WAN (IPsec-туннели, GRE-туннели, CNI-соединения) или Cloudflare Mesh. Они уже построили частное подключение к Cloudflare для межсайтовых сетей и Zero Trust и хотели использовать то же самое подключение для публичного трафика к частным источникам. Это и обеспечивает Application Services for Private Origins.
Когда вы включаете Использовать маршрутизацию частной сети для проксируемой A или AAAA записи, WAF Cloudflare, ограничение скорости, кэширование, управление ботами и правила трансформации работают как обычно в сети Cloudflare. Единственное отличие — последний переход: вместо достижения источника через публичный Интернет, Cloudflare направляет соединение через ваше существующее частное сетевое подключение.
Переключатель включается автоматически для частных IPv4 диапазонов RFC 1918 (10.x.x.x, 172.16.x.x–172.31.x.x и 192.168.x.x), диапазонов CGNAT RFC 6598 (100.64.x.x–100.127.x.x) и уникальных локальных IPv6 адресов RFC 4193 (FC00::/7), поскольку эти адреса доступны только в частных сетях. Для публичных IP-адресов, которые доступны только через вашу частную сеть или туннель, вы можете включить переключатель вручную.
Как выглядит API
Для клиентов, автоматизирующих развертывание через API, частная маршрутизация — это просто дополнительный атрибут в стандартной DNS-записи.
POST /zones/{zone_id}/dns_records
{
"type": "A",
"name": "app.example.com",
"content": "10.0.0.50",
"ttl": 300,
"proxied": true,
"use_private_routing": true
}
За кулисами прокси-платформа Cloudflare определяет, куда отправлять трафик для app.example.com, запрашивая Cloudflare Origin API. Ответ включает метаданные, указывающие, что пункт назначения должен быть достигнут через частный сетевой путь:
{
"zone_name": "example.com",
"ipv4_addresses": ["10.0.0.50"],
"use_private_routing": true
}
Флаг use_private_routing является ключевым сигналом. Когда наш прокси видит его, вместо попытки подключиться напрямую к частному IP-адресу через публичный Интернет, он передает запрос нашему уровню частной сети, который затем направляет соединение через существующее частное сетевое подключение клиента, будь то IPsec, GRE, Cloudflare Tunnel, CNI или Cloudflare Mesh.
За пределами HTTP: Spectrum и Workers VPC
Та же модель маршрутизации теперь распространяется за пределы HTTP-приложений. Источник не обязательно должен быть веб-сервером. Это может быть TCP-база данных, конечная точка UDP-логирования или частный API, который Workers вызывают напрямую. Общая нить в том, что Cloudflare находится между вашим трафиком и вашей частной сетью, применяя один и тот же уровень безопасности, производительности и маршрутизации независимо от протокола или источника запроса.
Spectrum, прокси-сервер Cloudflare уровня 4, теперь может располагаться перед TCP и UDP сервисами, работающими на частных IP-адресах. Вместо создания пула балансировщика нагрузки в качестве посредника, приложения Spectrum могут указывать virtual_network_id непосредственно в конфигурации источника. При создании приложения Spectrum вы можете включить идентификатор виртуальной сети вместе с IP-адресом вашего частного источника:
{
"protocol": "tcp/22",
"dns": {
"type": "CNAME",
"name": "ssh.example.com"
},
"origin_direct": ["tcp://10.0.0.50:22"],
"virtual_network_id": "fab9ac85-491b-44c8-b7ae-dd44d4f4672e"
}
Когда вы создаете или обновляете приложение Spectrum с частным источником и виртуальной сетью, Cloudflare проверяет, соответствует ли IP-адрес маршруту в вашем Cloudflare Tunnel, прежде чем сохранить конфигурацию. Если соответствующего маршрута не существует, API отклоняет запрос, и приложение не создается. После сохранения Spectrum передает подключение вашей виртуальной сети, которая направляет его через соответствующий туннель по тому же пути, который использует HTTP-трафик, когда вы включаете маршрутизацию частной сети для DNS-записи. В этой первоначальной версии частные источники Spectrum поддерживаются через Cloudflare Tunnel. Поддержка дополнительных возможностей подключения к частным сетям последует в будущих версиях.
Это означает, что теперь вы можете поместить Spectrum перед любой службой TCP/UDP, работающей на частном IP. Служба остается частной. Не требуется общедоступный IP, программное обеспечение для подключения или балансировщик нагрузки.
Workers VPC замыкает цикл для кода, работающего на Cloudflare. Привязка указывает среде выполнения Workers направлять трафик по тому же частному пути, что и DNS-записи. Браузеры, мобильные приложения, Workers и AI-агенты достигают ваших частных источников через Cloudflare: DNS-записи для интернет-трафика, привязки для Workers.
Что дальше
Маршрутизация от публичной сети к частной (public-to-private) сегодня находится в закрытой бета-версии, и мы планируем общую доступность (GA) в 4-м квартале 2026 года.
Помимо GA, мы стремимся к организации потоков трафика между частными сетями (private-to-private): пользователи, сервисы и AI-агенты в частных сетях безопасно достигают приложений в других частных сетях, при этом прикладные сервисы Cloudflare находятся посередине.
Мы движемся к модели, где одна и та же инфраструктура Cloudflare может обеспечивать безопасность трафика независимо от того, является ли пользователь или источник публичным.
Конечное состояние — это мир, где сотрудник, использующий Cloudflare One Client для доступа к wiki.company.internal, получает те же защиты WAF, ограничения скорости и управления ботами, что и клиент, обращающийся к публичному API. AI-агент, потребляющий проприетарный внутренний API, проходит через тот же стек безопасности, что и браузер. Трафик между сервисами в облаках и центрах обработки данных получает те же средства контроля, что и интернет-трафик, даже если ни пользователь, ни сервер не находятся в публичном интернете.
Начните сегодня
Маршрутизация к частным источникам сегодня доступна в закрытой бета-версии для подходящих клиентов Enterprise. Обратитесь к вашей команде по работе с учетными записями Cloudflare для запроса доступа. После включения следуйте нашей документации для разработчиков, в которой описан полный процесс настройки. Вам потребуется подключение Cloudflare One (IPsec, GRE, CNI или Cloudflare Mesh) и обратный маршрут для диапазона исходных IP-адресов Cloudflare 100.64.0.0/12 в вашей частной сети.