Linux پر Kerio VPN کلائنٹ: ترتیب سے پانچ جانچیں

Linux پر Kerio VPN کلائنٹ انسٹال کرنے کے بعد ڈیسک ٹاپ پر کوئی آئیکن ظاہر نہیں ہوتا اور نجی نیٹ ورک رسائی سے باہر رہتا ہے۔ یہ اس کلائنٹ کی معمول کی شکل ہے، خراب انسٹال نہیں: GFI کی Linux ہدایات کمانڈ لائن سے کنفیگریشن اور سروس اسکرپٹ بیان کرتی ہیں، بغیر کسی GUI کے۔ نیچے دی گئی جانچیں ترتیب سے کریں، کیونکہ ہر ایک الگ تہ ہٹاتی ہے۔ پہلی ناکامی بتاتی ہے کہ کہاں رکنا ہے، اور آگے چھلانگ لگانا عام طور پر ایسا پیکج دوبارہ بنانا ہے جو کبھی مسئلہ نہیں تھا۔

یقینی بنائیں کہ بلڈ مشین سے مطابقت رکھتا ہے

شروع کریں dpkg مشین کیا ہے اور پیکج کس لیے بنایا گیا، یہ دکھاتا ہے۔ عام 64-بٹ سسٹم پر dpkg --print-architecture چھاپتا ہے amd64، اور وینڈر کا صفحہ عام Debian پیکج کے ساتھ amd64 پیکج درج کرتا ہے۔ اصل میں انسٹال کی گئی فائل کے نام میں ریلیز اسٹرنگ پڑھیں، یہ ماننے کے بجائے کہ دونوں مطابقت رکھتے ہیں۔

2013 کا i386 کے لیے بنایا گیا آرکائیو صرف --force-architecture دینے کی وجہ سے 64-بٹ نہیں بنتا۔ زبردستی انسٹال کرنے سے غیر ملکی بائنریاں بستی ہیں، اب بھی چلنے والے لانچر کے پیچھے انحصار کی ناکامی چھپتی ہے، اور ڈیمن غلط لائبریریاں لوڈ کر سکتا ہے۔ اگر آپ کی ریلیز صرف 32-بٹ ہے، تو اسے 32-بٹ ماحول میں چلائیں یا گیٹ وے کے مالک سے نیا بلڈ مانگیں۔

انحصار کی سطر بھی دیکھیں۔ dpkg -s kerio-control-vpnclient | grep -i depends دکھاتا ہے کہ پیکج کیا توقع رکھتا ہے، اور نامکمل ورژن پن یا غائب رن ٹائم لائبریری یہیں ظاہر ہوتی ہے، کلائنٹ لاگ میں نہیں۔

پیکج وزرڈ کے ذریعے اسے کنفیگر کریں

ڈیزائن کے مطابق کلائنٹ کا ایپ ڈراور میں کوئی اندراج نہیں، اس لیے غائب آئیکن کنفیگریشن کی کامیابی کے بارے میں کچھ نہیں کہتا۔ وزرڈ دوبارہ کھولنے کے لیے sudo dpkg-reconfigure kerio-control-vpnclient چلائیں اور اس کے سوالات کے جواب دیں: VPN اینڈ پوائنٹ، اکاؤنٹ کی تفصیلات اور سرور سرٹیفکیٹ کی فنگر پرنٹ۔

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

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

وزرڈ جو فائل لکھتا ہے اسے جانیں

کنفیگریشن یہاں ہے: /etc/kerio-kvc.conf اور یہ اکاؤنٹ اور پن شدہ فنگر پرنٹ دونوں رکھتی ہے۔ اسے خفیہ مواد سمجھیں۔ sudo stat -c '%a %U %G' /etc/kerio-kvc.conf اسے سب کے لیے پڑھنے کے قابل نہیں دکھانا چاہیے۔

مجاز دستی ترمیم کے بعد، نیٹ ورک اسٹیک دوبارہ شروع کرنے کے بجائے فائل کا مالک ڈیمن دوبارہ لوڈ کریں: sudo /etc/init.d/kerio-kvc reload۔ دوبارہ لوڈ کنفیگریشن دوبارہ پڑھتا ہے اور موجودہ سیشن چھوڑ دیتا ہے، اس لیے زندہ کنکشن پر یہ بے اثر عمل نہیں ہے۔

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

زندہ سیشن کو بوٹ رویے سے الگ کریں

سروس اسکرپٹ موجودہ کنکشن کو کنٹرول کرتی ہے: sudo /etc/init.d/kerio-kvc stop ابھی ٹنل ختم کرتا ہے اور start اسے واپس لاتا ہے۔ کوئی بھی کمانڈ یہ طے نہیں کرتی کہ اگلی بوٹ پر کیا ہوگا، اور دور سے منظم مشین پر یہ فرق اہم ہے۔

لنک ہٹانے یا کچھ ماسک کرنے سے پہلے دیکھیں کہ اسٹارٹ اپ کس کا ہے۔ پیکج اپنی init اسکرپٹ انسٹال کر سکتا ہے، unit بنا سکتا ہے، یا دونوں، اور غلط نام غیر فعال کرنے سے ری بوٹ کے بعد کلائنٹ واپس آ جاتا ہے۔ systemctl status kerio-kvc کو پیکج دستاویزات میں استعمال ہونے والے نام سے جانچیں، پھر وہ راستہ غیر فعال کریں جو بوٹ عمل واقعی پڑھتا ہے۔

کنفیگریشن یکساں دکھتی ہے اس لیے OpenVPN unit نہ بدلیں۔ یہ کلائنٹ Kerio گیٹ وے سے اپنے پروٹوکول میں بات کرتا ہے، اس لیے اسی فائل کی طرف اشارہ کرنے والا دوسرا ڈیمن تصدیق نہیں کرے گا، اور اضافی ناکامی ثبوت پڑھنا مشکل بناتی ہے۔ GFI کا Linux کلائنٹ بھی ایک وقت میں صرف ایک VPN کنکشن رکھتا ہے؛ یہ حد کلائنٹ پر لاگو ہے، گیٹ وے کی صارف صلاحیت پر نہیں۔

لاگز پڑھیں، پھر وسیلہ تصدیق کریں

تین فائلیں /var/log/kerio-kvc ڈیمن کی کہانی بیان کرتی ہیں: init.log لائف سائیکل واقعات کے لیے، error.log سنگین ناکامیوں کے لیے اور debug.log تفصیلات کے لیے۔ اپنے سوال کا جواب دینے والا سب سے چھوٹا اقتباس پڑھیں، اور کہیں بھی پیسٹ کرنے سے پہلے اینڈ پوائنٹ اور صارف نام ہٹا دیں۔ init.log میں وزرڈ چلانے کے وقت کے آس پاس خلا ہو تو معلوم ہوتا ہے کہ ڈیمن کبھی دوبارہ شروع نہیں ہوا۔

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

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