کیا peering سے منسلک Azure VNet کو اپنا VPN گیٹ وے درکار ہے؟
peering سے منسلک VNet معاون SKU اور peering کی ہر سمت میں ایک ترتیب کے ساتھ hub کے VPN گیٹ وے کا استعمال کر سکتا ہے۔ مؤثر راستے دیکھیں، peering کی حیثیت نہیں۔
ایک نیا spoke VNet ظاہر ہوتا ہے، hub کے پاس پہلے سے ایک کام کرنے والا site-to-site گیٹ وے ہے، اور واضح سوال یہ ہے کہ کیا آپ کو دوسرے گیٹ وے کی ادائیگی کرنی ہوگی۔ عام طور پر نہیں: گیٹ وے ٹرانزٹ spoke کو peering کے ذریعے hub کے گیٹ وے کے استعمال کی اجازت دیتا ہے۔ تین شرطیں طے کرتی ہیں کہ یہ کام کرے گا یا نہیں، اور ان میں سے کوئی بھی peering کی حیثیت کے بیج سے نظر نہیں آتی۔ peering کنیکٹیویٹی اور کسی اور کے گیٹ وے کے استعمال کی اجازت الگ ترتیبات ہیں، اس لیے دو VM جو پہلے ہی ایک دوسرے کو ping کر سکتے ہیں، VPN راستے کے بارے میں کچھ ثابت نہیں کرتے۔
پہلی شرط: گیٹ وے، اور spoke میں اس کی عدم موجودگی
Azure، Basic کے علاوہ دیگر VPN Gateway SKU کے لیے گیٹ وے ٹرانزٹ کی معاونت کرتا ہے، اور علاقائی اور عالمی دونوں peering اسے لے جا سکتے ہیں۔ spoke ایسا گیٹ وے استعمال کرتا ہے جو اس کی ملکیت نہیں، اس لیے اس کا اپنا گیٹ وے نہیں ہو سکتا: اگر spoke میں پہلے ہی گیٹ وے موجود ہے، یا دور دراز گیٹ وے کا اختیار پہلے ہی منتخب ہے، تو مطلوبہ ٹرانزٹ ترتیب دستیاب نہیں ہوگی یا مؤثر نہیں ہوگی۔ کچھ بھی ڈیبگ کرنے سے پہلے یہ جانچ لیں، کیونکہ غیر فعال چیک باکس علامت ہے، خرابی نہیں۔ پہلے SKU اور موجودہ گیٹ وے پڑھیں، پھر peering کی ترتیبات دیکھیں۔
اختیار کے ظاہر ہونے کے لیے موجودہ spoke گیٹ وے کو حذف نہ کریں جب تک آپ کو معلوم نہ ہو کہ اس پر کیا منحصر ہے۔ منتقلی کی ترتیب چیک باکس سے زیادہ اہم ہے۔
دوسری شرط: peering کی ہر سمت میں ایک ترتیب
peering دو اشیاء ہیں، ہر VNet پر ایک، اور ٹرانزٹ کی ترتیبات اس جوڑی کے الگ الگ پہلوؤں میں ہیں۔ hub کا spoke کی طرف peering، hub گیٹ وے کو spoke کی خدمت کرنے کی اجازت دینا چاہیے؛ spoke کا hub کی طرف peering، hub کے گیٹ وے کو قبول کرنا چاہیے۔ Microsoft کی گیٹ وے ٹرانزٹ گائیڈ انہیں سمت کے مطابق نام دیتی ہے، اور انہیں درست رکھنے کا یہی واحد طریقہ ہے:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote کے لیبل والا کنٹرول اس بات پر منحصر ہو کر معنی بدلتا ہے کہ آپ کس VNet کی peering میں ترمیم کر رہے ہیں، اس لیے لفظ نہیں، سمت پڑھیں۔ دونوں طرفین مرتب کریں، محفوظ کریں اور تصدیق کریں کہ peering دونوں مقامات پر منسلک ہونے کی رپورٹ دیتی ہے۔
تیسری شرط: پتے کی جگہ اور اجازت کی حدود
ٹرانزٹ ایک ہی منزل کے سابقے کو دو نیٹ ورکس کا مطلب نہیں بنا سکتا، اس لیے hub، spoke اور مقامی نیٹ ورک کی حدود کو اس سے پہلے الگ ہونا چاہیے کہ ان میں سے کچھ کام کرے۔ VNet مختلف سبسکرپشنز یا مختلف کرایہ داروں میں بھی ہو سکتے ہیں؛ یہ ممانعت نہیں، لیکن ہر peering بنانے یا اپ ڈیٹ کرنے والی شناخت کے پاس اس نیٹ ورک پر مطلوبہ اجازتیں ہونی چاہئیں۔ سبسکرپشنز کے درمیان تبدیلیاں اکثر اجازت پر ناکام ہوتی ہیں، اور غلطی کو ٹوپولوجی مسئلہ پڑھنا آسان ہے۔
تبدیلی سے پہلے حدود اور مالکان لکھ لیں۔ ان میں سے کسی کا اندازہ لگانا ایسی peering بناتا ہے جو منسلک ہوتی ہے مگر کچھ راستہ نہیں دیتی۔
peering کی حیثیت سے نہیں، مؤثر راستوں سے تصدیق کریں
spoke ورک لوڈ کے نیٹ ورک انٹرفیس پر مؤثر راستے دیکھیں اور اصل مقامی سابقہ تلاش کریں۔ سب نیٹ کی روٹ ٹیبل اور یہ جانچیں کہ گیٹ وے روٹ کا پھیلاؤ غیر فعال ہے یا نہیں، کیونکہ صارف کی متعین کردہ روٹ یا معائنہ کرنے والا آلہ peering کے جھنڈوں کے بتائے ہوئے راستے کو زیر کر سکتا ہے۔ پھر مخالف سمت کی تصدیق کریں: مقامی نیٹ ورک کو جاننا چاہیے کہ site-to-site کنکشن کے ذریعے spoke کے سابقے تک کیسے پہنچنا ہے، چاہے سیکھے گئے اعلانات سے یا واضح روٹ اور گاہک کے آلے پر مماثل محفوظ نیٹ ورک اندراج سے۔ اگر سابقہ کسی بھی طرف موجود نہ ہو، تو بدلنے والی چیز peering کے جھنڈے نہیں ہیں۔
spoke ورک لوڈ سے ایک سروس کی جانچ کریں اور جواب کی پیروی کریں۔ VPN گیٹ وے یا hub VM سے جانچ مختلف ماخذ سابقہ اور مختلف راستہ استعمال کرتی ہے۔
اگر ٹوپولوجی point-to-site گاہکوں کی بھی خدمت کرتی ہے، تو ان کے نصب شدہ راستوں کی الگ سے توثیق کریں۔ ٹوپولوجی تبدیلی کے بعد Windows گاہک پیکیجز کو دوبارہ بنانے کی ضرورت ہو سکتی ہے، اور یہ گیٹ وے شیئرنگ کی ناکامی کا ثبوت نہیں، گاہک کی روٹنگ کا کام ہے۔
گیٹ وے شیئر کرنے سے کیا نہیں ملتا
گیٹ وے ٹرانزٹ روٹنگ کی سہولت ہے، اختیار نہیں۔ نیٹ ورک سیکیورٹی گروپس، مقامی فلٹرز اور سروس سطح کے قواعد اب بھی طے کرتے ہیں کہ spoke ورک لوڈ کہاں تک پہنچ سکتا ہے، اس لیے مشترکہ ٹنل کے پیچھے سب کچھ کی اجازت ماننے کے بجائے مخصوص ماخذ سے منزل تک سروس فعال کریں۔
peering بھی اس طرح منتقلی نہیں ہے جیسے لوگ امید کرتے ہیں۔ ایک اور spoke یا نجی اینڈ پوائنٹ شامل کرنا اس کی اپنی روٹنگ اور رسائی کی ضروریات لاتا ہے جنہیں موجودہ ٹرانزٹ ترتیب پورا نہیں کرتی۔