کیا آپ کو VPN ذیلی نیٹ میں پورٹ فارورڈ پر SNAT لگانا چاہیے؟

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

جواب الگ راستہ کیوں لیتا ہے

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

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

بھروسے کے قابل تنگ ماخذ قاعدہ

روٹر کو وہ ماخذ بنائیں جسے دور دراز میزبان جواب دیتا ہے۔ اس ترتیب میں WAN پتہ 203.0.113.24 ہے، LAN 192.168.88.0/24 ہے، روٹر کا ٹنل پتہ 172.20.5.1 ہے، اور سروس 172.20.5.40:8443 پر جواب دیتی ہے۔ نیچے دیا گیا قاعدہ منزل کے ترجمے کے بعد پیکٹ سے میل کھاتا ہے، اسی لیے یہ عوامی کے بجائے ترجمہ شدہ پتے کا نام لیتا ہے۔ اس میں کچھ بھی کلائنٹ کے پتے پر منحصر نہیں ہے، اور یہی اصل بات ہے۔

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

کب جامع مسکراڈ دیانتدارانہ انتخاب ہے

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

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

شائع کرنے سے پہلے کاؤنٹر جانچیں

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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