Подключите Cloudflare Workers к приватным сетям по всему миру

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

Сегодня мы объявляем о первом этапе нашей инициативы Workers VPC: VPC Services. VPC Services позволяют подключаться к вашим API, контейнерам, виртуальным машинам, бессерверным функциям, базам данных и другим службам в региональных частных сетях через Cloudflare Tunnels из ваших Workers, работающих в любой точке мира.

После настройки туннеля в нужной сети вы можете зарегистрировать каждую службу, которую хотите открыть для Workers, настроив её хост или IP-адрес. Затем вы можете получить доступ к VPC Service так же, как и к любой другой привязке службы Workers — сеть Cloudflare автоматически направит запрос к VPC Service через сеть Cloudflare, независимо от того, где выполняется ваш Worker:

export default {
  async fetch(request, env, ctx) {
    // Выполняем логику приложения в Workers здесь	

    // Вызываем внешний API, работающий в ECS в AWS, при необходимости используя привязку
    const response = await env.AWS_VPC_ECS_API.fetch("http://internal-host.com");

    // Дополнительная логика приложения в Workers
    return new Response();
  },
};

Workers VPC теперь доступен всем пользователям Workers без дополнительной платы в течение бета-тестирования, как и Cloudflare Tunnels. Попробуйте прямо сейчас. И читайте дальше, чтобы узнать больше о том, как это работает под капотом.

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

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

Значительная часть привязки к облаку — это inherent сложность создания безопасных распределенных рабочих нагрузок. Пиринг VPC требует настройки таблиц маршрутизации, групп безопасности и списков контроля доступа к сети, поскольку он полагается на сетевое взаимодействие между облаками для обеспечения connectivity. Во многих организациях это означает недели обсуждений и участие множества команд для получения согласований. Эта привязка также отражается в решениях, созданных для управления этой сложностью: каждый облачный провайдер имеет свою собственную версию "Private Link" для облегчения межсетевого соединения, что еще больше ограничивает вас этим облаком и поставщиками, которые с ним интегрированы.

С Workers VPC мы значительно упрощаем это. Вы настраиваете свой Cloudflare Tunnel один раз с необходимыми разрешениями для доступа к вашей частной сети. Затем вы можете настроить Workers VPC Services, указав туннель и имя хоста (или IP-адрес и порт) службы, которую вы хотите открыть для Workers. Любой запрос к этой VPC Service будет использовать эту конфигурацию для маршрутизации к указанной службе внутри сети.

{
  "type": "http",
  "name": "vpc-service-name",
  "http_port": 80,
  "https_port": 443,
  "host": {
    "hostname": "internally-resolvable-hostname.com",
    "resolver_network": {
      "tunnel_id": "0191dce4-9ab4-7fce-b660-8e5dec5172da"
    }
  }
}

Это гарантирует, что после представления в качестве Workers VPC Service служба в вашей частной сети защищена так же, как и другие привязки Cloudflare, с использованием модели привязки Workers. Давайте рассмотрим простой пример привязки VPC Service:

{
  "name": "WORKER-NAME",
  "main": "./src/index.js",
  "vpc_services": [
    {
      "binding": "AWS_VPC2_ECS_API",
      "service_id": "5634563546"
    }
  ]
}

Как и другие привязки Workers, когда вы развертываете проект Worker, который пытается подключиться к VPC Service, разрешения доступа проверяются во время развертывания, чтобы убедиться, что Worker имеет доступ к рассматриваемой службе. И после развертывания Worker может использовать привязку VPC Service для выполнения запросов к этой VPC Service — и только к этой службе внутри сети.

Это важно: вместо раскрытия всей сети Worker'у, только конкретная VPC Service может быть доступна Worker'у. Этот доступ проверяется во время развертывания, чтобы обеспечить более явный и прозрачный контроль доступа к службам, чем это делают традиционные сети и списки контроля доступа.

Это ключевой фактор в дизайне привязок Workers: безопасность по умолчанию с более простым управлением и защита Workers от атак подделки межсайтовых запросов (SSRF). Мы подробно рассматривали модель безопасности привязок ранее, и она становится еще более критичной при доступе к вашим частным сетям.

