ایک خرابی، تین راز: کون سی VPN اسناد ناکام ہوئیں؟
کلائنٹ ہر مرحلے کے لیے ایک ہی خرابی دکھاتا ہے۔ کسی ایسے پاس ورڈ کو ری سیٹ کرنے سے پہلے جو کسی نے نہیں دیکھا، ایسوسی ایشن، صارف کی تبادلہ اور طریقہ پڑھیں۔
“تصدیق ناکام ہوئی” سرور سرٹیفکیٹ، مشین کی پہلے سے شیئر کی گئی کلید یا صارف کے پاس ورڈ کی طرف اشارہ کر سکتی ہے۔ اس کا مطلب کون سا ہے، یہ پروٹوکول پر منحصر ہے، کیونکہ ہر پروٹوکول رازوں کا مختلف مجموعہ متعین کرتا ہے۔ غلط والا ری سیٹ کریں تو خرابی ویسی ہی رہتی ہے۔ حل یہ ہے کہ کچھ بھی بدلنے سے پہلے طے کریں کہ پروٹوکول کتنے ثبوت مانگتا ہے۔
مخالف سمتوں کی طرف اشارہ کرتے دو ثبوت
سرنگ کو یہ بتانا ہوتا ہے کہ وہ درست گیٹ وے تک پہنچی یا نہیں، اور الگ سے یہ کہ صارف کون ہے۔ گیٹ وے کا ثبوت مشین کی سطح کا ہے: سرور سرٹیفکیٹ، پہلے سے شیئر کی گئی کلید یا مستقل عوامی کلید۔ صارف کا ثبوت شخص کی سطح کا ہے: پاس ورڈ، ٹوکن، کلائنٹ سرٹیفکیٹ، یا کچھ بھی نہیں۔ یہ اعتماد کی مخالف سمتیں ہیں اور مختلف مواد استعمال کرتی ہیں۔
IKEv2 گیٹ وے کا ثبوت IKE_AUTH کے اندر انجام دیتا ہے اور جب EAP استعمال ہو تو صارف کا ثبوت بعد میں الگ تبادلے میں چلاتا ہے۔ IKEv2 کی تفصیل انہیں الگ الگ حصوں کے طور پر رکھتی ہے، جو اس بات کا مضبوط اشارہ ہے کہ جب ایک پیغام دونوں مرحلے ڈھانپے تو کہاں دیکھنا ہے۔
مرحلہ پڑھیں، پیغام نہیں
کوئی بھی مرحلہ ناکام ہو، کلائنٹ ایک ہی خرابی کی سطر دکھاتا ہے، اس لیے سطر بذات خود تقریباً کوئی معلومات نہیں رکھتی۔ معلومات وہ حالت رکھتی ہے جو ہر مرحلے پر دیکھی جا سکتی ہے: ایسوسی ایشن موجود ہے یا نہیں، صارف کا تبادلہ شروع ہوا یا نہیں، اور کلائنٹ نے وہ طریقہ پیش کیا یا نہیں جو گیٹ وے چاہتا تھا۔ جدول مراحل کو پروٹوکول کے نام کے بجائے اسی ترتیب سے رکھتا ہے۔
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
صرف دوسری سطر اس اسناد کے بارے میں ہے جو صارف دوبارہ ٹائپ کر سکتا ہے۔ باقی تین ترتیب کے حقائق ہیں، اور یہی عدم مطابقت سبب ہے کہ ایسی بہت سی رپورٹیں ایسے پاس ورڈ ری سیٹ پر ختم ہوتی ہیں جو کچھ نہیں بدلتا۔ کسی خانے کو چھونے سے پہلے وہ سطر پڑھیں جو آپ کے ثبوت سے میل کھاتی ہے۔
دو راز والا پروٹوکول اپنا پتہ دے دیتا ہے
L2TP over IPsec تعداد کو نظر آنے والا بناتا ہے، کیونکہ دونوں جانچ مختلف عملوں میں ہوتی ہیں۔ IPsec کی تہہ کو پہلے پہلے سے شیئر کی گئی کلید یا سرٹیفکیٹ کے ساتھ اوپر آنا ہوتا ہے، اور اسی کے بعد اس کے اندر کا PPP صارف کے لاگ ان کی کوشش کرتا ہے۔
جب مشین کا راز غلط ہو تو کوئی ایسوسی ایشن نہیں بنتی اور صارف کی اسناد کبھی آزمائی نہیں جاتیں۔ جب مشین کا راز درست اور صارف کا راز غلط ہو تو ایسوسی ایشن موجود رہتی ہے اور سرنگ پہلے ہی کھڑی ہونے کے بعد PPP لاگ ان مسترد کرتا ہے۔ دونوں دو مختلف واقعات سے اسکرین پر ایک ہی پیغام دیتے ہیں۔
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerخالی ایسوسی ایشن فہرست صارف کی تہہ کو فوراً خارج کر دیتی ہے، اس لیے پاس ورڈ سے پہلے اسے دیکھیں۔ بار بار PPP ناکامیوں والی قائم ایسوسی ایشن دوسری سمت، یعنی صارف کی تہہ یا اس کے اندر کے تصدیقی پروٹوکول کی طرف اشارہ کرتی ہے۔ کوئی نتیجہ کلائنٹ کے خرابی متن سے دستیاب نہیں ہوتا۔
صرف پاس ورڈ والی رسائی واقعی کس پر منحصر ہے
L2TP، PPTP، SSTP اور EAP والے IKEv2 کے لیے صرف پاس ورڈ والی رسائی عام ہے۔ WireGuard میں ایسا کوئی اختیار ہی نہیں، کیونکہ اس کے ساتھی صارف نہیں، کلیدیں ہیں۔ OpenVPN کے لیے جواب سرور کی کلائنٹ سرٹیفکیٹ شرط سے آتا ہے: جو گیٹ وے سرٹیفکیٹ اور پاس ورڈ دونوں مانگے، وہ خانے میں کچھ بھی لکھا جائے، صرف پاس ورڈ والے کلائنٹ کو مسترد کرتا رہے گا۔
آپ کو کون سا جزو چاہیے، یہ اسی جواب سے نکلتا ہے۔ IKEv2 کے تحت پاس ورڈ لاگ ان کے لیے EAP بولنے والا کلائنٹ درکار ہے، جبکہ سرٹیفکیٹ لاگ ان کے لیے کلائنٹ کی نجی کلید اور سرور کی زنجیر درکار ہے۔ غلط والا نصب کریں تو ناکامی اسناد کی خرابی کی طرح پڑھی جاتی ہے، حالانکہ تصدیق کا طریقہ ہی غائب ہے۔
ایک چیز بدلیں، پھر دوبارہ جانچیں
پہلے تین حقائق طے کریں: کون سا پروٹوکول چل رہا ہے، یہ کتنے راز متعین کرتا ہے، اور ان میں سے کون سے صارف کے بجائے مشین کے ہیں۔ مشینیں پہلے مرحلے پر ناکام ہوتی ہیں اور لوگ دوسرے پر، اور ان دونوں کو ملانا ہی یہ پورا مسئلہ ہے۔
پھر بالکل ایک چیز بدلیں اور اسی کلائنٹ سے دوبارہ جانچیں۔ یہ نظم الجھانے والی ناکامی کو ایسی درستی میں بدل دیتا ہے جو آپ اگلے شخص کو بتا سکیں، جو کسی ایسے چلنے والے کنکشن سے زیادہ مفید ہے جسے کوئی سمجھا نہیں سکتا۔