VPN सुरू असताना दुसऱ्या खाजगी मार्गावर SSH

एक मशीन VPN मार्फत दुसऱ्यापर्यंत पोहोचते, आणि आता कोणालातरी तेच शेल प्रदात्याच्या खाजगी नेटवर्कवर हवे आहे। मार्ग अस्तित्वात आहे, पिंग यशस्वी होते, तरीही SSH नकार देते। नेहमीचे कारण म्हणजे डेमॉनने नवीन पत्त्यावर कधीही ऐकले नाही, त्यामुळे जोडण्यासाठी काहीच नाही। ही फायरवॉलची समस्या होण्यापूर्वी पत्ता-बाइंडिंगची समस्या आहे।

नवीन मार्ग नवीन श्रोता का तयार करत नाही

ऐकणारा सॉकेट असा प्रक्रिया तयार करतो जो स्वीकारणारे पत्ते नावाने सांगतो। मार्ग फक्त पॅकेटना कुठे जायचे ते सांगतो; तो गंतव्यस्थानी श्रोता तयार करत नाही। जेव्हा sshd एकाच ListenAddress सह संरचित असतो, तेव्हा इंटरफेस सुरू असूनही इतर कोणत्याही स्थानिक पत्त्यावरील कनेक्शन नाकारली जातात। पोर्ट धारण करणाऱ्या सॉकेट युनिटलाही हेच लागू होते, म्हणून पहिली तपासणी नेहमी प्रत्यक्षात काय ऐकत आहे हे असते।

दोन्ही मार्गांची तुलना इंटरफेस नावाने नाही तर गंतव्य पत्त्याने करा। क्लायंट पत्त्याशी जोडतो, आणि कोणताही फायरवॉल नियम महत्त्वाचा होण्यापूर्वी तो पत्ता बांधलेला असणे आवश्यक आहे।

पत्ते आणि श्रोते यांची यादी करा

काहीही संपादित करण्यापूर्वी, होस्टवरील पत्ते आणि आता असलेली सॉकेट नोंदवा।

ip -br addr
ss -ltnp | grep ':22'

पत्त्यांची यादी दाखवते की कोणता खाजगी पत्ता खरा आहे आणि कोणत्या इंटरफेसवर, तर सॉकेट यादी दाखवते की त्याला काही बांधलेले आहे का। 0.0.0.0:22 वर ऐकणारा श्रोता आधीच प्रत्येक पत्ता स्वीकारतो, त्यामुळे नवीन बाइंडिंग काहीही जोडत नाही। एका विशिष्ट पत्त्यावर ऐकणारा श्रोता नकाराचे कारण लगेच स्पष्ट करतो। पोर्ट डेमॉनऐवजी सॉकेट युनिटचा असल्यास, डेमॉनचे संरचना ही संपूर्ण कथा नाही।

बाइंडिंग जोडा आणि जुनी टिकवा

OpenSSH अनेक ListenAddress नोंदी स्वीकारतो, त्यामुळे खाजगी मार्ग जोडताना VPN मार्ग राहू शकतो। फाइल पुन्हा लोड करण्यापूर्वी तिची चाचणी करा।

sshd -t
systemctl reload sshd

अयशस्वी संरचना चाचणी चालू डेमॉनला अस्पर्श ठेवते, आणि तुम्ही संपादित करत असलेल्या मार्गावरून जोडलेले असताना नेमके तेच तुम्हाला हवे असते। विद्यमान नोंद ठेवा, नवीन स्थानिक पत्ता जोडा, आणि सेवा सध्याचे सत्र न तोडता पुन्हा लोड होते याची खात्री करा। सॉकेट-सक्रिय इन्स्टॉलेशनवर पत्ता त्याऐवजी सॉकेट युनिटमध्ये जोडा आणि ते युनिट पुन्हा लोड करा। नंतर श्रोत्यांची यादी पुन्हा वाचा, कारण कधीही न दिसलेले बाइंडिंग म्हणजे चुकीचा घटक संपादित झाला।

जुने सत्र बंद करण्यापूर्वी नवे सत्र तपासा

मूळ सत्र अजून उघडे असताना नवीन पत्त्याशी जोडा, आणि कोणता पत्ता व किल्ली वापरली गेली हे पाहण्यासाठी तपशीलवार आउटपुट वापरा। तपासणी दोन वेळा यशस्वी होईपर्यंत मूळ सत्र उघडे ठेवा।

ssh -v [email protected]

गंतव्य पत्ता आणि सादर केलेल्या होस्ट किल्लीसाठी डीबग ओळी वाचा। नेटवर्क खाजगी असल्याचे वर्णन आहे म्हणून अनोळखी किल्ली स्वीकारण्याऐवजी, तुम्ही आधीच विश्वास ठेवता अशा मूल्याशी होस्ट किल्लीची फिंगरप्रिंट पडताळा। नवीन गंतव्याला स्वतःची known_hosts नोंद आवश्यक आहे, आणि ते अपेक्षित आहे। खाजगी मार्ग काम करू लागल्यावरच जुने व्यवस्थापन सत्र बंद करावे।

SSH वाहतुकीचे संरक्षण करते, पण स्वतंत्रपणे ते दोन नेटवर्क समतुल्य करत नाही। खाजगी मार्गाचा विश्वास डेटाशी जुळतो का, हे त्यावर अवलंबून राहण्यापूर्वी ठरवा।