راؤٹر کا VPN کام کرتا ہے، مگر LAN کلائنٹس کے پاس انٹرنیٹ نہیں

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

LAN میزبان سے ناکامی پڑھیں

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

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

مقامی اور فارورڈ ہونے والی ٹریفک مختلف ہیں

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

واپسی کا راستہ بھی ہونا چاہیے

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

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

کلائنٹ کا DNS بھی اسی جائزے میں آتا ہے۔ راؤٹر کا حل کنندہ جواب دے سکتا ہے جبکہ کسی اور سرور کی طرف اشارہ کردہ کلائنٹ کو کچھ بھی نہیں ملتا۔

ایک اجازت شدہ اور ایک مسترد شدہ بہاؤ کی تصدیق کریں

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

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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