Примечательно, что модель привязки также важна при рассмотрении того, что такое Workers: это скрипты, работающие в глобальной сети Cloudflare. В отличие от традиционных облаков, они не являются отдельными машинами с IP-адресами и не существуют внутри сетей. Привязки обеспечивают безопасный доступ к другим ресурсам в вашей учетной записи Cloudflare — и то же самое относится к Workers VPC Services.

Итак, как VPC Services и их привязки маршрутизируют сетевые запросы от Workers в любой точке глобальной сети Cloudflare к региональным сетям с использованием туннелей? Давайте рассмотрим жизненный цикл примера HTTP-запроса, сделанного из специального запроса fetch() VPC Service, представленного здесь:

Все начинается в коде Worker, где вызывается функция .fetch() желаемой VPC Service со стандартным JavaScript Request (как представлено в Шаге 1). Среда выполнения Workers будет использовать удаленный вызов процедур Cap'n Proto для отправки исходного HTTP-запроса вместе с дополнительным контекстом, как это делается для многих других привязок Workers.

Binding Worker системы VPC Service получает HTTP-запрос вместе с контекстом привязки, в данном случае с идентификатором службы VPC Service, к которой обращаются. Binding Worker будет проксировать эту информацию в службу Iris в рамках HTTP CONNECT соединения, стандартного паттерна среди привязок Cloudflare для размещения логики подключения к edge-сервисам Cloudflare в коде Worker, а не в самой среде выполнения Workers (Шаг 2).

Iris Service — это основная служба для Workers VPC. Её ответственность — принимать запросы для VPC Service и направлять их в сеть, в которой находится ваша VPC Service. Она делает это путем интеграции с Apollo, внутренней службой Cloudflare One. Apollo предоставляет унифицированный интерфейс, который абстрагирует сложность безопасного подключения к сетям и туннелям, на различных уровнях сетевого взаимодействия.

Для интеграции с Apollo Iris должна выполнить две задачи. Во-первых, Iris проанализирует идентификатор VPC Service из метаданных и получит информацию о туннеле, связанном с ним, из нашего хранилища конфигураций. Это включает идентификатор и тип туннеля из хранилища конфигураций (Шаг 3), что является информацией, необходимой Iris для отправки исходных запросов в правильный туннель.

Во-вторых, Iris создаст UDP-датаграммы, содержащие DNS-запросы для записей A и AAAA имени хоста VPC Service. Эти датаграммы будут отправлены первыми через Apollo. После завершения разрешения DNS исходный запрос отправляется вместе с разрешенным IP-адресом и портом (Шаг 4). Это означает, что шаги с 4 по 7 происходят последовательно дважды для первого запроса: один раз для разрешения DNS и второй раз для исходного HTTP-запроса. Последующие запросы используют преимущества кэширования информации о разрешении DNS в Iris, минимизируя задержку запроса.

На Шаге 5 Apollo получает метаданные Cloudflare Tunnel, к которому нужно получить доступ, вместе с UDP-датаграммами разрешения DNS или TCP-пакетами HTTP-запроса. Используя идентификатор туннеля, он определяет, какой дата-центр подключен к Cloudflare Tunnel. Этот дата-центр находится в регионе, близком к Cloudflare Tunnel, и, таким образом, Apollo направит сообщения разрешения DNS и исходный запрос в службу Tunnel Connector Service, работающую в этом дата-центре (Шаг 5).

Служба Tunnel Connector Service отвечает за предоставление доступа к Cloudflare Tunnel остальной части сети Cloudflare. Она передаст вопросы разрешения DNS, а затем исходный запрос в туннель по протоколу QUIC (Шаг 6).

Наконец, Cloudflare Tunnel отправит вопросы разрешения DNS в DNS-резолвер сети, к которой он принадлежит. Затем он отправит исходный HTTP-запрос со своего собственного IP-адреса на IP-адрес и порт назначения (Шаг 7). Результаты запроса затем передаются обратно исходному Worker'у, от дата-центра, ближайшего к туннелю, до исходного дата-центра Cloudflare, выполняющего запрос Worker'а.

Это открывает целый новый пласт приложений, которые вы можете создавать на Cloudflare. В течение многих лет Workers превосходно работали на границе сети, но в основном они оставались "вне" вашей основной инфраструктуры. Они могли обращаться только к публичным конечным точкам, что ограничивало их способность взаимодействовать с наиболее критически важными частями вашего стека — такими как приватный API аккаунтов или внутренняя база данных инвентаря. Теперь, с сервисом VPC, Workers могут безопасно получать доступ к этим приватным API, базам данных и сервисам, кардинально меняя возможное.

