نحوهٔ اتصال vpc service به شبکه‌های خصوصی از هر نقطهٔ جهان

vpc service چیست و چگونه کار می‌کند؟

کلیدواژهٔ اصلی در این مقاله vpc service است که به اتصال بین Workers VPC Services و شبکه‌های خصوصی منطقه‌ای اشاره دارد.

How Workers VPC Services connects to your regional private networks from anywhere in the world — 2025-11-05 — Thomas Gauvin, Matt Alonso, Eric Falcão 😊

در آوریل امسال، چشم‌اندازمان برای یک Virtual Private Cloud سراسری روی Cloudflare را مطرح کردیم؛ هدف این بود که برنامه‌هایتان را از محدودیت‌های منطقه‌ای ابرها و شبکه‌های on-premise آزاد کنیم و امکان ساخت برنامه‌های واقعاً cross-cloud را فراهم سازیم.

امروز اولین گام ملموس این ابتکار را معرفی می‌کنیم: Workers VPC — بخش اول از آن، VPC Services است. VPC Services این امکان را به شما می‌دهد که از هر نقطه دنیا، از طریق Cloudflare Tunnels و از داخل Workers، به APIها، کانتینرها، VMs، serverless functions، دیتابیس‌ها و سایر سرویس‌های داخل شبکه‌های خصوصی منطقه‌ای خود متصل شوید. 🚀

پس از راه‌اندازی یک Tunnel در شبکه‌ای که خواهان دسترسی هستید، می‌توانید هر سرویسی را که می‌خواهید به Workers در دسترس قرار گیرد با تنظیم hostname یا آدرس IP ثبت کنید. سپس می‌توانید VPC Service را مثل هر binding دیگر در Workers فراخوانی کنید — شبکه Cloudflare به‌طور خودکار ترافیک را به VPC Service هدایت می‌کند، صرف‌نظر از محلی که Worker اجرا می‌شود:

export default {
  async fetch(request, env, ctx) {
    // Perform application logic in Workers here	

    // Call an external API running in a ECS in AWS when needed using the binding
    const response = await env.AWS_VPC_ECS_API.fetch("http://internal-host.com");

    // Additional application logic in Workers
    return new Response();
  },
};

Workers VPC در حال حاضر برای همه کاربران Workers در دسترس است و در دوره beta بدون هزینه اضافی ارائه می‌شود، همراه با Cloudflare Tunnels. حتماً آن را تست کنید و در ادامه توضیح داده‌ایم که زیرساخت چگونه کار می‌کند.

Connecting the networks you trust, securely 🔐

برنامه‌های شما معمولاً در چند شبکه مختلف پراکنده‌اند—چه on-premise و چه در ابرهای عمومی. اما اتصال امن Workers به APIها و دیتابیس‌هایی که پشت شبکه‌های خصوصی قرار دارند همیشه چالش‌برانگیز بوده است. VPCهای سنتی گرچه ایزولاسیون و امنیت فراهم می‌کنند، اما اغلب باعث قفل شدن شما در همان ابر و پیچیدگی‌های زیاد برای برقراری ارتباط میان‌ابری می‌شوند.

بخشی از این قفل‌شدگی ناشی از پیچیدگی ذاتی ساخت سرویس‌های توزیع‌شده و امن است: VPC peering، پیکربندی routing tables، security groups و network ACLها را می‌طلبد که معمولاً به جلسات طولانی و دخالت چند تیم منجر می‌شود. هر ارائه‌دهنده ابری هم راهکار «Private Link» خودش را دارد که به نوعی انتخاب شما را محدودتر می‌کند.

با Workers VPC این جریان را خیلی ساده کرده‌ایم: شما یک Cloudflare Tunnel را یک‌بار راه‌اندازی می‌کنید و با مجوزهای لازم به شبکه خصوصی خود متصل می‌شوید. بعد VPC Services را با مشخصات tunnel و hostname یا IP و پورت سرویس دلخواه پیکربندی می‌کنید. هر درخواستی که به آن 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 معرفی می‌شود، از همان مدل binding در Workers برای امنیت و مدیریت دسترسی استفاده می‌شود. نمونه‌ای از پیکربندی binding برای یک پروژه Worker به شکل زیر است:

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

مانند دیگر bindings، هنگام deploy کردن پروژه Worker، مجوزهای دسترسی بررسی می‌شود تا اطمینان حاصل شود Worker بتواند به آن VPC Service خاص دسترسی داشته باشد. نکته مهم: به جای باز کردن کل شبکه برای Worker، فقط همان VPC Service مشخص شده در دسترس خواهد بود. این رویکرد کنترل دسترسی واضح‌تر و شفاف‌تری نسبت به network ACLهای سنتی فراهم می‌کند.

طراحی bindingها مزایای امنیتی ذاتی دارد: مدیریت ساده‌تر، امنیت پیش‌فرض و مقاوم کردن Workers در برابر حملات SSRF. چون Workers اسکریپت‌هایی هستند که روی شبکه جهانی Cloudflare اجرا می‌شوند و نه ماشین‌های سنتی با IPهای ثابت در یک شبکه، bindings‌ها راه امنی برای دسترسی به منابع داخل اکانت Cloudflare شما فراهم می‌کنند—همین مدل برای Workers VPC Services نیز اعمال می‌شود.

