Ping کام کرتا ہے مگر VPN پر SSH ناکام ہوتا ہے: کون سا مرحلہ ٹوٹا؟

Ping کے جوابات اور مسترد شدہ SSH لاگ ان ایک ہی وقت میں درست ہو سکتے ہیں، اور یہ جوڑی ٹنل کو مورد الزام نہیں ٹھہراتی۔ ایکو جوابات اور پورٹ 22 پر TCP کنکشن مختلف منتخب کنندگان، مختلف پالیسیوں اور اکثر مختلف منزلوں والے مختلف تجربات ہیں۔ ایک دانستہ SSH کوشش ریکارڈ کریں، پھر وہ آخری مرحلہ بتائیں جس تک وہ پہنچی۔ وہ ایک ہی ثبوت درجنوں قیاسی کنفیگریشن تبدیلیوں کی جگہ لیتا ہے۔

ایک کوشش ریکارڈ کریں، بار بار ٹھونکنے کا سیشن نہیں

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

ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]

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

پہلا اور دوسرا مرحلہ: SSH سے پہلے TCP

پہلی حد ساکٹ کی رسائی ہے: ایک پتہ، ایک پورٹ اور ایک راستہ جس پر پیکٹ واقعی چلتا ہے۔ اگر TCP کنکشن کبھی مکمل نہ ہو، اس کے اوپر ابھی کچھ نہیں، اور میزبان کی چابیاں اور اکاؤنٹس غیر متعلق ہیں۔

nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'

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

تیسرا مرحلہ: کس کی چابی نے جواب دیا

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

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

چوتھا اور پانچواں مرحلہ: اکاؤنٹ بمقابلہ اجازت

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

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

واپسی اور وہ ریکارڈ جو آپ رکھتے ہیں

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

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