ہیئرپن NAT: اندر سے VPN اینڈ پوائنٹ کیوں ناکام ہوتا ہے
عوامی پتہ استعمال کرنے والا مقامی کلائنٹ LAN چھوڑ کر واپس اندر آتا ہے۔ جب راؤٹر ہیئرپن نہیں کرتا تو باہر سے کام کرتا ہے اور اندر سے نہیں۔
موبائل نیٹ ورک سے جواب دینے والا مگر صوفے سے ناکام ہونے والا VPN سرور عام طور پر سرٹیفکیٹ کا مسئلہ نہیں ہوتا۔ LAN کے اندر موجود کلائنٹ راؤٹر سے ایسا پیکٹ ترجمہ کرنے کو کہتا ہے جس کا منزل راؤٹر کا اپنا عوامی پتہ ہے، یعنی پیکٹ کو باہر جا کر فوراً واپس اندر آنا ہے۔ اس چال کو hairpinning کہتے ہیں، اور بہت سے راؤٹر اسے یا تو نافذ نہیں کرتے یا صرف چیک باکس فعال ہونے پر کرتے ہیں۔ باہر کی جانچ کا پاس ہونا ہی الجھن کی وجہ ہے، کیونکہ یہ ثابت کرتا ہے کہ سننے والا اور فارورڈنگ اصول درست ہیں۔
پیکٹ باہر جاتا ہے اور واپس اندر آتا ہے
پیکٹ کا پیچھا کریں۔ کلائنٹ عوامی نام حل کرتا ہے، عوامی پتے سے جڑتا ہے، اور راؤٹر کا منزل NAT منزل کو اندرونی سرور کی طرف دوبارہ لکھتا ہے۔ سرور کا جواب کلائنٹ کے LAN پتے پر مخاطب ہے، اس لیے یہ راؤٹر کے LAN انٹرفیس سے واپس جاتا ہے، اس NAT اصول سے کبھی نہ گزرتے ہوئے جو ماخذ کو واپس ترجمہ کرتا۔
اب کلائنٹ کو ایسے پتے سے پیکٹ ملتا ہے جہاں اس نے کبھی کچھ نہیں بھیجا، اور وہ اسے پھینک دیتا ہے۔ یہی عدم توازن پوری خرابی ہے۔
RFC 4787 اس صورت میں NAT سے متوقع رویے کی وضاحت کرتا ہے، اور مختصر بات یہ ہے کہ عملاً یہ اختیاری ہے، وہاں بھی جہاں نظریاتی طور پر متعین ہے۔ کچھ راؤٹر اس ترتیب کو NAT loopback کہتے ہیں، کچھ ہیئرپن NAT یا NAT reflection، اور کچھ کچھ بھی ظاہر نہیں کرتے۔ جس راؤٹر میں یہ نہیں وہ غلط کنفیگر نہیں؛ وہ معمول کا کام کر رہا ہے، اور حل کہیں اور ہے۔ مقامی جانچ ناکام ہونے سے یہ نتیجہ نہ نکالیں کہ عوامی فارورڈنگ اصول غلط ہے۔
جانچ 1: دونوں راستے الگ الگ آزمائیں
LAN سے باہر سے، اسی پروفائل سے جڑیں جو حقیقی صارف استعمال کرے گا اور تصدیق کریں کہ سیشن قائم ہوتا ہے۔ اندر سے، اسی پروفائل سے عوامی پتے پر جڑیں اور درست خرابی اور وقت نوٹ کریں۔
درست مقامی جانچ میزبان نام رکھتی ہے اور صرف پتہ بدلتی ہے: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ درخواست عوامی پتے پر بھیجتا ہے اور ساتھ ہی درست سرور نام پیش کرتا ہے۔ یہ نام کے حل کے مسئلے کو ترجمے کے مسئلے سے الگ کرتا ہے، اور جب وہی نام کسی کیفے سے کام کرے تو دونوں آسانی سے الجھ جاتے ہیں۔ نوٹ کریں کہ کلائنٹ TCP کنکشن پر ناکام ہوتا ہے یا بعد میں TLS پر، کیونکہ پہلا ترجمے اور دوسرا شناخت کی طرف اشارہ کرتا ہے۔
جانچ 2: پڑھیں کہ سرور کیا دیکھتا ہے
سب سے مفید مشاہدہ سرور کا نقطہ نظر ہے۔ VPN میزبان پر کلائنٹ کے LAN پتے اور راؤٹر کے LAN پتے پر فلٹر شدہ کیپچر چلائیں، پھر مقامی کوشش دہرائیں۔ اگر کچھ نہ آئے تو پیکٹ ترجمے سے بچ نہیں سکا۔
اگر کنکشن کلائنٹ کے پتے کے بجائے راؤٹر کے LAN پتے سے آتا ہے، تو ہیئرپننگ ہو رہی ہے اور ماخذ دوبارہ لکھا گیا ہے۔ یہ کام کرنے والی ترتیب ہے، خرابی نہیں۔
جانچ 3: بیرونی راستے کو چھوئے بغیر درست کریں
تین معاون شکلیں ہیں، اثر کے دائرے کے بڑھتے ہوئے ترتیب میں۔ سب سے تنگ تقسیم شدہ DNS ہے: اندرونی ریکارڈ شائع کریں تاکہ وہی سرور نام LAN کے کلائنٹس کے لیے اندرونی پتے پر حل ہو، جو عوامی راستے سے مکمل بچتا ہے۔ اگلا راؤٹر کے دستاویزی loopback یا reflection اختیار کو فعال کرنا ہے، اگر ہو، اور اسے صرف اس سروس پر لاگو کرنا۔ سب سے وسیع راؤٹر پر source-NAT اصول ہے جو LAN سے آنے والی ٹریفک کو سرور کی طرف دوبارہ لکھتا ہے تاکہ جواب راؤٹر سے واپس آئے؛ Linux راؤٹر پر یہ سرور کے پتے اور پورٹ سے مطابقت رکھنے والا MASQUERADE اصول POSTROUTING ہے۔ تینوں بیرونی راستے کو اچھوتا رکھتے ہیں، اور یہی وہ خصوصیت ہے جو محفوظ رکھنی ہے۔
مقامی راستے کو بیرونی جیسا بنانے کے لیے غیر متعلق پورٹ فارورڈنگ نہ بڑھائیں، اور مسئلے سے بچنے کے لیے سروس کو دوسرے پورٹ پر نہ لے جائیں۔ دونوں تبدیلیاں بیرونی دنیا کہاں تک پہنچ سکتی ہے یہ بدلتی ہیں، صرف اندرونی دنیا جو دیکھتی ہے اسے درست کرنے کے لیے۔
تقسیم شدہ DNS میں ایک جال ہے جس کا ذکر کرنا مناسب ہے۔ میزبان نام کو منمانے IP سے بدلنا بدل دیتا ہے کہ کلائنٹ کیا تصدیق کرتا ہے، اس لیے اندرونی ریکارڈ کو اب بھی سرٹیفکیٹ کے نام سے مطابقت رکھنی چاہیے۔
جانچ 4: بعد میں دونوں راستے تصدیق کریں
LAN سے باہر سے بیرونی کوشش دہرائیں، اسی پروفائل سے اندرونی کوشش دہرائیں، اور تصدیق کریں کہ سرور لاگ ایک کامیابی اور ایک خاموشی کے بجائے دو الگ کامیاب سیشن دکھاتا ہے۔ پھر جانچیں کہ دیگر کلائنٹس اب بھی سننے والے تک پہنچتے ہیں اور نجی وسائل کے راستے تبدیل نہیں ہوئے۔
ریکارڈ مختصر رکھیں: کس کلائنٹ نے کون سا پتہ استعمال کیا، سرور نے کیا دیکھا، اور تین اصلاحات میں سے کون سی لاگو ہوئی۔ RFC 4787 کی ہیئرپننگ شرائط یہاں NAT سے کیا متوقع ہے اس کا حوالہ ہیں، اور بیان کرتی ہیں کہ اس خصوصیت کے بغیر راؤٹر معمول کا رویہ کیوں کرتا ہے۔ بیرونی دنیا جو دہرا نہیں سکتی ایسی مقامی ناکامی الٹ ثابت ہونے تک ترجمے کا سوال ہے، اس لیے اسی طرح جانچیں۔