Peering در Azure یا VPN از VNet به VNet؟ پیش از مسیریابی تصمیم بگیرید

Azure حداقل دو روش برای اتصال دو شبکه مجازی به شما می‌دهد و این‌ها تنظیمات قابل تعویض روی یک شیء نیستند. Peering شبکه‌های VNet را بدون دروازه روی ستون فقرات مایکروسافت به هم وصل می‌کند؛ VPN از VNet به VNet یک رابطه IPsec میان دو دروازه‌ای که خودتان مستقر، اندازه‌بندی و پایش می‌کنید قرار می‌دهد. تصمیم به سه شرط برمی‌گردد و اگر پیش از افزودن یک مسیر نتوانید به هر سه پاسخ دهید، در آستانه ساختن یک راه‌حل دور زدن برای مدلی هستید که هرگز انتخاب نکرده‌اید.

سه شرطی که مدل را تعیین می‌کنند

نخست این است که آیا چیزی در نیازمندی به مرز IPsec نیاز دارد که مالک آن باشید و بتوانید به آن اشاره کنید. دوم این است که آیا فضای نشانی‌ها پاک است و دو VNet فقط باید با هم صحبت کنند. سوم این است که مالک هر مسیر گذرا و صورت‌حساب دروازه کیست. به همین ترتیب پاسخ دهید، زیرا شرط اول می‌تواند Peering را حذف کند هر قدر هم شرط دوم جذاب به نظر برسد.

آنچه هر دو مدل در آن شریک‌اند یک قاعده سخت نشانی‌دهی است: فضاهای نشانی VNet نباید هم‌پوشانی داشته باشند. نه Peering و نه VPN از VNet به VNet روشی پشتیبانی‌شده برای یکتا کردن دو محدوده یکسان نیست، و هم‌پوشانی به طراحی نگاشت یا بازطراحی نیاز دارد، نه به نوع اتصال متفاوت.

شرط 1: آیا به مرز IPsec نیاز دارید که مالک آن باشید؟

Peering ترافیک را روی ستون فقرات خصوصی Azure حمل می‌کند و برای خودِ اتصال peered به دروازه VPN نیاز ندارد. این یک گزاره درباره انتقال است، نه گزاره‌ای درباره رمزنگاری که بتوانید به حسابرس تحویل دهید با این مضمون که «ما IPsec اجرا می‌کنیم». اگر نیازمندی یک تونل پیکربندی‌شده توسط مشتری، یک سیاست مشخص IKE یا مرزی را نام ببرد که روی تجهیزات تحت کنترل شما پایان می‌یابد، Peering آن را برآورده نمی‌کند، هر قدر هم ستون فقرات خصوصی باشد.

VPN از VNet به VNet آن مرز را فراهم می‌کند: دو دروازه، یک رابطه IPsec/IKE، کلیدهای مشترک و تمام سطح عملیاتی که با آن می‌آید. شما وضعیت تونل، ظرفیت دروازه، محدودیت‌های SKU و پایشی را به ارث می‌برید که اثبات می‌کند تونل بالاست. این پاسخ درست است هنگامی که نیازمندی دقیقاً درباره همان مرز است، که در مرور Peering به‌عنوان نوع اتصالی متمایز از Peering توصیف شده است.

در جهت دیگر هم به همان اندازه دقیق باشید. «ما به رمزنگاری میان VNetها نیاز داریم» اغلب با TLS خودِ بار کاری برآورده می‌شود و آن‌گاه دروازه هزینه‌ای است بدون نیازمندی در پشت آن. جمله‌ای را که حسابرس خواهد خواند پیش از انتخاب سازوکار بنویسید.

شرط 2: توپولوژی مستقیم است یا چیزی باید گذر کند؟

