VPN पर रिमोट SSH: सुरंग क्या नहीं करती
VPN एक SSH सर्वर को पहुँच-योग्य बनाता है और उससे अधिक कुछ नहीं। तीन शर्तें तय करती हैं कि यह उपयुक्त है या नहीं, और विफलता का चरण बताता है कि कौन-सी परत दोषी है।
VPN एक SSH सर्वर को निजी मार्ग देता है और पोर्ट 22 पर सार्वजनिक श्रोता की आवश्यकता हटा देता है। यह होस्ट को प्रमाणित नहीं करता, उपयोगकर्ता को अधिकृत नहीं करता और यह तय नहीं करता कि कौन-से खाते लॉग इन कर सकते हैं। वह SSH का ही काम रहता है। VPN सर्वर तक पहुँचने का सही तरीका है या नहीं, यह तीन शर्तों पर निर्भर करता है, और सुरंग केवल संभावित उत्तरों में से एक है।
सुरंग क्या बदलती है और SSH अब भी क्या तय करता है
सुरंग पहुँच बदलती है: कौन-से पते पहुँचे जा सकते हैं, और कहाँ से। TCP कनेक्शन पहुँचने के बाद क्या होता है, यह वह नहीं बदलती, जहाँ सर्वर होस्ट कुंजी प्रस्तुत करता है और उपयोगकर्ता की पहचान माँगता है।
दोनों परतों को अपने दिमाग में और अपने दस्तावेज़ में अलग रखें। VPN लॉगिन साबित करता है कि कौन नेटवर्क का उपयोग कर सकता है। यह इस बारे में कुछ नहीं कहता कि लक्ष्य पर कौन-से खाते हैं, और यह हर पहुँच-योग्य मशीन में साइन इन करने की अनुमति नहीं है।
विफलता के तरीके भी अलग हैं, और यही घटना के दौरान अलगाव को उपयोगी बनाता है।
तीन शर्तें जो पहुँच मॉडल तय करती हैं
पहला, क्या सर्वर को आपके नेटवर्क के बाहर के लोगों के लिए पहुँच-योग्य होना चाहिए? यदि नहीं, तो निजी मार्ग और एक बुर्ज या एक जाल छोटा डिज़ाइन है। दूसरा, क्या ग्राहक आबादी वास्तव में VPN क्लाइंट चला सकती है, जिनमें प्रतिबंधों वाले प्रबंधित उपकरणों पर मौजूद लोग भी शामिल हैं?
तीसरा, क्या आपको प्रति-सेवा नियंत्रण चाहिए या प्रति-उपयोगकर्ता नियंत्रण? VPN नेटवर्क पहुँच देता है; SSH खाता पहुँच देता है। यदि आवश्यकता यह है कि ठेकेदार एक होस्ट तक पहुँचे और कुछ नहीं, तो वह अधिकृति की आवश्यकता है और केवल सुरंग उसे व्यक्त नहीं कर सकती।
उन तीन का उत्तर दें और मॉडल स्वयं चुन लेता है। उन्हें छोड़ दें और आप क्लाइंट रोलआउट से बचने के लिए SSH को सार्वजनिक रूप से उजागर करके समाप्त करेंगे।
SSH को दोष देने से पहले निजी मार्ग की पुष्टि करें
अनुमोदित VPN से कनेक्ट करें और लक्ष्य का दस्तावेज़ीकृत निजी नाम या पता उपयोग करें। फिर चयनित मार्ग, गेटवे की अनुमति और क्लाइंट तक वापसी मार्ग जाँचें। सही ढंग से हल होने वाला नाम इस बात का प्रमाण नहीं है कि पता इच्छित सुरंग लेता है, क्योंकि अतिव्यापी स्थानीय और दूरस्थ उपसर्ग अनुरोध को पूरी तरह कहीं और भेज सकते हैं। यह अंतर रनबुक में लिखने योग्य है।
यदि कनेक्शन कभी नहीं पहुँचता, पुष्टि करें कि सर्वर उस इंटरफ़ेस पर सुन रहा है जिसकी आप अपेक्षा करते हैं और उसका होस्ट फ़ायरवॉल उस स्रोत की अनुमति देता है जिसे वह वास्तव में देखता है। गेटवे NAT उस स्रोत को फिर से लिख सकता है, इसलिए क्लाइंट के सुरंग पते के लिए लिखी गई अनुमति सूची कभी मेल नहीं खा सकती।
यही असंगति VPN पर सबसे आम स्व-उत्पन्न SSH विफलता है।
संयुक्त त्रुटि नहीं, विफलता का चरण पढ़ें
तीन चरण तीन अलग संदेश उत्पन्न करते हैं, और उनमें से केवल एक क्रेडेंशियल के बारे में है।
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
VPN और SSH क्रेडेंशियल को एक साथ रीसेट करने के बजाय सटीक त्रुटि और सर्वर के अपने लॉग का उपयोग करें। दोनों को रीसेट करना ही पाँच मिनट के निदान को दो दिन की पहचान घटना में बदलने का तरीका है।
विस्तृत आउटपुट दिखाता है कि आप किस चरण तक पहुँचे:
ssh -vv [email protected]होस्ट कुंजियाँ और अधिकृति अक्षुण्ण रखें
होस्ट कुंजी को इच्छित विश्वसनीय प्रक्रिया के माध्यम से मान्य करें, विशेष रूप से सर्वर बदलने के बाद। अप्रत्याशित बदली-कुंजी चेतावनी वह एकमात्र संदेश है जिसे आपको केवल इसलिए खारिज नहीं करना चाहिए कि VPN जुड़ गया, क्योंकि निजी सुरंग गंतव्य को वह मशीन नहीं बनाती जो आप सोचते हैं। फिंगरप्रिंट को कनेक्शन से स्वतंत्र रूप से विश्वसनीय स्रोत के विरुद्ध जाँचें।
सर्वर पक्ष पर, पुष्टि करें कि खाता अधिकृत है और आपके द्वारा कॉन्फ़िगर की गई प्रमाणीकरण विधि वही है जो प्रस्तावित की जा रही है। मौजूद लेकिन अनदेखी की गई कुंजी आमतौर पर अनुमति या कॉन्फ़िगरेशन की समस्या है, नेटवर्क की नहीं।
सेवा पहुँच को आवश्यक पहचानों तक सीमित रखें और नेटवर्क परिवर्तनों के लिए अधिकृत पुनर्प्राप्ति मार्ग रखें।