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 जोडले गेले या कारणाने दुर्लक्ष करू नये, कारण खाजगी बोगदा गंतव्यस्थानाला तुम्ही विचार करता ते मशीन बनवत नाही। बोटांची छाप जोडणीपासून स्वतंत्रपणे विश्वासार्ह स्त्रोताशी तपासा।
सर्व्हरच्या बाजूला, खाते अधिकृत आहे आणि तुम्ही कॉन्फिगर केलेली प्रमाणीकरण पद्धत हीच सादर केली जात आहे याची खात्री करा। उपस्थित पण दुर्लक्षित केलेली की सामान्यतः नेटवर्कची नसून परवानग्या किंवा कॉन्फिगरेशनची समस्या असते।
सेवा प्रवेश आवश्यक ओळखींपर्यंत मर्यादित ठेवा आणि नेटवर्क बदलांसाठी अधिकृत पुनर्प्राप्ती मार्ग ठेवा।