Peering گذرا نیست. دو VNet که به یک هاب peered شده‌اند به این وسیله به هم متصل نمی‌شوند، و مسیری که در یک جهت کار می‌کند معمولاً Peeringی است که فقط در یک سمت به Connected رسیده است. هر دو سمت باید وجود داشته باشند و هر دو باید Connected نشان دهند، و این نخستین چیزی است که وقتی ترافیک بی‌صدا ناپدید می‌شود بررسی می‌کنید.

اگر نیازمندی دسترسی به شبکه محلی از طریق هاب است، گذر دروازه طراحی جدایی با نقش‌های مشخص است: هاب مالک دروازه است، Peering شاخه گذر دروازه را مجاز می‌کند و شاخه باید ترافیک ارسال‌شده را مجاز کند. این‌ها ویژگی‌هایی روی Peering هستند، نه پیامدهای خودکار اتصال VNetها:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

جدول مسیر مؤثر پاسخ صادقانه به «آیا مسیر وجود دارد؟» است. نوع گام بعدی را نشان می‌دهد که پلتفرم واقعاً استفاده خواهد کرد، بنابراین Peeringی که پیکربندی شده به نظر می‌رسد ولی متصل نیست، به‌صورت مسیر گم‌شده یا نادرست دیده می‌شود نه به‌صورت یک معما.

شرط 3: مالک مسیر گذرا و صورت‌حساب کیست؟

هر گام اضافه یک مالک دارد. با Peering، یک VNet جدید یعنی یک جفت Peering جدید در هر دو سمت و برای گذر، هابی که به ارسال ترافیک ادامه می‌دهد و جدول مسیری که هم‌چنان به آن اشاره می‌کند. با VPN، یک VNet جدید یعنی دروازه دیگر یا اتصال دیگر روی یک دروازه موجود، با سقف ظرفیت خودش که باید پایش شود.

هزینه همان شکل را دنبال می‌کند ولی نه همان ردیف‌ها را: هزینه‌های Peering اتصال و انتقال داده است، در حالی که VPN ساعت‌های دروازه و هزینه‌های انتقال خودش را اضافه می‌کند. مجموع را برای توپولوژی‌ای که واقعاً یک سال اجرا می‌کنید مقایسه کنید، با احتساب تونل دوم و پایش، نه قیمت یک اتصال امروز. کاری را هم اضافه کنید که هیچ‌کس صورت‌حساب نمی‌کند: کسی باید کلیدها را بچرخاند، وضعیت تونل را بپاید و وقتی دروازه راه‌اندازی مجدد می‌شود ساعت سه بامداد به هشدار پاسخ دهد. معمولاً همین ردیف بحث را تعیین می‌کند، چون تنها ردیفی است که هرگز در پیشنهاد قیمت ظاهر نمی‌شود.

هر کدام را انتخاب کنید، سه جریان را بیازمایید: جریان موردنظر، جریانی ردشده که باید ردشده بماند، و حالت بازیابی وقتی دروازه هاب یا یک Peering پایین است. مدلی که فقط مسیر خوش را توضیح می‌دهد تأیید نشده است، نمایش داده شده است.

انتخاب را با ادعای خودش بسنجید

یک جمله بنویسید که مدل، مرز و مالک را نام ببرد، سپس بررسی کنید که وضعیت مستقرشده با آن مطابقت دارد. برای Peering این یعنی هر دو وضعیت Peering در Connected، مسیر مؤثر گام بعدی Peering را برای پیشوند مقصد نشان دهد و هیچ دروازه‌ای در مسیر نباشد. برای VPN از VNet به VNet یعنی هر دو اتصال Connected، کلیدها و سیاست‌های منطبق روی هر دو دروازه و مسیری که گام بعدی آن دروازه شبکه مجازی است.

اگر بررسی‌ها با جمله اختلاف دارند، نخست جمله را اصلاح کنید. بیشتر سردرگمی در این طراحی‌ها از یک ترکیب می‌آید که هیچ‌کس توصیفش نکرده است: یک Peering برای زیرشبکه بار کاری، یک VPN برای یک سرویس قدیمی و یک جدول مسیر که بی‌صدا یکی را ترجیح می‌دهد.