A peek under the hood 🛠️

حال بیایید نگاهی فنی‌تر به جریان یک درخواست HTTP از داخل Worker به VPC Service بیندازیم. فرض کنید Worker فراخوانی .fetch() روی binding مربوطه را انجام می‌دهد — این نقطه شروع (Step 1) است. runtime از Cap’n Proto RPC برای ارسال درخواست HTTP اصلی همراه با context استفاده می‌کند، همانطور که در دیگر bindings انجام می‌شود.

Binding Worker سیستم VPC Service این درخواست و metadata (از جمله Service ID) را دریافت می‌کند و آن را از طریق یک HTTP CONNECT به سرویس Iris پروکسی می‌کند؛ این الگو به ما اجازه می‌دهد تا منطق اتصال را در لایه edge و در کد Worker مدیریت کنیم تا runtime ساده بماند (Step 2).

Iris سرویس اصلی برای Workers VPC است؛ مسئولیت Iris قبول درخواست‌ها برای یک VPC Service و هدایت آن‌ها به شبکه‌ای است که سرویس در آن قرار دارد. Iris از طریق یک لایه میانی به نام Apollo (جزئی از Cloudflare One) متصل می‌شود؛ Apollo یک API متحد برای انتزاع پیچیدگی اتصال امن به شبکه‌ها و tunnelهاست.

برای کار با Apollo، Iris دو کار اصلی انجام می‌دهد: اولاً، Iris از metadata، VPC Service ID را استخراج و پیکربندی تونل مربوطه را از configuration store می‌خواند (شامل tunnel ID و نوع آن) — این اطلاعات برای ارسال درخواست‌ها به تونل صحیح لازم است (Step 3). ثانیاً، Iris دیتاگرام‌های UDP حاوی پرسش‌های DNS برای رکوردهای A و AAAA نام hostname سرویس می‌سازد و ابتدا آن‌ها را عبر Apollo ارسال می‌کند. پس از تکمیل حل نام، درخواست اصلی با آدرس IP و پورت حل‌شده ارسال می‌شود (Step 4).

به همین دلیل برای اولین درخواست، مراحل مربوط به DNS و سپس درخواست HTTP اصلی به ترتیب اجرا می‌شوند؛ درخواست‌های بعدی از cache حل نام در Iris بهره می‌برند تا latency کاهش یابد.

در Step 5، Apollo metadata تونل و دیتاگرام‌های DNS یا بسته‌های TCP درخواست HTTP را دریافت می‌کند و براساس tunnel ID مشخص می‌کند کدام دیتاسنتر به تونل متصل است. Apollo سپس پیام‌ها را به Tunnel Connector Service در آن دیتاسنتر هدایت می‌کند.

Tunnel Connector Service وظیفه دارد دسترسی شبکه Cloudflare به Cloudflare Tunnel را فراهم کند و دیتاگرام‌های DNS و در ادامه درخواست اصلی را از طریق پروتکل QUIC به تونل ارسال نماید (Step 6). در نهایت، Cloudflare Tunnel پرسش‌های DNS را به DNS resolver شبکه مقصد می‌فرستد و درخواست HTTP را از IP تونل به IP مقصد و پورت ارسال می‌کند (Step 7). پاسخ مسیر معکوس را طی کرده و در نهایت به Worker بازمی‌گردد.

چه چیزی با VPC Service قابل ساختن است؟ ✨

این قابلیت دسته‌ای از برنامه‌ها را باز می‌کند که قبلاً دشوار یا غیرممکن بودند. Workers که برای کار در edge طراحی شده‌اند، حالا می‌توانند امن و مستقیم به APIهای خصوصی، دیتابیس‌های داخلی و سرویس‌های mission-critical دسترسی داشته باشند؛ یعنی می‌توان کارهای حساس را بدون باز کردن شبکه یا حرکت دادن داده‌ها به اینترنت عمومی انجام داد.

نتیجه‌ی عملی این است که می‌توانید برنامه‌های واقعی cross-cloud بسازید که ترکیبی از Cloudflare Workers و سرویس‌های درون AWS، GCP، Azure یا دیتاسنترهای on-premise شما باشند. در نسخهٔ private beta، مشتریان زیادی این الگو را پذیرفته و اتصال‌های خصوصی بین محیط‌ها را پیاده‌سازی کرده‌اند — این مسیر به‌خصوص برای تیم‌های DevOps / SRE که دنبال کاهش پیچیدگی شبکه و افزایش سرعت deployment هستند، بسیار مفید است.

اگر می‌خواهید، می‌توانم برای شما یک checklist عملی برای راه‌اندازی Cloudflare Tunnel و ساخت یک VPC Service و binding در پروژه Worker آماده کنم تا سریع‌تر آن را در محیط خود تست کنید. 🔧