دوسرا VPN ٹنل پہلے کو کیوں توڑ دیتا ہے؟

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

علامت: دوسرا کلائنٹ خاموشی سے جیت جاتا ہے

OpenVPN: آپشن redirect-gateway def1 راستے 0.0.0.0/0 کو دوبارہ نہیں لکھتا۔ یہ 0.0.0.0/1 اور 128.0.0.0/1 شامل کرتا ہے: دونوں مل کر ہر IPv4 پتے کو ڈھانپتے ہیں، اور ہر سابقہ لمبائی میں عام ڈیفالٹ کو ہرا دیتا ہے۔ اصل ڈیفالٹ ٹیبل میں رہتا ہے اور عام ٹریفک کے لیے استعمال ہونا بند ہو جاتا ہے، اور VPN سرور تک ہوسٹ راستہ ٹنل کو اس کے اپنے بیرونی پیکٹ پکڑنے سے روکتا ہے۔ دونوں کلائنٹ ایسا کرتے ہیں، اور دوسرا صرف اپنی جوڑی بعد میں نصب کرتا ہے۔

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

دوسرے کلائنٹ کے جڑنے سے پہلے اور بعد میں راستوں کا اسنیپ شاٹ لیں۔ ٹیبل میں نظر آنے والے دو نصف راستے ہی پوری تبدیلی ہیں، اور وہ دونوں شکایات کی وضاحت کرتے ہیں۔ علامت ظاہر ہونے کے لیے ٹیبل میں کچھ اور ہلنے کی ضرورت نہیں۔ اسی لیے دوسرا کلائنٹ ہٹانے سے پہلا فوراً بحال ہو جاتا ہے۔

پڑھیں کہ کون سا ٹنل واقعی جیتتا ہے

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

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

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

نتیجہ درج کریں، انٹرفیس کا نام اور ملنے والا سابقہ شامل کرتے ہوئے۔ جو ٹکٹ کہتا ہے کہ دوسرے VPN نے پہلا توڑا، وہ علامت کی وضاحت ہے، ایسا راستہ بیان نہیں جس پر کوئی عمل کر سکے۔ تلاش اسے ایسی حقیقت میں بدل دیتی ہے جسے اگلا انجینئر ایک حکم میں دہرا سکے۔

ونڈوز: ایک پروفائل کو ڈیفالٹ کا مالک بننے سے روکیں

ونڈوز محفوظ پروفائلز رکھتا ہے، اور بلٹ اِن کلائنٹ ایک کو دوسرے پر منحصر ہونے دیتا ہے تاکہ دوسرا ڈائل کرنے پر پہلا خود بخود اوپر آ جائے۔ جو پروفائل سب سے آخر میں جڑا وہ ڈیفالٹ رکھنے کا رجحان رکھتا ہے، اس لیے عملی مالک پہلا نہیں بلکہ آخری ڈائل ہے۔ ہر پروفائل کو اپنے push راستے دیں اور جسے ڈیفالٹ نہیں ہونا چاہیے اس کے لیے split tunneling چالو کریں۔

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling اسے بدلتا ہے: ٹیبل میں صرف وہ سابقے آتے ہیں جو سرور push کرتا ہے، جس سے ڈیفالٹ پہلے ٹنل کے پاس رہتا ہے۔ اگر دونوں سرور ڈیفالٹ راستہ push کریں تو ڈیزائن پھر بھی ناکام ہوتا ہے، کیونکہ تب آخری کنکشن جیتتا ہے اور کلائنٹ کی طرف کوئی ترتیب اسے نہیں بدلتی۔ سرور کی طرف push درست کریں یا ایک مالک مان لیں۔

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

لینکس: دوسرے ٹنل کو مرکزی ٹیبل سے باہر رکھیں

ایک مشین پر openvpn --config کی دو مثالیں چلانے سے دونوں کلائنٹ ایک ہی ٹیبل میں آ جاتے ہیں، اور تین اختیارات بڑھتی تنہائی کے ساتھ انہیں الگ کرتے ہیں۔ سب سے ہلکا یہ ہے کہ دوسرے کلائنٹ کو ٹیبل میں ترمیم کرنے ہی نہ دیں: واضح راستوں کے ساتھ route-nopull، یا route-up اسکرپٹ جو صرف وہی نصب کرے جو آپ چاہتے ہیں۔ پھر دوسرا ٹنل بالکل وہی سابقے لے کر چلتا ہے جو آپ نام دیتے ہیں اور کچھ نہیں۔ پھر آپ طے کرتے ہیں کہ کون سا سابقہ کہاں جائے بجائے بعد میں دریافت کرنے کے۔

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

نیٹ ورک نام کی جگہیں سب سے بھاری اور سب سے صاف اختیار ہیں۔ دوسرا کلائنٹ ip netns کے اندر شروع کریں، اسے veth جوڑی دیں، اور استعمال کے لیے اس نام کی جگہ میں داخل ہوں۔ مداخلت ختم ہو جاتی ہے کیونکہ ہر نام کی جگہ ایک ٹیبل بانٹنے کے بجائے اپنے ٹیبل رکھتی ہے، جو دونوں ٹنل ہفتوں تک چلانے ہوں تو اضافی ترتیب کے لائق ہے۔

فی ایپلیکیشن، اور زنجیر بنانا الگ مسئلہ

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

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

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