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