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 पासवर्ड होइन। पाँचौं सीमा सफल लगइनपछिको अधिकार हो। प्रमाणित प्रयोगकर्तालाई पनि शेल, आदेश, उपप्रणाली वा फर्वार्डिङ अस्वीकार गर्न सकिन्छ, र क्लाइन्टको अन्तिम लाइन मात्र पढ्नेलाई ती अस्वीकृतिहरू खराबीजस्ता देखिन्छन्।

केही असफल पासवर्ड प्रयासपछि रोक्नुहोस्। दोहोरिएका अनुमानले लकआउट बनाउँछन्, जो पछि दोस्रो, असम्बन्धित खराबीजस्ता देखिन्छन् र मूल टिकटभन्दा बढी समय लिन्छन्।

रोलब्याक र तपाईंले राख्ने रेकर्ड

एक पटकमा एउटा कुरा बदल्नुहोस्, र फेरि परीक्षण गर्नुअघि के बदल्नुभयो लेख्नुहोस्। यदि परिवर्तनले प्रयास बिगार्छ भने माथि अर्को सुधार थुपार्नुको सट्टा तुरुन्तै फर्काउनुहोस्। मूल क्लाइन्ट र सन्दर्भबाट मूल कार्य दोहोर्याउनुहोस्। अर्को मेसिनबाट, अर्को ठेगाना परिवारमा सफल लगइन पुनरुत्पादन होइन र सुधार प्रमाणित गर्दैन।

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