Это немедленно позволяет создавать настоящие межоблачные приложения, охватывающие Cloudflare Workers и любые другие облака, такие как AWS, GCP или Azure. Мы видели, как многие клиенты приняли эту модель в ходе нашего закрытого бета-тестирования, устанавливая приватное соединение между своими внешними облаками и Cloudflare Workers. Мы даже сделали это сами, подключив наши Workers к сервисам Kubernetes в наших основных дата-центрах для работы API плоскости управления многих наших сервисов. Теперь вы можете создавать такие же мощные распределенные архитектуры, используя Workers для глобального масштабирования, сохраняя при этом stateful бэкенды в сети, которой вы уже доверяете.

Это также означает, что вы можете подключаться к своим локальным сетям из Workers, что позволяет модернизировать устаревшие приложения с помощью производительности и бесконечного масштабирования Workers. Еще более интересными являются некоторые новые варианты использования для рабочих процессов разработчиков. Мы видели, как разработчики запускают cloudflared на своих ноутбуках, чтобы подключить развернутый Worker обратно к своей локальной машине для отладки в реальном времени. Вся гибкость Cloudflare Tunnels теперь стала программируемым примитивом, доступным напрямую из вашего Worker, открывая мир возможностей.

VPC Services — это первый этап в рамках более крупной инициативы Workers VPC, но мы только начинаем. Наша цель — сделать подключение к любому сервису и любой сети в любой точке мира неотъемлемой частью опыта работы с Workers. Вот над чем мы работаем дальше:

Более глубокая сетевая интеграция. Начать с Cloudflare Tunnels было осознанным выбором. Это высокодоступное, гибкое и знакомое решение, что делает его идеальным фундаментом для построения. Чтобы предоставить больше вариантов для корпоративных сетей, мы добавим поддержку стандартных IPsec-туннелей, Cloudflare Network Interconnect (CNI) и AWS Transit Gateway, давая вам и вашим командам больше выбора и потенциальных оптимизаций. Что важно, эти соединения также станут по-настоящему двунаправленными, позволяя вашим приватным сервисам инициировать соединения обратно к ресурсам Cloudflare, например, для отправки событий в Queues или получения данных из R2.

Расширенная поддержка протоколов и сервисов. Следующим шагом после HTTP станет обеспечение доступа к TCP-сервисам. Это сначала будет достигнуто за счет интеграции с Hyperdrive. Мы развиваем предыдущую поддержку Hyperdrive для приватных баз данных, упрощая ее с помощью конфигурации VPC Services, избегая необходимости добавлять Cloudflare Access и управлять токенами безопасности. Это создает более нативный опыт, дополненный мощным пулом соединений Hyperdrive. После этого мы добавим более широкую поддержку сырых TCP-соединений, открывая прямую связь с такими сервисами, как кэши Redis и очереди сообщений, из Workers 'connect()'.

Совместимость с экосистемой. Мы хотим, чтобы подключение к приватному сервису ощущалось так же естественно, как и к публичному. Для этого мы будем предоставлять уникальное автоматически генерируемое имя хоста для каждого Workers VPC Service, подобно строкам подключения Hyperdrive. Это упростит использование Workers VPC с существующими библиотеками и библиотеками ORM, которым может требоваться имя хоста (например, в глобальном вызове 'fetch()' или строке подключения MongoDB). Имя хоста Workers VPC Service будет автоматически разрешаться и маршрутизироваться к правильному VPC Service, так же как это делает команда 'fetch()'.

Мы рады выпустить Workers VPC Services в открытый бета-тест сегодня. Мы потратили месяцы на создание и тестирование нашего первого этапа для доступа Workers к приватным сетям. И мы дополнительно улучшили его на основе отзывов как внутренних команд, так и клиентов в ходе закрытого бета-тестирования.

Теперь мы с нетерпением ждем возможности позволить всем создавать межоблачные приложения на Workers с помощью Workers VPC, доступных бесплатно в течение открытого бета-тестирования. С Workers VPC вы можете приблизить свои приложения в приватных сетях к региону Earth, ближе к вашим пользователям и доступными для Workers по всему миру.