LAN راؤٹر اور VPN کلائنٹ: دو آلات، دو روٹ ٹیبل

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

کسی روٹ کو چھونے سے پہلے دو ہاپ کھینچیں

ایک مثال ترتیب لیں: LAN ہوسٹ 192.168.50.0/24 پر، عام راؤٹر 192.168.50.1 پر، ایک مخصوص کلائنٹ 192.168.50.15 پر، اور دور کا LAN 10.60.0.0/24 پر جو صرف اسی ٹنل سے قابل رسائی ہے جو وہ کلائنٹ رکھتا ہے۔ دو نجی حدود میں سے کوئی دوسری سے متجاوز نہیں ہوتی، اور ٹنل کا اپنا پتہ منصوبہ ہے۔

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

مرحلہ 1: راؤٹر کو ٹنل کی طرف نہیں، کلائنٹ کی طرف موڑیں

LAN راؤٹر پر، ایک منزل روٹ شامل کریں جس کا اگلا ہاپ کلائنٹ کا LAN پتہ ہے:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

وہ ریکارڈ کہتا ہے «اسے اس مشین تک پہنچاؤ جو ٹنل بنا سکتی ہے»۔ یہ اس بارے میں کچھ نہیں کہتا کہ ٹنل کیسے بنتا ہے، اور یہ کلائنٹ کے اپنے روٹ کا متبادل نہیں ہے۔ منظم راؤٹر پر مساوی چیز آلے کے مستقل روٹ صفحے میں رہتی ہے؛ Linux راؤٹر پر یہ اس انٹرفیس کی ترتیب میں آتی ہے جو LAN کا مالک ہے، اس شیل میں نہیں جو آپ بند کریں گے۔

دوسرے حکم کا جواب دیکھیں۔ اگر یہ کلائنٹ کو gateway اور LAN انٹرفیس کو device بتاتا ہے، تو پہلا ہاپ درست ہے اور باقی کام دوسری مشین پر ہے۔

مرحلہ 2: کلائنٹ کو ٹنل کی طرف اس کا اپنا روٹ دیں

کلائنٹ اب 10.60.0.0/24 کے لیے پیکٹ وصول کرتا ہے اور اپنا ٹیبل دیکھتا ہے۔ اگر اس کی ٹنل ترتیب نے اس سابقے کے لیے روٹ انسٹال کیا ہے، تو پیکٹ خفیہ رہ کر آگے بڑھتا ہے۔ اگر نہیں، تو پیکٹ عام ڈیفالٹ سے میل کھاتا ہے اور 192.168.50.1 پر واپس جاتا ہے، جو اسے دوبارہ کلائنٹ کی طرف بھیجتا ہے۔

کچھ شامل کرنے سے پہلے دیکھیں:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

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

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

مرحلہ 3: فارورڈنگ کی اجازت دیں اور واپسی کا راستہ چنیں

وصول کرنا اور آگے بھیجنا مختلف اجازتیں ہیں۔ کلائنٹ پر net.ipv4.ip_forward=1 کرنل سطح پر گزر کی اجازت دیتا ہے، اور فائر وال اصول کو یہ اب بھی LAN انٹرفیس اور ٹنل کے درمیان اجازت دینی ہوگی۔ جو اصول کلائنٹ کے اپنے انتظامی صفحے تک رسائی کی اجازت دیتا ہے وہ دور کے LAN تک گزر کی اجازت نہیں دے گا، اور یہ فرق چھوڑ دینا آسان ہے جب وہی ہوسٹ مقامی طور پر ping کا جواب دے۔

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

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

مرحلہ 4: دونوں فیصلوں کو مستقل کریں، پھر اصل راستہ جانچیں

ہر روٹ کا ایک مالک ہوتا ہے، اور مالک وہ ترتیب ہے جو بوٹ پر یا دوبارہ رابطے پر دوبارہ بنتی ہے۔ راؤٹر پر یہ مستقل روٹ اندراج ہو سکتا ہے؛ کلائنٹ پر یہ VPN پروفائل، NetworkManager یا systemd-networkd ہو سکتا ہے۔ ٹنل دوبارہ جوڑ کر اور کلائنٹ ری بوٹ کر کے تصدیق کریں، پھر تبدیلی پر بھروسا کرنے کے بجائے ٹیبل دوبارہ پڑھیں۔

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

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