بوٹ پر SoftEther کلائنٹ: AccountStartupSet اور ڈیمون کی ترتیب

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

تصدیق کریں کہ اکاؤنٹ خودکار آغاز کے لیے نشان زد ہے

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

cd /opt/softether/vpnclient
./vpncmd

VPN کلائنٹ کے انتظام کے لیے 2 منتخب کریں اور Enter دبا کر مقامی سرور قبول کریں۔

AccountStartupSet
office-hub
exit

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

تصدیق کریں کہ سروس شروع ہوتی ہے، اور کافی جلدی

Linux پر کلائنٹ اپنی ہی ڈائریکٹری سے ڈیمون کے طور پر چلتا ہے، اور بوٹ کا کوئی بھی مرحلہ اکاؤنٹ استعمال کرنے سے پہلے اسے چل رہا ہونا چاہیے۔ ڈائریکٹری بدل کر اسے شروع کرنے والا مختصر ہک ان نظاموں میں کافی ہے جو اب بھی rc.local چلاتے ہیں۔

cd /opt/softether/vpnclient
./vpnclient start

جہاں rc.local نہیں ہے، وہاں واضح WorkingDirectory اور دوبارہ شروع کرنے کی پالیسی کے ساتھ systemd یونٹ لکھیں۔ بائنری اپنی ترتیب اس جگہ کے حوالے سے حل کرتی ہے جہاں سے شروع کی جاتی ہے، اس لیے اس ترتیب کے بغیر یونٹ کامیابی سے شروع ہو کر کچھ بھی نہیں پڑھ سکتا۔ ترتیب مسئلے کا دوسرا نصف ہے: ڈیمون کے سننا شروع کرنے سے پہلے چلنے والی کنکشن کی کوشش وقفے وقفے سے ناکام ہوتی ہے، جس کی تشخیص مسلسل ناکامی سے کہیں زیادہ مشکل ہے۔ دوبارہ شروع کرنے کی پالیسی تیسری صورت کو ڈھکتی ہے، جہاں ڈیمون گھنٹوں بعد خاموشی سے مر جاتا ہے۔

پچھلے بوٹ کی چھوڑی ہوئی pid فائل پر بھروسہ کرنے کے بجائے پروسیسوں کی فہرست جانچیں۔

تصدیق کریں کہ اڈاپٹر کو پتہ ملا ہے

اکاؤنٹ جڑتے ہی کلائنٹ ایک مجازی اڈاپٹر پیش کرتا ہے اور اڈاپٹر کو اب بھی پتے کی ضرورت ہے۔ SecureNAT چلانے والا حب عام طور پر DHCP کا جواب دیتا ہے؛ طبیعی LAN سے پل بندھا حب اس کے بجائے اسی LAN کے سرور کے جواب دینے کی توقع رکھتا ہے۔

ip -brief address
dhclient vpn_vpn1

فہرست سے انٹرفیس کا نام لیں، کیونکہ مثال میں دیا گیا عدد مستقل نہیں ہے۔ اگر پتہ مستقل ہونا چاہیے تو اسے اسی انٹرفیس کے لیے تقسیم کی نیٹ ورک ترتیب میں رکھیں، تاکہ لنک کے واقعے کے بعد یہ دوبارہ لاگو ہو اور صرف بوٹ پر ہی نہ ہو۔ ایک بار چلنے والی اسکرپٹ دن میں ٹنل کے پہلی بار دوبارہ جڑنے پر اڈاپٹر کو بغیر پتے کے چھوڑ دیتی ہے۔ اکاؤنٹ ٹھیک ہونے کے باوجود وہ ناکامی مردہ ٹنل جیسی دکھتی ہے۔

بغیر پتے کا اڈاپٹر فہرست میں سب سے خاموش ناکامی ہے، کیونکہ اکاؤنٹ اب بھی جڑا ہونے کی اطلاع دیتا ہے۔

تصدیق کریں کہ راستہ وہیں جا رہا ہے جہاں آپ سوچتے ہیں

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

ip route get 10.10.20.15

حب کی حد سے متجاوز مقامی سب نیٹ جیت جاتا ہے، کیونکہ اس کا راستہ زیادہ مخصوص ہے اور پہلے سے نصب ہے۔

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

چاروں جانچیں دوبارہ تعمیر کے نوٹس میں لکھیں

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

جھنڈا دوبارہ لاگو کرنے کی ایک سطر ہے اور اسے بھولنا آسان ہے۔

ترتیب برقرار رکھیں: جھنڈا، سروس، پتہ، راستہ۔ درمیان سے شروع ہونے والی چیک لسٹ بہت سے پراعتماد غلط جوابات پیدا کرتی ہے۔