FortiClient مکمل ٹنل: صرف دفتر کا ذیلی نیٹ ورک روٹ کریں
VPN ایک ڈیفالٹ روٹ انسٹال کرتا ہے اور مقامی نیٹ ورک غائب ہو جاتا ہے۔ جدول پڑھیں، LAN کا ڈیفالٹ روٹ بحال کریں، دفتر کے سابقے شامل کریں، پھر DNS درست کریں۔
ٹنل اوپر آتا ہے، آئیکن سبز ہوتا ہے اور مقامی نیٹ ورک غائب ہو جاتا ہے: پرنٹرز، NAS اور دفتر کا راؤٹر سب جواب دینا بند کر دیتے ہیں۔ FortiClient وہی کر رہا ہے جو پروفائل نے مانگا تھا۔ گیٹ وے نے ڈیفالٹ روٹ بھیجا، کلائنٹ نے اسے انسٹال کیا، اور اب ہر پیکٹ کا ٹنل میں جانے کا راستہ ہے۔ مرمت روٹ ٹیبل کی ترمیم ہے اور اس کے پیچھے DNS کی ترمیم، اور ان ترامیم کی ترتیب ہی طے کرتی ہے کہ مشین بہتر رہے گی یا بدتر۔
کلائنٹ نے کیا انسٹال کیا، اور LAN کیوں غائب ہوا
کلائنٹ انٹرفیس کے بجائے جدول پڑھ کر شروع کریں۔ macOS پر netstat -rn پورا جدول چھاپتا ہے اور route -n get default اس انٹرفیس اور میٹرک کا نام بتاتا ہے جو اس وقت جیت رہے ہیں؛ Linux پر جوڑی ip route show اور ip route get 8.8.8.8 ہے۔ دونوں ایک ہی سوال کا جواب دیتے ہیں: کون سا اندراج اس پیکٹ کو لے جائے گا جو کسی زیادہ مخصوص چیز سے نہیں ملتا۔
ٹنل ڈیوائس کا نام مقرر نہیں ہے۔ macOS پر IKEv2 پروفائل عام طور پر نمبر کے ساتھ utun دکھاتا ہے، SSL VPN کلائنٹ ppp0 دکھاتا ہے، اور OpenVPN tun0 دکھاتا ہے۔ مختلف میٹرک کے ساتھ دو ڈیفالٹ ایک ہی وقت میں بھی ہو سکتے ہیں، اور کلائنٹ کا اندراج شاید نظر آنے کے لمحے نہیں بلکہ دوبارہ جڑنے کے بعد ہی کنٹرول لے۔ اسی لیے پانچ منٹ کے وقفے سے لیے گئے دو ٹیبل ڈمپ مختلف کہانیاں سنا سکتے ہیں۔
ٹنل کا ڈیفالٹ روٹ پہلے کیوں جانا چاہیے
کرنل سب سے لمبا مماثل سابقہ چنتا ہے، اور جب کئی روٹ یکساں طور پر مخصوص ہوں تو سب سے کم میٹرک والا چنتا ہے۔ اس لیے 0.0.0.0/0 بہتر میٹرک کے ساتھ انسٹال کرنے والا کلائنٹ اصل ڈیفالٹ کو حذف کیے بغیر ہر منزل جیت لیتا ہے، اور اسی لیے طبعی روٹ اب بھی جدول میں ہے اور اب بھی رکاوٹ کی وضاحت کرتا ہے۔ ٹنل کا ڈیفالٹ روٹ پہلے ہٹانے سے پچھلا رویہ بحال ہوتا ہے۔ اسی کے بعد ٹنل سے گزرنے والا سابقہ روٹ وہ کرتا ہے جو مصنف کا مقصد تھا۔
اس مرحلے سے پہلے سابقے شامل کرنا وہ غلطی ہے جو آدھی چلنے والی مشین بناتی ہے۔ نئے سابقے کی ٹریفک ٹنل کی پیروی کرتی ہے، اور فہرست میں نہ ہونے والی ہر چیز بھی ٹنل کے ڈیفالٹ کی پیروی کرتی ہے، اس لیے کوئی چیز ٹوٹی ہوئی نظر نہیں آتی جب تک کوئی ایسی خدمت نہ کھولے جو کسی نے شامل نہ کی ہو۔ حذف کریں، بحال کریں، پھر شامل کریں، اور درمیانی حالت قابلِ اندازہ رہتی ہے۔
macOS اور Linux پر ترتیب
macOS پر یہ ترتیب ٹنل کا ڈیفالٹ روٹ حذف کرتی ہے، طبعی ڈیفالٹ بحال کرتی ہے اور ایک دفتری سابقہ واپس ٹنل میں بھیجتی ہے۔ یہاں دیے گئے مثال کے انٹرفیس نام اپنے جدول والے ناموں سے بدل دیں۔
sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4Linux پر یہی ترتیب دوسرا اوزار استعمال کرتی ہے: ڈیفالٹ کے لیے LAN گیٹ وے اور دفتری سابقے کے لیے ٹنل ڈیوائس۔ پرانا route کمانڈ اب بھی پرانا نحو قبول کرتا ہے، لیکن ip route وہ شکل ہے جو موجودہ دستاویزات سے میل کھاتی ہے۔
sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0جب روٹ کو ڈیوائس کے بجائے اگلی چھلانگ درکار ہو، تو کلائنٹ آؤٹ پٹ سے peer لیں۔ اندازہ دو غلطیوں میں سے ایک دیتا ہے، اور ان کا مطلب مختلف ہے: غلط گیٹ وے فوراً network unreachable دیتا ہے، جبکہ غلط ٹنل ہدف وقت ختم ہونے کی غلطی دیتا ہے۔ کمانڈ دوبارہ بدلنے سے پہلے پڑھیں کہ کون سی ملی۔
سابقے، حل کنندہ اور اندھیرے میں رہنے والا DMZ
ایک سابقہ شاذ و نادر ہی پورا کام ڈھکتا ہے۔ ایپلیکیشن سرورز، انتظامی نیٹ ورک، DMZ اور خود DNS سرورز ہر ایک مختلف حد میں ہو سکتے ہیں، اس لیے شروع کرنے سے پہلے ہر وہ حد درج کریں جس کا نام آپ بتا سکتے ہیں اور ہر ping کے ساتھ ایک تلاش آزمائیں۔ آزمائش کے درمیان دریافت ہونے والی منزل ہی وہ ہوتی ہے جو تبدیلی کے ریکارڈ میں بھول جاتی ہے۔ جو روٹ پتے سے جواب دیتا ہے مگر نام سے ناکام ہوتا ہے وہ عام طور پر روٹنگ کا لباس پہنے حل کنندہ کا مسئلہ ہوتا ہے۔
حل کنندہ ایک الگ فیصلہ ہے۔ جب پروفائل نے اندرونی DNS سرورز بھیجے ہوں، تو ڈیفالٹ ہٹانے سے وہ پتے عوامی ناموں کے لیے ناقابلِ رسائی رہ سکتے ہیں یا صرف ٹنل سے قابلِ رسائی ہو سکتے ہیں، اور دونوں حالتیں الجھے ہوئے جزوی نتائج دیتی ہیں۔ حل کنندہ کے پتوں کو ٹنل سے روٹ کریں، یا فی ڈومین حل ترتیب دیں تاکہ عوامی تلاشیں مقامی حل کنندہ استعمال کریں۔
Linux SSL کلائنٹ میں ایک شعبے سے متعلق ناکامی ہے جو جاننے کے قابل ہے: ٹنل جڑتا ہے، دفتر کا LAN جواب دیتا ہے، اور ایک DMZ حد اندھیرے میں رہ جاتی ہے۔ غائب ٹکڑا اس حد کے لیے ٹنل گیٹ وے سے گزرنے والا روٹ ہے، اور گیٹ وے مشین بہ مشین مختلف ہوتا ہے، اس لیے سخت کوڈ شدہ پتہ ہی وہ طریقہ ہے جس سے اگلا لیپ ٹاپ خراب ہوتا ہے۔ اسے کلائنٹ کی حالت سے نکالیں اور کمانڈ کو خود دستاویزی رکھیں:
PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"چلانے سے پہلے دونوں قدریں پڑھیں۔ peer نقطہ سے نقطہ ٹنل کا دور کا سرا ہے، اور یہی وہ پتہ ہے جو DMZ روٹ کو درکار ہے؛ روٹ شدہ ٹنل میں اس کا متبادل وہ انٹرفیس یا گیٹ وے ہے جو کلائنٹ بتاتا ہے۔ اگر دونوں میں سے کوئی نظر نہ آئے تو کلائنٹ اس موڈ میں نہیں جو آپ نے فرض کیا۔
اگلے کنکشن کے بعد، اور یہ مقامی طور پر کب بند کرنا ہے
FortiClient نیند یا نیٹ ورک کی تبدیلی کے بعد دوبارہ جڑتا ہے اور پروفائل جو بتاتا ہے وہ دوبارہ انسٹال کرتا ہے۔ اس لیے دستی روٹ اگلے کنکشن تک ہی رہتے ہیں، اور یہی وہ وقفہ ہے جس میں ایک کامیاب آزمائش مرمت جیسی لگ سکتی ہے۔ راتوں رات غائب ہونے والا روٹ متوقع رویہ ہے، نئی خرابی نہیں۔
دو پائیدار جواب ہیں۔ ہر کنکشن کے بعد درستی دوبارہ چلانے والی اسکرپٹ ایک عارضی حل ہے جو اپنے مصنف سے زیادہ عرصہ چل سکتا ہے، جبکہ گیٹ وے منتظم کی طرف سے تقسیم شدہ ٹنل پروفائل ہی اصل مرمت ہے، کیونکہ پھر کلائنٹ صرف وہی حدود انسٹال کرتا ہے جو کام کو درکار ہیں۔ دوسرا مانگیں اور پہلا صرف انتظار کے دوران استعمال کریں۔ مقامی طور پر مکمل ٹنل تقسیم کرنے سے پہلے وہ پالیسی بھی دیکھیں جس پر آپ متفق ہوئے، کیونکہ دور دراز نیٹ ورک آپ کی پوری ٹریفک دیکھنے پر انحصار کر سکتا ہے۔
جانچ کی فہرست مختصر ہے: جدول پڑھیں، ٹنل کا ڈیفالٹ روٹ حذف کریں، LAN کا ڈیفالٹ روٹ بحال کریں، ہر سابقہ شامل کریں، حل کو الگ سے درست کریں، اور توقع کریں کہ دوبارہ جڑنے پر روٹ واپس آئیں گے۔