لینکس پر لاگ ان سے پہلے SSTP ناکام ہو رہا ہے؟ رن ٹائم حصے چیک کریں

آپ SSTP پلگ ان انسٹال کرتے ہیں، نیٹ ورک ایڈیٹر میں ریڈیو بٹن نمودار ہوتا ہے، آپ گیٹ وے اور صارف نام بھرتے ہیں، اور پروفائل پاس ورڈ مانگنے سے پہلے ہی عام خرابی کے ساتھ ناکام ہو جاتا ہے۔ اس ترتیب میں کوئی غیر معمولی بات نہیں، اور اس میں کچھ بھی ثابت نہیں کرتا کہ ٹنل سافٹ ویئر انسٹال ہے۔ SSTP کنکشن الگ الگ بھیجے جانے والے حصوں سے جوڑا جاتا ہے: ایک VPN پلگ ان جسے NetworkManager شروع کر سکتا ہے، SSTP کلائنٹ پروگرام جو TLS اور PPP سیشن رکھتا ہے، اس کے نیچے PPP ڈیمن، اور رازوں کا ذخیرہ جسے کنکشن پڑھ سکتا ہے۔

مینو اندراج کیا شامل کرتا ہے اور کیا نہیں

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

پھر کلائنٹ کو PPP درکار ہے، کیونکہ SSTP TLS کنکشن کے اندر PPP سیشن لے کر چلتا ہے۔ pppd کے بغیر ٹنل TLS ہینڈ شیک مکمل کر سکتی ہے اور پھر بھی پہلے کنٹرول فریم پر مر سکتی ہے، جو اسناد کی خرابی جیسا لگتا ہے اور نہیں ہے۔ Debian اور Ubuntu پر حصے network-manager-sstp, sstp-client اور ppp کے طور پر آتے ہیں، اور صرف پہلا انسٹال کرنا سب سے عام وجہ ہے کہ فارم ہر خانہ قبول کرتا ہے مگر کنکشن کبھی مکمل نہیں ہوتا۔

ڈیسک ٹاپ کا انتخاب ایک اور تقسیم جوڑتا ہے۔ Plasma پروفائل plasma-nm کے ذریعے ایڈٹ کرتا ہے، جسے اپنا SSTP جزو درکار ہے اور وہی سروس تفصیل پڑھتا ہے، اس لیے SSTP اندراج کے بغیر ایڈیٹر اور پروفائل بخوبی بنانے والا CLI ٹوٹا ہوا رن ٹائم نہیں، بلکہ ایڈیٹر کا ادھرا حصہ غائب ہونا ہے۔

کچھ بھی دوبارہ انسٹال کرنے سے پہلے پہلا ناکام مرحلہ پڑھیں

ناکام SSTP کوشش مقرر ترتیب میں مراحل سے گزرتی ہے، اور جو مرحلہ ناکام ہوا وہ بتاتا ہے کہ کون سا جزو دیکھنا ہے۔

پلگ ان شروع کرنا پہلا ہے، اور وہاں ناکامی سرور کے بارے میں نہیں بلکہ VPN سروس کے بارے میں پیغام دیتی ہے۔ پھر پورٹ 443 پر TCP کنکشن آتا ہے؛ یہاں انکار یا وقت ختم ہونا رسائی کا مسئلہ ہے، TLS کا نہیں۔ پھر TLS ہینڈ شیک اور سرور کی شناخت کی جانچ، پھر PPP گفت و شنید اور اکاؤنٹ کی تصدیق، اور آخر میں پتہ تقسیم اور راستے۔ پروفائل ایک بار فعال کرتے وقت journalctl -f -u NetworkManager دیکھیں، اور آخری عام سطر کے بجائے پہلی مخصوص سطر پڑھیں۔

یہ ترتیب ایک عام غلط قراءت کی وضاحت کرتی ہے۔ سرٹیفکیٹ کی شکایت کسی بھی اسناد بھیجنے سے پہلے درج ہوتی ہے، اس لیے پاس ورڈ بدلنے سے مدد نہیں مل سکتی؛ PPP تصدیق کا انکار کامیاب ہینڈ شیک کے بعد آتا ہے، اس لیے سرٹیفکیٹ بدلنے سے بھی مدد نہیں ملتی۔ پہلی خرابی اور اس کا مرحلہ رکھیں، پھر علامت نہیں بلکہ تشخیص ملے گی۔

سرٹیفکیٹ پر بھروسہ اور اکاؤنٹ میں لاگ ان دو الگ دروازے ہیں

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

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

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

پروفائل اور رازوں کا مالک ایک ہی رہے

پروفائل بننے کے بعد اسے NetworkManager کے ذریعے فعال کریں اور پیدا ہونے والے راستوں اور حل کنندہ کی تبدیلیوں کی ملکیت اسی منتظم کو دیں۔ NetworkManager پہلے سے کنکشن چلا رہا ہو تو دوسرا خودمختار SSTP کلائنٹ شروع کرنے سے آپ کو دو راستہ سیٹ، دو DNS ترتیبات اور ایک ہی سچ کے ماخذ کے بغیر ڈیبگ سیشن ملتا ہے۔

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

ٹنل، راستے اور حل کنندہ الگ الگ چیک کریں

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

ناکام کوشش کے لیے ہر جزو کا ورژن اور صاف شدہ خرابی متن محفوظ کریں۔ وہ شیئر کریں، پوری پروفائل نہیں، کیونکہ پروفائل میں پہلے سے مشترکہ راز اور آپ کی محفوظ اسناد ہو سکتی ہیں۔

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