Azure VPN میں NAT اوور لیپنگ VNet پتوں کو حل نہیں کرتا
ایک ہی نجی رینج والے دو VNet محض NAT موجود ہونے سے نہیں جڑیں گے۔ پہلے کنکشن کی قسم دیکھیں، پھر دوبارہ نمبر دیں یا ترجمہ کا عرف رکھیں۔
دونوں VNet 10.40.1.0/24 استعمال کرتے ہیں، ٹنل اوپر آتے ہیں، اور کچھ بھی کام نہیں کرتا۔ دوسرا VPN گیٹ وے شامل کرنے سے یہ نہیں بدلتا، اور نہ ہی کم روٹ میٹرک سے، کیونکہ مسئلہ راستے کے انتخاب میں نہیں ہے۔ ایک ہی نجی پتے کا جواب دینے والے دو ورک لوڈ ہر پیکٹ کو مبہم منزل اور ناقابل تصدیق واپسی راستے کے ساتھ چھوڑ دیتے ہیں۔ کسی بھی ترجمے کی منصوبہ بندی سے پہلے معلوم کریں کہ آپ نے دراصل کس قسم کا کنکشن بنایا ہے، کیونکہ یہی ایک انتخاب طے کرتا ہے کہ Azure کی NAT سہولت بالکل دستیاب ہے یا نہیں۔
یہ علامت دراصل آپ کو کیا بتا رہی ہے
جب VNet A کا میزبان 10.40.1.10 پر بھیجتا ہے، روٹنگ ٹیبل اسے صرف کہیں اشارہ کر سکتا ہے۔ اگر VNet B میں بھی 10.40.1.10 موجود ہو، تو وہ پتہ ایسی منزل نہیں جسے راستہ ممتاز کر سکے؛ یہ دو مالکان والا ایک ہی پتہ ہے۔
لوگ عام طور پر جو دوسرا گیٹ وے تعینات کرتے ہیں وہ مدد نہیں کرتا۔ یہ ایک اور ٹنل دیتا ہے، دوسرا پتہ نہیں، اور نقل شدہ رینج ٹنل کے اندر بغیر تبدیلی سفر کرتی ہے۔ یہ اس ترتیب کو بھی دوگنا کرتا ہے جسے آپ کو مستقل رکھنا ہے۔ جو یہ نہیں کر سکتا وہ یہ ہے کہ ایک پتے کا مطلب دو میزبان کر دے۔
VPN ساتھیوں کے عوامی پتوں کو تبدیل کرنے سے بھی کچھ نہیں ہوتا۔ وہ پتے ٹنل کے سرے کی نشاندہی کرتے ہیں، جب کہ ٹکراؤ اس نجی رینج میں ہے جو اس کے اندر لے جایا جاتا ہے۔
NAT دستیاب ہے یا نہیں یہ کنکشن کی قسم طے کرتی ہے
Azure VPN Gateway میں واقعی NAT کی صلاحیت ہے، اور یہ مخصوص گیٹ وے SKU پر روٹ پر مبنی IPsec بین السائٹ کنکشن کے لیے دستاویز کی گئی ہے۔ یہی دستاویز VNet-to-VNet اور point-to-site کنکشن کو مستثنی قرار دیتی ہے، اس لیے یہ سہولت ہر گیٹ وے تعلق پر نظر آنے والا چیک باکس نہیں ہے۔
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
مول VNet-to-VNet کے لیے بھی ضروری ہے کہ VNet اور مقامی نیٹ ورک کی رینج شروع ہی سے اوور لیپ نہ ہوں، جو اس استثنا سے ہم آہنگ ہے۔ اسی وجہ سے VNet پیئرنگ بھی اوور لیپ کا حل نہیں ہے۔
ایک معاون متبادل ہے جسے لوگ مول قسم کے ساتھ خلط ملط کرتے ہیں: دوسرے VNet کو مقامی نیٹ ورک کے طور پر ماڈل کریں اور اسے سائٹ سے سائٹ کنکشن کے طور پر جوڑیں۔ یہ الگ وسیلہ اور الگ ڈیزائن ہے، اس لیے نام بدلے کنکشن کو محض نام کی تبدیلی نہیں بلکہ توثیق طلب تبدیلی سمجھیں۔
دوبارہ نمبر دیں، یا ایسی چیز سے ترجمہ کریں جو عرف کی مالک ہو
اگر دونوں VNet آپ کے ہیں، تو منصوبہ بند دوبارہ نمبر دینے کا ترجمے کی مسلسل لاگت سے موازنہ کریں۔ دوبارہ نمبر دینا ایپلیکیشن ترتیب، DNS ریکارڈز، سلامتی قواعد اور ہر موجودہ کنکشن کو چھوتا ہے، لیکن بعد میں عام طور پر پڑھے جانے والا نیٹ ورک چھوڑ دیتا ہے۔ ایک وقت میں ایک سب نیٹ کریں، DNS تبدیلی سب سے آخر میں۔ آدھی دوبارہ نمبر شدہ رینج دونوں آپشنز سے بدتر ہے، کیونکہ پھر دونوں سابقے اگلی بار جدول پڑھنے والے کو مستند لگتے ہیں۔
جہاں دوبارہ نمبر دینا عملی نہ ہو، وہاں عرف کے حقیقی مالک والا مترجم ڈیزائن استعمال کریں۔ VNet A کے کالر VNet B کے 10.40.1.10 تک 10.140.1.10 کے طور پر پہنچ سکتے ہیں، لیکن اس عرف کے لیے ترجمہ کرنے والا آلہ، اس کی طرف راستہ اور جواب کے لیے موافق رویہ درکار ہے۔ صرف DNS میں شامل کیا گیا پتہ ترجمہ نہیں ہے۔
دونوں رینج دونوں سمتوں میں درج کریں: کالر کیا ڈائل کرتا ہے، منزل ماخذ کے طور پر کیا دیکھتی ہے، اور کون فریق آغاز کر سکتا ہے۔ Azure کے اپنے NAT قواعد اپنے SNAT میپنگ کے لیے الٹا ترجمہ شامل کرتے ہیں، اس لیے آپ ہاتھ سے موافق DNAT قاعدہ نہیں لکھتے، لیکن وہ سہولت انہی کنکشن اقسام تک محدود ہے جنہیں یہ فیچر معاونت دیتا ہے۔
کیا کام نہیں کرے گا
صارف کی متعین راستہ یا روٹ میٹرک غائب پتہ امتیاز پیدا نہیں کر سکتے۔ دونوں ابھی بھی مبہم منزل پر کام کرتے ہیں، اور پیکٹ اسی اگلے ہاپ تک پہنچتا ہے جسے جدول ترجیح دیتا ہے۔
نقل شدہ رینج کو زیادہ مخصوص سابقے کے طور پر روٹ ٹیبل میں شامل کرنا ابہام کو صرف ایک قدم آگے بڑھاتا ہے۔ یہ مخالف سمت کو بھی توڑنے کا رجحان رکھتا ہے، جہاں جواب کے اب دو ممکنہ ماخذ ہیں۔
دونوں سمتوں کی ٹریفک کے ساتھ ڈیزائن قبول کریں
ڈیزائن کو ٹنل کی حالت سے نہیں، بلکہ ہر فریق سے نئی اجازت شدہ کارروائی سے ثابت کریں۔ منسلک IPsec ٹنل کہتا ہے کہ ساتھی کرپٹوگرافی پر متفق ہیں؛ یہ نہیں بتاتا کہ منزلیں قابل امتیاز ہوئیں یا نہیں۔
پھر مسترد راستے چلائیں: ایسا پتہ جو ناقابل رسائی رہنا چاہیے، اور ایسی سروس جسے پالیسی کو روکنا چاہیے۔ اگر دونوں اب بھی کامیاب ہوں، تو ترجمہ ڈیزائن کے ارادے سے زیادہ وسیع ہے۔
ان حقائق کے ساتھ اختتام کریں جو بعد میں یہ ترتیب بیان کریں گے: اصل رینج، پیش کردہ رینج، ترجمہ کرنے والا آلہ، اور وہ سمت جس میں ہر فریق آغاز کر سکتا ہے۔ اگر ان میں سے کوئی غائب ہو، تو اگلا انجینئر ایسا نیٹ ورک ورثے میں پاتا ہے جہاں دو میزبان ایک ہی نام شیئر کرتے ہیں اور کسی کو یاد نہیں کہ ان میں سے ایک جواب کیوں دیتا ہے۔