VPN کلائنٹ کی سروس تک پہنچنا: اُلٹا سرنگ یا DNAT

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

دو شکلیں، ایک ملاقات کا مقام

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

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

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

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

پہلی شرط: کیا پورٹ کو سیشن سے زیادہ زندہ رہنا چاہیے

اُلٹی فارورڈنگ بالکل اُتنی دیر زندہ رہتی ہے جتنی دیر وہ SSH سیشن جس نے اُسے بنایا۔ جب لنک گرتا ہے تو سننے والا غائب ہو جاتا ہے اور ساتھی سست راستے کے بجائے مسترد کنکشن دیکھتا ہے۔ systemd یونٹ اور ری اسٹارٹ پالیسی کے ساتھ کمانڈ کی نگرانی اسے حل کرتی ہے، اور ExitOnForwardFailure=yes ناکام بائنڈنگ کو فوراً نظر آنے والا بناتا ہے، فارورڈنگ کے بغیر چلتا سیشن چھوڑنے کے بجائے۔

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

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

دوسری شرط: فائر وال اور لاگ کس کے ہیں

اُلٹی شکل ساری پالیسی دو جگہ رکھتی ہے۔ sshd AllowTcpForwarding کے ذریعے طے کرتا ہے کہ دور سے فارورڈنگ بالکل اجازت یافتہ ہے یا نہیں، اور GatewayPorts طے کرتا ہے کہ سننے والا لوپ بیک سے بندھے یا ہر پتے سے۔ طے شدہ no کے ساتھ سرور سے باہر کا ساتھی فارورڈنگ کامیاب ہونے کے باوجود پورٹ تک نہیں پہنچ سکتا، اور یہ ٹوٹی سرنگ جیسا لگتا ہے جبکہ حقیقت میں یہ بائنڈنگ پتہ ہے۔

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

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

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

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

تیسری شرط: ایک پورٹ یا کئی، اور نام کس کا ہے

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

نام اِسے مزید پیچیدہ کرتے ہیں۔ اُلٹی فارورڈنگ ایسے TCP پراکسی کے پیچھے بیٹھ سکتی ہے جو SNI کے مطابق راستہ دیتا ہے، جبکہ منتقلی شدہ پورٹ عام طور پر فی سروس ایک پورٹ ہوتا ہے۔ اگر سروس خود TLS ختم کرتی ہے اور اصل ہوسٹ نام چاہتی ہے تو پراکسی طریقہ اُسے بچاتا ہے، اور DNAT طریقہ اُسے صرف اُس وقت بچاتا ہے جب سروس وہ نام اُس پورٹ پر قبول کرے۔

لکھیں کہ تین شرطوں میں سے کس نے شکل کا فیصلہ کیا۔ ورنہ دوسری سروس شامل کرنے والا اگلا شخص کم سیاق کے ساتھ وہی موازنہ پھر کھولے گا۔

فیصلہ کریں، پھر باہر سے جانچیں

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

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

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

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