درست ایک بار استعمال ہونے والا کوڈ بھی VPN لاگ ان میں کیوں ناکام ہوتا ہے

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

پرامپٹ کی ترتیب بتاتی ہے کہ آپ کس بہاؤ میں ہیں

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

غلط شکل برے کوڈ جیسی دکھتی ہے۔ صرف پاس ورڈ کے لیے بنائی گئی فیلڈ میں نیا کوڈ چسپاں کریں، سرور اسے پاس ورڈ کا حصہ سمجھ کر پڑھے گا۔ کلائنٹ کی طرف، OpenVPN 2.4 اور بعد کے ورژن فرق کو نمایاں کرتے ہیں: جو سرور AUTH_FAILED,CRV1: کے ساتھ جواب دیتا ہے وہ چیلنج جواب کی توقع کرتا ہے، اس لیے پروفائل کو static-challenge یا SCRV1: شکل کی پاس ورڈ فائل درکار ہے۔ صرف auth-user-pass والا پرانا پروفائل پاس ورڈ کی تصدیق کر کے رک جاتا ہے، جو لاگ میں OTP ناکامی جیسا لگتا ہے حالانکہ کوئی کوڈ نہیں بھیجا گیا۔

WireGuard کو استثنا کے طور پر ذکر کرنا چاہیے: یہ لوگوں کی نہیں بلکہ کلیدوں کے جوڑوں کی تصدیق کرتا ہے، اس لیے کوڈ کے لیے کوئی فیلڈ نہیں۔ اگر کوئی فراہم کنندہ ایسا اعلان کرے، تو سرنگ سے باہر کوئی چیز اسے قبول کر رہی ہے۔

سرور چھ ہندسوں کے ساتھ کیا کرتا ہے

وقت پر مبنی کوڈ RFC 6238 کی پیروی کرتے ہیں، جو RFC 4226 کی پرانی گنتی پر مبنی ساخت کو لپیٹتا ہے: متحرک عنصر پر HMAC، بطور ڈیفالٹ چھ ہندسوں میں کاٹا گیا۔ TOTP میں متحرک عنصر موجودہ Unix وقت ہے جو ایک قدم پر تقسیم کیا گیا، 30 سیکنڈ جب تک آپریٹر نے اسے نہ بدلا ہو۔ تصدیق کرنے والا کبھی آپ کے ہندسوں کا محفوظ قدر سے موازنہ نہیں کرتا؛ وہ مشترکہ بیج سے متوقع کوڈ دوبارہ شمار کرتا ہے اور عام طور پر ہمسایہ قدم بھی قبول کرتا ہے، اس لیے سست چکر لاگ ان ناکام نہیں کرتا۔

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

گنتی پر مبنی ٹوکن ہر دباؤ پر اپنی گنتی آگے بڑھاتے ہیں، اس لیے کوڈ بننے کے بعد کبھی نہ بھیجے جانے پر وہ ہم آہنگی سے باہر ہو جاتے ہیں؛ عام حل دوبارہ ہم آہنگی کی ونڈو ہے جو آگے کے چند قدر قبول کرتی ہے۔ اگر آپریٹر نے HOTP رجسٹر کیا ہو اور آپ کی ایپ TOTP دکھائے، تو ہر قدر غلط ہے اس انداز میں جو گھڑی کے مسئلے جیسا لگتا ہے۔ QR کوڈ کے پیچھے پروویژننگ URI قسم، ہندسے، مدت اور ہیش بتاتا ہے۔

غلط کوڈ جیسی دکھنے والی ناکامیاں

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

دوسرا، ناملتا ہوا پیرامیٹر سیٹ۔ آٹھ ہندسوں، 60 سیکنڈ کی مدت یا SHA-256 کے ساتھ رجسٹرڈ بیج ایسے کوڈ دیتا ہے جنہیں چھ ہندسے، 30 سیکنڈ اور SHA-1 کی توقع کرنے والا تصدیق کار مسترد کرتا ہے، اور کلائنٹ پر اسے غلط کوڈ سے الگ نہیں پہچانا جا سکتا۔ یہ ان ہجرتوں کے بعد ظاہر ہوتا ہے جہاں QR کوڈ کی تصویر سے اندراج دوبارہ شامل کیا گیا، یا ٹوکن ریکارڈ ڈیفالٹ اقدار کے ساتھ دوبارہ بنایا گیا۔

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

اسے تنگ کرنے والا مختصر سلسلہ

سب سے سستی جانچ سے شروع کریں اور جس پہلے مرحلے پر بات نہ بنے وہیں رک جائیں۔

1. نئے کوڈ کا انتظار کریں، اسے ایک بار بھیجیں، اور نوٹ کریں کہ چیلنج پاس ورڈ قبول ہونے سے پہلے آتا ہے یا بعد میں۔
2. تصدیق کنندہ کا لیبل سرور کے محفوظ کردہ صارف نام سے ملائیں۔
3. یقینی بنائیں کہ پروفائل چیلنج کا جواب دے ہی سکتا ہے، اوپر والے CRV1 معاملے کی طرح۔
4. آلے کی گھڑی کا موازنہ کسی معلوم وقت کے ماخذ سے کریں؛ چند درجن سیکنڈ سے زیادہ انحراف TOTP کو خود ہی توڑ دیتا ہے۔
5. آپریٹر سے پوچھیں کہ ٹوکن TOTP ہے یا HOTP، اور کون سے ہندسے، مدت اور ہیش رجسٹر ہوئے۔

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

بیج اور بازیابی کوڈ گردش سے باہر رکھیں

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

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

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