Ping चालते पण VPN वर SSH अयशस्वी: कोणता टप्पा तुटला?
एक तपशीलवार प्रयत्न TCP पोहोच, 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 पासवर्ड नाही. पाचवी सीमा यशस्वी लॉगिननंतरची अधिकृती आहे. प्रमाणित वापरकर्त्यालाही शेल, आदेश, उपप्रणाली किंवा फॉरवर्डिंग नाकारले जाऊ शकते, आणि क्लायंटची शेवटची ओळच वाचणाऱ्याला ते नकार बिघाडांसारखे दिसतात.
| Last stage reached | What it proves | Where to look next |
|---|---|---|
| No TCP connection | No SSH transport exists | Address, port, route, selectors, filter, listener |
| TCP up, exchange incomplete | Reachability is not the blocker | Server response, negotiation, packet handling |
| Host identity rejected | The peer is not the expected host | Independently verified host key |
| User authentication rejected | The attempt reached authentication | Account, credential and server policy |
| Authenticated, session denied | Login succeeded, the operation did not | Shell, command or forwarding permission |
काही अयशस्वी पासवर्ड प्रयत्नांनंतर थांबा. वारंवार अंदाज लॉकआउट तयार करतात, जे नंतर दुसऱ्या, असंबंधित बिघाडासारखे दिसतात आणि मूळ तिकिटापेक्षा जास्त वेळ घेतात.
रोलबॅक आणि तुम्ही ठेवता ती नोंद
एकावेळी एक गोष्ट बदला, आणि पुन्हा चाचणी करण्यापूर्वी काय बदलले ते लिहा. बदलामुळे प्रयत्न बिघडल्यास वर आणखी एक दुरुस्ती थर न देता लगेच तो परत करा. मूळ क्लायंट आणि संदर्भातून मूळ क्रिया पुन्हा करा. दुसऱ्या मशीनवरून, दुसऱ्या पत्ता कुटुंबात यशस्वी लॉगिन हे पुनरुत्पादन नाही आणि दुरुस्ती सिद्ध करत नाही.
तुम्ही सामायिक करता ते स्वच्छ करा. तपशीलवार क्लायंट आउटपुटमध्ये अंतर्गत नावे, खाते लेबल, की मार्ग आणि सार्वजनिक की ओळखकर्ते असू शकतात, म्हणून कच्च्या ट्रेसऐवजी टप्प्याटप्प्याने निष्कर्ष प्रकाशित करा.