دو شاخوں کے درمیان ٹریفک کو Azure VPN گیٹ وے کے ذریعے روٹ کریں
ایک Azure VPN گیٹ وے پر دو سائٹ ٹو سائٹ کنکشن شاخوں کی ٹریفک گزر سکتے ہیں، لیکن صرف تب جب دونوں سرے پریفکس سیکھیں اور LAN میں واپسی کا راستہ موجود ہو۔
دو شاخیں آپس میں کسی براہ راست سرنگ کے بغیر Azure VPN گیٹ وے کے ذریعے ٹریفک کا تبادلہ کر سکتی ہیں۔ ہر شاخ اسی گیٹ وے سے سائٹ ٹو سائٹ کنکشن کھولتی ہے، اور گیٹ وے سیکھے گئے پریفکس کو دونوں کنکشنوں کے درمیان منتقل کرتا ہے۔ اسے کام کرنے والی دوسری سرنگ نہیں بلکہ روٹوں کا تبادلہ ہے: شاخ A کو شاخ B کا پریفکس سیکھنا ہوگا، اور B کو A کا۔ نیچے دیے گئے جائزے ترتیب سے کریں اور پہلے ناکام جائزے پر رک جائیں، کیونکہ ہر اگلا قدم اسی پر منحصر ہے۔
کچھ بھی کنفیگر کرنے سے پہلے پیشگی شرائط
یہ ڈیزائن بالکل کام کر سکتا ہے یا نہیں، یہ چار شرطیں طے کرتی ہیں۔ گیٹ وے روٹ پر مبنی ہونا چاہیے اور ایسے SKU پر ہونا چاہیے جو BGP کی حمایت کرے، دونوں کنکشنوں پر BGP فعال ہونا چاہیے، شاخوں کے پتے کی جگہیں ایک دوسرے پر نہیں چڑھنی چاہئیں، اور کوئی بھی فریق اپنا اصل پریفکس چھپانے کے لیے NAT پر انحصار نہیں کر سکتا۔
ASN کا منصوبہ سوچ سمجھ کر بنائیں۔ Azure کی دستاویزی ڈیفالٹ 65515 ہے، اور ہر شاخ کے راؤٹر کو اپنا نجی ASN چاہیے جو گیٹ وے یا دوسری شاخ سے نہ ٹکرائے۔ موجودہ گیٹ وے کنفیگریشن کی جانچ کیے بغیر ڈیفالٹ دوبارہ استعمال کرنا ہی وہ طریقہ ہے جس سے بعد میں AS راستہ مسترد ہوتا ہے۔
یہ بھی یقینی بنائیں کہ آپ VNet پیئرنگ کے رویے کی توقع نہیں کر رہے۔ گیٹ وے ان دو کنکشنوں کے درمیان راستوں کا تبادلہ کرتا ہے جو آپ نے کنفیگر کیے؛ یہ من مانی پیئرنگ کو منتقلی نہیں بناتا۔ اگر کسی تیسرے نیٹ ورک کو دونوں شاخوں تک پہنچنا ہے تو اسے اپنا کنکشن یا اپنا روٹ راستہ چاہیے، یہ مفروضہ نہیں کہ گیٹ وے ٹریفک تقسیم کر دے گا۔ پہلی تبدیلی کی ونڈو سے پہلے یہ حد لکھ لیں، کیونکہ بعد میں سائٹ شامل کرنے پر لوگ اسی ڈیزائن کے فیصلے کی طرف لوٹتے ہیں۔
اسی ترتیب سے کنفیگر کریں
ہر قدم کا مشاہدہ کیا جا سکنے والا نتیجہ ہے، اس لیے اس کے ظاہر ہونے تک آگے نہ بڑھیں۔
- ورچوئل نیٹ ورک گیٹ وے پر BGP فعال کریں اور اس کا ASN اور پیئر پتہ نوٹ کریں۔
- ہر شاخ کے لیے اس شاخ کے اصل پتے کی جگہ، اس کے ASN اور اس کے BGP پیئر پتے کے ساتھ مقامی نیٹ ورک گیٹ وے بنائیں۔
- ہر سائٹ ٹو سائٹ کنکشن بنائیں اور کنکشن پر ہی BGP فعال کریں۔
- شاخ کے راؤٹر کو مفروضے کی بنیاد پر گیٹ وے کے عوامی IKE اینڈ پوائنٹ کے بجائے Azure کے تفویض کردہ گیٹ وے پتے کے ساتھ پیئر کرنے کے لیے کنفیگر کریں۔
چوتھا قدم ہی وہ جگہ ہے جہاں زیادہ تر کوششیں رک جاتی ہیں۔ Azure جو BGP پیئر پتہ بتاتا ہے وہی شاخ کے راؤٹر کو بطور ہمسایہ استعمال کرنا ہوتا ہے، اور یہ ہمیشہ وہ پتہ نہیں ہوتا جس کی لوگ سرنگ کے نقشے سے توقع کرتے ہیں۔
شاخ کا پریفکس خود نشر کریں، مثلاً A سے 10.10.0.0/16 اور B سے 10.20.0.0/16۔ کسی غائب مخصوص نیٹ ورک کو ڈھانپنے کے لیے ڈیفالٹ راستہ یا وسیع مجموعہ نشر نہ کریں؛ خلا بعد میں خاموش سیاہ شگاف کے طور پر واپس آتا ہے۔
دونوں سروں پر راستوں کا تبادلہ تصدیق کریں
کنکشن کی حالت جائزہ نہیں ہے۔ دونوں کنکشنوں پر IPsec چل سکتا ہے جبکہ ان کے درمیان کوئی پریفکس نہ گزرے۔ گیٹ وے کے BGP پیئر اور سیکھے گئے راستے پڑھیں، پھر تصدیق کریں کہ دوسری شاخ کی طرف راستہ قابل استعمال راستے کے طور پر ظاہر ہوتا ہے۔
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP جدول میں موجود پریفکس بھی کسی جامد راستے یا زیادہ مخصوص پریفکس کے سامنے فارورڈنگ کا فیصلہ ہار سکتا ہے۔ صرف موصول شدہ نہیں، منتخب شدہ راستہ جانچیں۔
LAN کی طرف واپسی کا راستہ پیروی کریں
یہ وہ حصہ ہے جو Azure میں درست دکھتا ہے اور سائٹ پر ناکام ہوتا ہے۔ شاخ A کا میزبان اپنا پیکٹ A کے VPN راؤٹر کو صرف تب بھیجتا ہے جب وہ راؤٹر اس کا ڈیفالٹ گیٹ وے ہو، یا میزبان یا اس کے گیٹ وے کے پاس B کے پریفکس کے لیے راستہ ہو۔ مخالف سمت میں بھی یہی سچ ہونا چاہیے۔
اگر کوئی الگ کور سوئچ LAN کا ڈیفالٹ گیٹ وے ہے تو اسے VPN راؤٹر کی طرف اشارہ کرنے والا دوسری شاخ کی طرف راستہ چاہیے۔ اس کے بغیر درخواست آتی ہے اور جواب انٹرنیٹ راستے سے نکل جاتا ہے، اور صارف کو ایسا کنکشن نظر آتا ہے جو کھلتا ہے اور پھر لٹک جاتا ہے۔
اسے ٹھیک کرنے کے لیے گیٹ وے سب نیٹ پر نیٹ ورک سیکیورٹی گروپ کی طرف نہ جائیں۔ اس سب نیٹ کی اپنی ضروریات ہیں اور وہاں NSG شاخ کی طرف کی پالیسی کا معاون متبادل نہیں ہے۔ فلٹرنگ شاخوں کے فائر والز اور خود ورک لوڈز پر ہونی چاہیے، جہاں مالکان قواعد کا جائزہ لے سکتے ہیں۔ ان قواعد کو سب نیٹ NSG میں منتقل کرنا انہیں اگلی خرابی ڈیبگ کرنے والی ٹیم سے بھی چھپا دیتا ہے۔
آپریشن کی اجازت دیں، پھر مسترد شدہ جانچ سے ثابت کریں
سیکھا گیا راستہ اجازت نہیں ہے۔ جو ماخذ، منزل اور سروس آپ کو واقعی درکار ہے اسے شاخوں کے فائر والز اور اینڈ پوائنٹ پالیسی کے ذریعے اجازت دیں، اور باقی مسترد رہنے دیں۔
شاخ A کے عام ورک لوڈ سے شاخ B کی حقیقی سروس تک جانچ کریں، جواب کی تصدیق کریں، پھر ایسا آپریشن آزمائیں جو ممنوع رہنا چاہیے۔ VPN آلے خود جو ٹریفک پیدا کرتا ہے وہ مختلف ماخذ پتہ استعمال کر سکتا ہے اور LAN راؤٹنگ مرحلہ چھوڑ سکتا ہے، اس لیے راؤٹر سے کامیاب ping دکھائی دینے سے کم ثابت کرتا ہے۔
چار حقائق لکھ کر ختم کریں: تبادلہ شدہ پریفکس، زیر استعمال ASN، ہر فریق کے لیے LAN واپسی راستہ، اور وہ پالیسی جو سروس کی اجازت دیتی ہے۔ ان میں سے ایک بھی غائب ہو تو سیٹ اپ پہلی تبدیلی تک کام کرتا ہے، اور پھر کوئی نہیں بتا سکتا کہ کیوں۔