VPN راستے میں اگلا ہاپ: گیٹ وے کا مقامی طور پر قابل رسائی ہونا کیوں ضروری ہے

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

یہ رہنما کتاب عام صورت حال کا احاطہ کرتی ہے: 192.168.20.0/24 پر ایک لیپ ٹاپ، LAN پتہ 192.168.20.5 والا VPN گیٹ وے، اور اُس گیٹ وے کے پیچھے 10.70.0.0/24 دور دراز نیٹ ورک۔ نیچے دی گئی تمام ہدایات یہ مانتی ہیں کہ آپ لیپ ٹاپ پر ہیں، الا یہ کہ بصورت دیگر کہا جائے۔

دو پتے، ایک راستہ

مطلوبہ اندراج 10.70.0.0/24 via 192.168.20.5 ہے۔ سابقہ بتاتا ہے کہ پیکٹ کہاں جا رہا ہے؛ via پتہ بتاتا ہے کہ اسے وہاں کون لے جا رہا ہے۔ کرنل ایسا راستہ نصب کرنے سے انکار کرتا ہے جس کے گیٹ وے تک وہ آپ کے بتائے ہوئے انٹرفیس سے نہیں پہنچ سکتا، اور یہی انکار پوری بات ہے: وہ اگلا ہاپ جسے قابل رسائی ہونے کے لیے سرنگ درکار ہے، سرنگ بنانے والا اگلا ہاپ نہیں ہو سکتا۔

اسی لیے پہلی جانچ «گیٹ وے چل رہا ہے» نہیں بلکہ «گیٹ وے اسی لنک پر ہے» ہے۔ لیپ ٹاپ کا اپنا سب نیٹ، اس کا ARP یا پڑوسی اندراج، اور راستے میں موجود انٹرفیس — سب کو متفق ہونا چاہیے۔ جو پتہ صرف 10.70.0.0/24 کے اندر موجود ہے وہ دوسرے راستے کی منزل ہو سکتا ہے، مگر پہلے کا via کبھی نہیں۔

اگلا ہاپ گیٹ وے کو کس بات کا پابند کرتا ہے

لیپ ٹاپ پر راستہ نصب کرنا صرف پہلی حوالگی طے کرتا ہے۔ اس کے بعد گیٹ وے کو اپنا راستہ درکار ہے: فعال فارورڈنگ، 10.70.0.0/24 کے لیے سرنگ کا راستہ، اور کوئی بھی رسائی پالیسی جو طے کرتی ہے کہ کون اسے استعمال کر سکتا ہے۔ Linux پر یہ net.ipv4.ip_forward=1 اور سرنگ کا راستہ ہے؛ اس کے سامنے موجود فائر وال کو ایسا قاعدہ درکار ہے جو فارورڈ ہونے والے بہاؤ کی اجازت دے۔

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

بھیجنے والے ہوسٹ سے تلاش کی تصدیق کریں

کرنل سے پوچھیں کہ وہ کون سا اگلا ہاپ منتخب کرے گا، اور جواب میں موجود انٹرفیس پڑھیں:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

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

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

قابل رسائی ہونے کا ڈھونگ رچانے کے لیے onlink استعمال نہ کریں

onlink کرنل سے کہتا ہے کہ گیٹ وے کی رسائی کی جانچ چھوڑ دے اور پھر بھی وہاں بھیجے۔ یہ راستہ نہیں بناتا، جو پتہ موجود نہیں اس کے لیے ARP حل نہیں کرتا، اور آپ کے Ethernet قطعے پر دور دراز روٹر کو جواب دینے پر مجبور نہیں کرتا۔ یہ اُن گیٹ ویز کے لیے جائز ہے جو جواب دیتے ہیں مگر منسلک سب نیٹ میں نہیں بیٹھتے، اور یہ جال ہے جب اسے اُس غلطی کو خاموش کرنے کے لیے استعمال کیا جائے جس کی آپ نے وضاحت نہیں کی۔

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

نقطہ بہ نقطہ سرنگیں Ethernet نہیں ہیں

سرنگ کا آلہ ARP نہیں کرتا اور اکثر پڑوسیوں کا بامعنی سب نیٹ نہیں ہوتا۔ اس کے راستے اکثر 10.70.0.0/24 dev tun0 جیسے نظر آتے ہیں، کسی via کے بغیر، کیونکہ ساتھی ہی دوسرا واحد سرا ہے۔ اُس جدول میں LAN طرز کا via نقل کرنے سے ایسا راستہ بنتا ہے جسے کرنل مسترد کر سکتا ہے یا، اس سے بدتر، ایسا جو اُس پتے کی طرف اشارہ کرتا ہے جس کا ساتھی کبھی جواب نہیں دیتا۔

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

شامل کریں، تصدیق کریں، واپس لیں

پوری تبدیلی تین ہدایات اور ایک جانچ ہے، اور اسے اسی ترتیب میں لکھا جانا چاہیے:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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