ایک Azure VPN VM پر دو عوامی IP: کون کیا کرتا ہے

ایک Azure VPN VM پر دو عوامی IP ایسی توقع پیدا کرتے ہیں جو شاذ و نادر ہی پوری ہوتی ہے: جس پتے سے کلائنٹ جڑتے ہیں وہی پتہ ویب سائٹس کو بھی نظر آئے گا۔ یہ نتیجہ تین خودمختار فیصلوں سے آتا ہے، اور ان میں سے صرف پہلا ٹنل سننے والے سے متعلق ہے۔ دوسرا وہ مہمان ماخذ ہے جو آگے بھیجے گئے کلائنٹ ٹریفک کے لیے استعمال ہوتا ہے، اور تیسرا Azure کا اخراجی طریقہ ہے جو اُس ماخذ پر لاگو ہوتا ہے۔ ایک بدلیں تو باقی دو جہاں تھے وہیں رہتے ہیں، اس لیے ہر ایک کا واضح فیصلہ کریں۔

فیصلہ 1: ٹنل کہاں ختم ہوتی ہے

Azure کا عوامی IP NIC پر موجود نجی IP کنفیگریشن سے منسلک ہوتا ہے؛ یہ وہ پتہ نہیں جو آپ مہمان آپریٹنگ سسٹم کے اندر شامل کرتے ہیں۔ اندازہ لگانے کے بجائے نقشہ پڑھیں: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'۔ وہ استفسار جو بھی نجی پتہ واپس کرے، مہمان کو درحقیقت وہی رکھنا ہوتا ہے۔

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

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

فیصلہ 2: آگے بھیجا گیا کلائنٹ کون سا ماخذ استعمال کرتا ہے

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

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

فیصلہ 3: کون سا Azure اخراجی طریقہ جیتتا ہے

Microsoftاخراج کی ترجیحی ترتیبکی دستاویز کرتا ہے: آلے یا گیٹ وے تک قابل اطلاق راستہ ترجیح رکھتا ہے، اور متعلقہ راستے پر سب نیٹ NAT Gateway کنیکٹیویٹی مثال کی سطح کے عوامی IP پر ترجیح رکھتی ہے۔ یہی ترتیب وجہ ہے کہ 10.20.0.5 پر ترجمہ یہ ثابت نہیں کرتا کہ ویب سائٹ 198.51.100.20 دیکھے گی۔ اخراجی ڈیزائن قبول کرنے سے پہلے موثر روٹ ٹیبل، NAT Gateway تعلق اور NIC کا عوامی IP ایک ساتھ پڑھیں۔

رکھیںAzure NIC فارورڈنگ سیٹنگکو Linux فارورڈنگ سے الگ۔ کلاؤڈ پرچم ایسے پیکٹوں کی اجازت دیتا ہے جن کا ماخذ یا منزل NIC کو تفویض نہ ہو؛ یہ net.ipv4.ip_forward فعال نہیں کرتا، اور مہمان کی سیٹنگ کلاؤڈ کی اجازت نہیں دیتی۔

ٹنل ساکٹ کا اپنا ماخذ فیصلہ ہے

wg-quick کے تحت WireGuard کا Address WireGuard انٹرفیس کو پتہ تفویض کرتا ہے؛ یہ بیرونی UDP بائنڈنگ کی ہدایت نہیں۔ خفیہ کردہ ساکٹ کا ماخذ روٹ ٹیبل کی پیروی کرتا ہے، اس لیے پالیسی راستہ یا دوسرا طے شدہ راستہ انٹرفیس کے پتے کو چھوئے بغیر اسے ہلا سکتا ہے۔OpenVPNکا local اختیار اور UDP multihome اسی طرح برتاؤ کرتے ہیں: یہ سننے والے اور اس کے جوابات سے متعلق ہیں، ہر آگے بھیجے گئے کلائنٹ کے انٹرنیٹ ماخذ سے نہیں۔

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

کیا قبول کریں، اور کس ترتیب سے

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

کامیاب ٹنل صرف پہلا حصہ ثابت کرتی ہے۔ اخراج کو نئے بہاؤ سے جانچیں، کیونکہ کیش شدہ کنکشن راستہ بدلنے کے بعد بھی دیر تک پرانا ماخذ استعمال کر سکتا ہے۔