سرور کا IP بدلنے کے بعد بھی SNAT اصول پرانے کا ہی ذکر کرتا ہے

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

جڑنا اور فارورڈنگ الگ الگ جگہوں پر ناکام ہوتے ہیں

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

پتے کی تبدیلی صرف دوسرے فیصلے کو توڑتی ہے، اور اسی لیے علامت "جڑا ہوا ہے مگر انٹرنیٹ نہیں" کے طور پر پڑھی جاتی ہے۔ یہ یہ بھی بتاتا ہے کہ کلائنٹ کی طرف کی معمول کی جانچیں صحت مند کیوں لگتی ہیں: مصافحہ مکمل ہوتا ہے، کلائنٹ کو پتہ ملتا ہے، اور سرور کے ٹنل پتے پر ping بھی جواب دے سکتا ہے۔ خرابی دوسری طرف ہونے کے باوجود کلائنٹ پر گھنٹے ضائع ہوتے ہیں، اس لیے اصولوں کا جدول پہلی نظر کی جگہ ہے۔

ترمیم سے پہلے اصول اور اس کے کاؤنٹر پڑھیں

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

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

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

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

ماخذ بدلیں، یا اس کا نام لینا بند کریں

جب میزبان کے پاس مستقل پتہ ہو تو دوسرا شامل کرنے کے بجائے اصول کو اسی جگہ بدلیں۔ اصول کے نمبر سے تبدیلی وہ ترتیب بچاتی ہے جس پر زنجیر کا باقی حصہ منحصر ہے۔

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

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

تبدیلی غلط کرنے کے دو طریقے

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

پرانے پر دوسرا ترجمہ چڑھانا دوسری غلطی ہے۔ پہلا منطبق اصول جیتتا ہے، اس لیے پرانا اندراج مٹائے جانے تک پیکٹ سنبھالتا رہتا ہے، اور نئے اصول کے کاؤنٹر صفر پر رہتے ہیں جبکہ سب تبدیلی کو مورد الزام ٹھہراتے ہیں۔ کچھ نیا شامل کرنے سے پہلے نقل مٹا دیں۔ پھر فہرست ایک بار پھر پڑھیں اور تصدیق کریں کہ تالاب سے بالکل ایک ہی ترجمہ منطبق ہے۔

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

اندر آنے والی سروسز کو اُلٹا ترجمہ چاہیے

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

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

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