VPN کلائنٹ سرور تک پہنچتے ہیں لیکن LAN تک نہیں: کون سا حل؟

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

پہلے معلوم کریں کہ کون سی سمت خراب ہے

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

پہلا سوال: کیا آپ دور دراز LAN کے راؤٹر میں ترمیم کر سکتے ہیں؟

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

وہ اس دن خاموشی سے ناکام ہوتا ہے جب کوئی پول بدل دے۔ قدر ایک بار لکھ لیں اور تینوں جگہوں میں سے کسی ایک میں تبدیلی کو تینوں کی تبدیلی سمجھیں۔

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

دوسرا سوال: کیا LAN کلائنٹ پتے دیکھنا بند کر سکتا ہے؟

جب راؤٹر کسی اور کا ہو تو VPN سرور پر ترجمہ تعاون کا محتاج نہیں۔ LAN کا میزبان سرور کا LAN پتہ دیکھتا ہے، اسے جواب دیتا ہے، اور سرور واپس ترجمہ کر دیتا ہے۔ اسی لیے آلات اور NAT پر مبنی ریموٹ ایکسیس کردار ایسا رویہ رکھتے ہیں۔

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

قیمت انتساب ہے: فی کلائنٹ پتے LAN کے لاگز سے غائب ہو جاتے ہیں۔ LAN کے میزبان پر کوئی بھی اجازت فہرست پھر پول کے بجائے سرور کا نام لے گی۔

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

تیسرا سوال: کیا سرور خود کسی دوسرے ٹنل کا کلائنٹ ہے؟

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

پھر دونوں سمتیں اور دونوں حجم جانچیں

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

پھر حقیقی ڈیٹا منتقل کریں، کیونکہ چھوٹا ping کامیاب ہونا جبکہ بڑی منتقلی رک جائے MTU کی علامت ہے۔ وہ خرابی عین اس وقت ظاہر ہوتی ہے جب آپ روٹ درست کرنے پر خود کو مبارکباد دیتے ہیں۔

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