Azure UDR سے VPN گیٹ وے تک: ایک منزل، پورا اخراج نہیں

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

اگلا ہاپ ایک گیٹ وے ہے، کسی ڈیوائس کا IP نہیں

ایک UDR مماثل پریفکس کو اگلے ہاپ کی قسم کو بھیجتا ہے، اور VirtualNetworkGateway ایک قسم ہے، پتہ نہیں۔ لوگ گیٹ وے کا نجی IP ایک VirtualAppliance روٹ میں چپکا دیتے ہیں اور پھر سوچتے ہیں کہ کچھ بھی کیوں مماثل نہیں، کیونکہ وہ قسم اس کے بجائے NIC یا اندرونی لوڈ بیلنسر کی توقع کرتی ہے۔ Microsoft کی روٹنگ دستاویزات بھی گیٹ وے کے اگلے ہاپ کو ایسے ورچوئل نیٹ ورک تک محدود کرتی ہیں جس کا گیٹ وے VPN گیٹ وے ہو۔ ExpressRoute، Route Server اور Virtual WAN حب اس اختیار سے مخاطب نہیں ہوتے۔

روٹ لکھنے سے پہلے جانچیں کہ ورچوئل نیٹ ورک میں واقعی کیا ہے۔ اگر ڈیزائن حب کے ذریعے روٹ کرتا ہے، تو روٹ حب کے روٹنگ مالک کا ہے، نہ کہ اس اسپوک کا جسے آپ ترمیم کر رہے ہیں۔

کچھ بدلنے سے پہلے مؤثر روٹ پڑھیں

Azure سسٹم روٹ، BGP سے سیکھے گئے پریفکس اور UDR کو ہر NIC کے لیے ایک مؤثر روٹ ٹیبل میں جوڑتا ہے، اور سب سے لمبا مماثل پریفکس جیتتا ہے، چاہے وہ کہیں سے بھی آیا ہو۔ ایک ہی پریفکس کے لیے، UDR BGP روٹ کو ہرا دیتا ہے۔ یہی ترتیب وجہ ہے کہ پچھلے تجربے کا پرانا UDR خاموشی سے اس پریفکس کو پیچھے چھوڑ سکتا ہے جو آپ نے ابھی سرنگ کے ذریعے سیکھا ہے۔

پہلے مؤثر ٹیبل دیکھیں، پھر فیصلہ کریں کہ آپ روٹ شامل کر رہے ہیں یا بدل رہے ہیں:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

پریفکس کے ساتھ ماخذ کا کالم بھی پڑھیں۔ درست پریفکس اور غلط ماخذ والا روٹ آپ کو بتاتا ہے کہ کون سی شے میں ترمیم کرنی ہے، اور پہلے سے ہارنے والا دوسرا روٹ شامل کرنے سے بچاتا ہے۔

اصل پریفکس اور سب نیٹ کے مطابق روٹ لکھیں

فورم پوسٹ سے نقل کی گئی عوامی رینج کے بجائے اس سروس سے لیئے گئے منزل کے اصل پریفکس استعمال کریں جس تک آپ واقعی پہنچتے ہیں۔ تمام اخراج کو ہٹانے والے ڈیفالٹ روٹ پر غور کرنے سے پہلے ایک منظور شدہ سروس سے شروع کریں۔ پھر روٹ ٹیبل کو ورک لوڈ سب نیٹ سے منسلک کریں۔ گیٹ وے سب نیٹ کی اپنی ضروریات ہیں، اور وہاں آپ کا ٹیبل منسلک کرنا ورک لوڈ کی رہنمائی کے بجائے گیٹ وے توڑ دیتا ہے۔

روٹ بنائیں، پھر ٹیبل کو اس سب نیٹ سے باندھیں جو ورک لوڈ کی میزبانی کرتا ہے:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

پھیلاؤ بھی اہم ہے۔ اس ٹیبل پر BGP پھیلاؤ فعال ہو تو سیکھے گئے پریفکس آپ کے لکھے ہوئے کے ساتھ ظاہر ہوتے ہیں، اور زیادہ مخصوص سیکھا گیا پریفکس وسیع UDR کو ہرا سکتا ہے۔ پھیلاؤ صرف اس وقت بند کریں جب آپ چاہتے ہیں کہ UDR مجموعہ اس سب نیٹ کے لیے مستند ہو۔

آن پریمیس نصف مکمل کریں ورنہ بہاؤ وہیں مر جائے گا

آن پریمیس گیٹ وے کو Azure ماخذ قبول کرنا چاہیے، اسے منزل تک بھیجنا چاہیے اور ایپلیکیشن کو اجازت دینی چاہیے۔ اس کا اگلا راستہ انٹرنیٹ اخراج یا کوئی اور نجی ہاپ ہو سکتا ہے، لیکن یہ فیصلہ Azure روٹ ٹیبل میں نہیں، منصوبے میں ہے۔ عام ناکامی واپسی کا راستہ ہے۔ انٹرنیٹ منزل نجی Azure ماخذ کو آپ کی طرف واپس روٹ نہیں کرے گی، اس لیے جواب اپنے ڈیفالٹ گیٹ وے پر جا کر مر جاتا ہے، یا باہر ہی نہیں نکلتا۔

دو ڈیزائن اسے حل کرتے ہیں اور وہ ایک دوسرے کے متبادل نہیں ہیں۔ اخراج پر ماخذ کا ترجمہ کریں, تاکہ منزل اس عوامی پتے کو جواب دے جو آن پریمیس نیٹ ورک کی ملکیت ہے۔ یا ماخذ محفوظ رکھیں اور روٹڈ واپسی تعلق بنائیں تاکہ جواب سرنگ کے ذریعے واپس آئیں۔ ایک منتخب کریں اور لکھیں کہ ایپلیکیشن کون سا پتہ دیکھے گی۔

سلیکٹر اور اجازت کی فہرستیں ان سب سے الگ ہیں۔ Azure اگلے ہاپ کا انتخاب VPN ٹریفک سلیکٹر کو وسیع نہیں کرتا، اور کسی بیرونی سروس کی ماخذ اجازت فہرست نہیں بدلتا۔

منزل کے مشاہدہ کردہ ماخذ سے تصدیق کریں

درخواست کسی دوسرے سب نیٹ کے جمپ ہوسٹ سے نہیں، اصل ورک لوڈ سے بھیجیں، پھر منزل کے دیکھے گئے ماخذ پتے کو پڑھیں۔ وہی ایک قدر بتاتی ہے کہ دو واپسی ڈیزائنوں میں سے کون سا لاگو ہے۔ پھر جواب کے راستے کی جانچ کریں، اور تصدیق کریں کہ VM تک عام انتظامی ٹریفک اب بھی کام کرتا ہے، کیونکہ حادثاتی طور پر شامل کیا گیا ڈیفالٹ روٹ ایپلیکیشن خراب ہونے سے بہت پہلے ٹوٹے ہوئے SSH سیشن کے طور پر ظاہر ہوتا ہے۔

منتخب پریفکس کے ذریعے گزرنا جبری سرنگ سے کہیں زیادہ تنگ تبدیلی ہے۔ اسے تنگ رکھیں اور واپسی ایک روٹ کو حذف کرنا ہے۔