VPN کلائنٹس جڑتے ہیں مگر انٹرنیٹ نہیں: تین گمشدہ حصے

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

چلتے ہوئے ٹنل کے پاس باہر جانے کا راستہ کیوں نہیں

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

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

لہٰذا کلائنٹ نہیں، تین تہوں کی جانچ کریں، اور نتیجے کا مطلب ہونے کے لیے ایک وقت میں ایک ہی بدلیں۔

فارورڈنگ ایک کرنل سوئچ ہے جسے مستقل بنانا ہوتا ہے

تبدیلی سے پہلے موجودہ قدر دیکھیں، پھر اسے مقرر کریں اور تصدیق کریں کہ تبدیلی نافذ ہوئی۔

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

اسے /etc/sysctl.d/ کے تحت فائل میں مستقل کریں، پھر جاننے کے لیے ری بوٹ کرنے کے بجائے وہی فائل لاگو کریں۔ FreeBSD میں مساوی net.inet.ip.forwarding ہے، اور دوام کے لیے rc.conf میں gateway_enable=YES۔ جو آلہ فارورڈنگ بند بتاتا ہے وہ «پیکٹ آتے ہیں اور کچھ واپس نہیں آتا» جیسی پوری قسم کی رپورٹوں کی وضاحت کرتا ہے۔ ہر اپ گریڈ کے بعد بھی ترتیب دیکھیں، کیونکہ دوبارہ بنایا گیا کرنل یا بدلی گئی ڈیوائس امیج کسی کو بتائے بغیر اسے ری سیٹ کر سکتی ہے۔

masquerade یا ایک مقررہ ترجمہ پتہ منتخب کریں

متحرک بیرونی پتے کے ساتھ masquerading سب سے سادہ درست شکل ہے۔ ٹنل سب نیٹ کو ماخذ اور بیرونی انٹرفیس کو اخراج کا نام دیں۔

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

مستقل عوامی پتے کے ساتھ ماخذ کا ترجمہ ٹھیک اسی پتے پر زیادہ قابل اندازہ اور جانچنا آسان ہے۔

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

فلٹر جدول تیسرا دروازہ ہے

فارورڈنگ اور ترجمہ دونوں درست ہو سکتے ہیں جبکہ پیکٹ پھر بھی فلٹر جدول میں مرتا ہے۔ ufw اکثر مجرم ہوتا ہے: اس کی فارورڈ پالیسی DROP کے طور پر آتی ہے، اور باقی ترتیب بالکل درست دکھ سکتی ہے جبکہ وہی ایک ترتیب ٹریفک کو مار دیتی ہے۔ اسے اوپر اٹھانا چیک باکس نہیں، سوچا سمجھا حفاظتی فیصلہ ہے۔

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

پل والے ٹنل کو مختلف جواب چاہیے۔ پتہ جسمانی پورٹ کا نہیں، پل کا ہے، اس لیے انٹرفیس کو غلام بنانا اس کا پہلے والا پتہ ہٹا دیتا ہے اور میزبان اس وقت تک ناقابل رسائی دکھتا ہے جب تک پل خود ایک پتہ نہ پا لے، جو dhclient br0 دے سکتا ہے۔ وہ ناکامی VPN مسئلہ لگتی ہے اور دراصل دوسری تہہ کا مسئلہ ہے۔ فائر وال کو چھونے سے پہلے پل کا اپنا پتہ دیکھیں، کیونکہ فلٹر تبدیلی اس میزبان کو ٹھیک نہیں کر سکتی جس کے پاس بھیجنے کا پتہ ہی نہیں۔

صفحہ کبھی لوڈ نہ ہو تو کہاں دیکھیں

ٹنل کی موجودگی ثابت کرنے کے لیے سرور کے ٹنل پتے پر ping کریں۔ پھر کلائنٹ سے عوامی پتے تک traceroute چلائیں اور پڑھیں کہ کہاں رکتا ہے: سرور پر پیکٹ پہنچتا ہے مگر فارورڈ یا ترجمہ نہیں ہوتا؛ سرور کے پار مسئلہ اوپر ہے اور آپ کے ہاتھ میں نہیں۔

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

پہلا حکم ثابت کرتا ہے کہ ٹنل ٹریفک کو سرور تک ہی لے جاتا ہے، اور دوسرا دکھاتا ہے کہ پیکٹ باہر کتنی دور جاتا ہے۔ ٹنل پتے پر ختم ہونے والا نشان سرور پر فارورڈنگ یا ترجمے کی طرف اشارہ کرتا ہے، جبکہ ایک ہاپ بعد رکنے والا نشان فراہم کنندہ یا اوپری راؤٹر کے واپسی راستے کی طرف۔

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

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