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 पासवर्ड नहीं। पाँचवीं सीमा सफल लॉगिन के बाद अनुमति है। प्रमाणित उपयोगकर्ता को अभी भी शेल, कमांड, सबसिस्टम या फ़ॉरवर्डिंग से मना किया जा सकता है, और ये अस्वीकृतियाँ केवल क्लाइंट की अंतिम पंक्ति पढ़ने वाले को विफलता जैसी लगती हैं।

कुछ असफल पासवर्ड प्रयासों के बाद रुकें। बार-बार अनुमान लगाने से लॉकआउट बनते हैं जो फिर दूसरी, असंबंधित खराबी जैसे दिखते हैं और मूल टिकट से अधिक समय लेते हैं।

रोलबैक और वह रिकॉर्ड जो आप रखते हैं

एक बार में एक चीज़ बदलें, और दोबारा परीक्षण से पहले लिखें कि आपने क्या बदला। यदि कोई बदलाव प्रयास को बदतर बनाता है, तो ऊपर एक और सुधार ढेर करने के बजाय उसे तुरंत वापस लें। मूल क्लाइंट और संदर्भ से मूल कार्रवाई दोहराएँ। दूसरी मशीन से, दूसरे पता परिवार में सफल लॉगिन पुनरुत्पादन नहीं है और सुधार सिद्ध नहीं करता।

जो साझा करते हैं उसे साफ़ करें। विस्तृत क्लाइंट आउटपुट आंतरिक नाम, खाता लेबल, कुंजी पथ और सार्वजनिक कुंजी पहचानकर्ता ले जा सकता है, इसलिए कच्चे ट्रेस के बजाय चरणबद्ध निष्कर्ष प्रकाशित करें।