Azure سائٹ سے سائٹ VPN اور NAT کے پیچھے پیر: چیک لسٹ

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

قدم 1: تصدیق کریں کہ پیر واقعی NAT کے پیچھے ہے

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

اگر دونوں پتے مل جائیں تو یہیں رک جائیں: NAT آپ کا مسئلہ نہیں اور اس فہرست کا باقی حصہ مدد نہیں کرے گا۔

ٹکٹ میں دونوں پتے اور مترجم کا ماڈل لکھیں۔ وہ ایک سطر اگلی بار یہ پوچھنے سے روکتی ہے کہ ترتیب دیا گیا پیر جواب کیوں نہیں دیتا۔

قدم 2: طے کریں کہ کون شروع کرے گا

Azure VPN Gateway کے عام سوالات NAT-T کی حمایت کا ذکر کرتے ہیں اور یہ شامل کرتے ہیں کہ آن پریمائز آلے کو NAT کے پیچھے ہونے پر IPsec ٹنل شروع کرنی چاہیے۔ یہ اس بات سے میل کھاتا ہے کہ حالت رکھنے والا ترجمہ کیسے کام کرتا ہے، کیونکہ مترجم میپنگ رکھتا ہے کیونکہ اندرونی آلے نے پہلا پیکٹ بھیجا تھا۔ اگر Azure سے شروع کرنے کی توقع ہو اور وہ میپنگ بنانے کے لیے کچھ نہ آئے تو ٹنل کبھی شروع نہیں ہوتی۔

پیر کو ایسے ترتیب دیں کہ صرف جواب دینے والے کی غلطی واضح ہو، اور دیکھیں کہ آلہ خود دوبارہ کوشش کرتا ہے یا محرک چاہیے۔ کچھ آلات ٹنل تبھی اٹھاتے ہیں جب دلچسپ ٹریفک ظاہر ہو، جو ٹھیک ہے جب تک دلچسپ ٹریفک ایسی صحت جانچ نہ بن جائے جو کبھی نہ آئے۔

دستی آغاز کے دوران آلے پر IKE کے تبادلے کو دیکھیں؛ وہاں خاموشی روٹنگ یا فائر وال کا جواب ہے، Azure کا جواب نہیں۔

قدم 3: پیر کا پتہ درست کریں

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

اگر عوامی پتہ بدلے تو وہ آبجیکٹ بھی اس کے ساتھ بدلنا چاہیے۔ پرانے پتے پر حل ہونے والا نام اس مستقل پتے سے بدتر ہے جسے ہاتھ سے اپ ڈیٹ کرنا پڑتا ہے۔

تینوں اقدار لکھیں: آلے کا مقامی پتہ، ترجمہ شدہ عوامی پتہ، اور ترتیب دی گئی پیر شناخت۔

قدم 4: صرف وہی پورٹ کھولیں جو NAT-T کو درکار ہیں

NAT-T، ESP کو UDP کے اندر لے جاتا ہے، اور RFC 3948 اس encapsulation کو بیان کرتا ہے جس میں پورٹ 4500 پورٹ 500 پر ابتدائی گفت و شنید کے بعد استعمال ہوتا ہے۔ آپ کے فائر وال اور مترجم دونوں کو تبادلے اور اس کی واپسی ٹریفک کی اجازت دینی چاہیے۔ غیر متعلق TCP پورٹ کی اجازت دینا اس راستے کے بارے میں کچھ ثابت نہیں کرتا، اور وہ اصول جو باہر جانے کی اجازت دے مگر جواب کی نہ دے، پھر بھی ناکام ہوگا۔

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

مترجم کے دونوں اطراف ایک بار کیپچر کریں؛ encapsulation کا فرق فوراً نظر آتا ہے۔

قدم 5: بیرونی ترسیل کو اندرونی روٹنگ سے الگ کریں

جو ٹنل بنے مگر کچھ نہ لے جائے وہ روٹنگ کا مسئلہ ہے، NAT-T کا نہیں۔ سائٹس کو اب بھی موزوں ٹریفک سلیکٹر، ملتے جلتے پتہ فضائیں، رسائی کے اصول اور ایپلیکیشن نیٹ ورکس کے لیے واپسی راستہ درکار ہے۔ ان میں سے کوئی چیز کامیاب IKE تبادلہ فراہم نہیں کرتا۔

اگر دونوں سائٹس ایک دوسرے پر چڑھنے والی نجی رینجیں استعمال کریں تو ٹنل کے اندر ترجمہ اپنے اصولوں والا الگ ڈیزائن ہے۔ صرف اس لیے سب نیٹ کو دوبارہ نمبر نہ دیں کہ بیرونی گیٹ وے اتفاقاً گھریلو روٹر کے پیچھے ہے۔

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