Windows VPN کو کام میں پاس ورڈ رکھے بغیر دوبارہ جوڑیں

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

کام کا عمل کیا پڑھنے کے قابل چھوڑتا ہے

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

schtasks /query /tn "VPN Reconnect" /xml
cmdkey /list

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

محفوظ شدہ پہلے سے مشترکہ کلید واقعی کیا دیتی ہے

Add-VpnConnection -L2tpPsk کلید کو کام میں نہیں بلکہ کنکشن کی فون بک اندراج میں لکھتا ہے۔ یہ کام کے عمل سے چھوٹی نمائش کی سطح ہے۔ یہ اب بھی قابل بازیافت راز ہے، کیونکہ مشین پر منتظم فون بک پڑھ سکتا ہے۔

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

Winlogon اسناد راز ختم کرتی ہیں اور انحصار شامل کرتی ہیں

-UseWinlogonCredential مختلف راستہ اختیار کرتا ہے۔ کنکشن تصدیق کرتا ہے MSCHAPv2 کے ساتھ لاگ ان صارف کی اسناد کے خلاف۔ اس اکاؤنٹ کے لیے اضافی کچھ محفوظ نہیں ہوتا۔

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

سرٹیفکیٹ تصدیق پھیلتی ہے کیونکہ کچھ محفوظ نہیں ہوتا

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

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

اگلی گردش سے پہلے نوادرات کا جائزہ لیں

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

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