Azure میں peering یا VNet سے VNet تک VPN؟ روٹنگ سے پہلے فیصلہ کریں

Azure آپ کو دو مجازی نیٹ ورک جوڑنے کے کم از کم دو طریقے دیتا ہے، اور یہ ایک ہی آبجیکٹ پر بدلے جا سکنے والے سیٹنگز نہیں ہیں۔ Peering بغیر گیٹ وے Microsoft کی ریڑھ کی ہڈی پر VNet کو جوڑتا ہے؛ VNet سے VNet تک VPN ان دو گیٹ ویز کے درمیان IPsec تعلق رکھتا ہے جنہیں آپ تعینات کرتے، حجم طے کرتے اور نگرانی کرتے ہیں۔ فیصلہ تین شرائط پر آتا ہے، اور اگر راستہ شامل کرنے سے پہلے آپ تینوں کا جواب نہیں دے سکتے، تو آپ ایسے ماڈل کے لیے متبادل راستہ بنا رہے ہیں جو آپ نے کبھی منتخب نہیں کیا۔

وہ تین شرائط جو ماڈل کا تعین کرتی ہیں

پہلی یہ ہے کہ ضرورت میں کسی چیز کو آپ کی ملکیت کی اور آپ کی نشاندہی کر سکنے والی IPsec حد درکار ہے یا نہیں۔ دوسری یہ ہے کہ پتہ کی جگہیں صاف ہیں یا نہیں اور دونوں VNet کو صرف ایک دوسرے سے بات کرنی ہے یا نہیں۔ تیسری یہ ہے کہ کسی بھی گزرگاہ راستے اور گیٹ وے بل کا مالک کون ہے۔ اسی ترتیب سے جواب دیں، کیونکہ پہلی دوسری کتنی ہی پرکشش لگے، peering کو خارج کر سکتی ہے۔

دونوں ماڈلز میں مشترک چیز سخت پتہ نگاری کا اصول ہے: VNet کی پتہ جگہیں ایک دوسرے پر نہیں آنی چاہئیں۔ نہ peering اور نہ VNet سے VNet تک VPN دو یکساں حدود کو غیر مبہم بنانے کا معاون طریقہ ہے، اور اوورلیپ کے لیے مختلف کنکشن قسم نہیں، میپنگ ڈیزائن یا ازسرنو ڈیزائن درکار ہے۔

شرط 1: کیا آپ کو اپنی ملکیت کی IPsec حد درکار ہے؟

Peering ٹریفک کو Azure کی نجی ریڑھ کی ہڈی پر لے جاتا ہے اور peered کنکشن کے لیے بذات خود VPN گیٹ وے کی ضرورت نہیں۔ یہ نقل و حمل کے بارے میں بیان ہے، ایسا بیان نہیں جو آپ آڈیٹر کو «ہم IPsec چلاتے ہیں» کے طور پر دے سکیں۔ اگر ضرورت گاہک کے ترتیب دیے ہوئے ٹنل، مخصوص IKE پالیسی یا آپ کے زیرِ کنٹرول آلات پر ختم ہونے والی حد کا نام لے، تو ریڑھ کی ہڈی کتنی ہی نجی ہو، peering اسے پورا نہیں کرتا۔

VNet سے VNet تک VPN وہ حد فراہم کرتا ہے: دو گیٹ وے، IPsec/IKE تعلق، مشترکہ چابیاں اور وہ تمام عملی سطح جو اس کے ساتھ آتی ہے۔ آپ ٹنل کی حالت، گیٹ وے کی گنجائش، SKU کی حدیں اور وہ نگرانی ورثے میں پاتے ہیں جو ثابت کرتی ہے کہ ٹنل قائم ہے۔ یہ درست جواب ہے جب ضرورت خاص طور پر اسی حد کے بارے میں ہو، جسے peering کے جائزے میں peering سے الگ کنکشن قسم کے طور پر بیان کیا گیا ہے۔

مخالف سمت میں بھی اتنی ہی احتیاط کریں۔ «ہمیں VNet کے درمیان انکرپشن درکار ہے» اکثر ورک لوڈ کے اپنے TLS سے پورا ہو جاتا ہے، اور پھر گیٹ وے پیچھے ضرورت کے بغیر خرچ ہوتا ہے۔ طریقہ کار منتخب کرنے سے پہلے وہ جملہ لکھیں جو آڈیٹر پڑھے گا۔

شرط 2: کیا ٹوپولوجی براہِ راست ہے، یا کسی چیز کو گزرنا ہے؟

Peering گزرنے والا نہیں ہے۔ ایک حب سے peered دو VNet اس سے ایک دوسرے سے جڑے نہیں ہوتے، اور ایک سمت میں کام کرتا دکھنے والا راستہ عام طور پر وہ 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 کا اگلا ہاپ دکھائے، اور راستے میں کوئی گیٹ وے نہ ہو۔ VNet سے VNet تک VPN کے لیے اس کا مطلب دونوں کنکشن Connected، دونوں گیٹ ویز پر مطابق چابیاں اور پالیسیاں، اور ایسا راستہ جس کا اگلا ہاپ مجازی نیٹ ورک گیٹ وے ہو۔

اگر جانچیں جملے سے متصادم ہوں تو پہلے جملہ درست کریں۔ ان ڈیزائنوں میں بیشتر الجھن ایسے ہائبرڈ سے آتی ہے جسے کسی نے بیان نہیں کیا: ورک لوڈ سب نیٹ کے لیے peering، ایک پرانی سروس کے لیے VPN اور ایسا راستہ جدول جو خاموشی سے ایک کو ترجیح دیتا ہے۔