रीबूटनंतर SSH ऐकत नाही: VPN पत्ता उशिरा येतो

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

बाइंड त्रुटी प्रत्यक्षात काय सांगते

ऐकणारे सॉकेट त्या क्षणी अस्तित्वात असलेल्या पत्त्यावर तयार केले पाहिजे। VPN इंटरफेस नंतर आल्यावर, फक्त टनेल पत्त्याला बांधण्यासाठी कॉन्फिगर केलेल्या डेमनला धरून ठेवण्यासाठी काहीही नसते। कॉन्फिगरेशन वाक्यरचनात्मकदृष्ट्या वैध राहते; वातावरण फक्त तयार नव्हते। हाताने सुरू केल्यापासून चालणारी सेवा कधीही बूट मार्गातून जात नाही, म्हणूनच दोष पुढील रीस्टार्टवरच दिसतो। अयशस्वी बाइंडचा टाइमस्टॅम्प पत्ता वाटपाच्या टाइमस्टॅम्पशी तुलना करा, आणि क्रम स्पष्ट होईल।

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

कोणती प्रक्रिया पोर्टची मालक आहे

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

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

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

तयारी स्पष्ट करा, झोप नाही

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

ip -4 addr show dev tun0
systemctl edit ssh.service

पत्ता दिसेपर्यंत पुनरावृत्ती करणारी ExecStartPre आज्ञा जोडा, किंवा इंटरफेसची मालकी असलेल्या विशिष्ट नेटवर्क लक्ष्यानंतर युनिट क्रमवारीत ठेवा। दोन्ही पद्धती अवलंबित्व अशा जागी नोंदवतात जिथे पुढील प्रशासक ते वाचू शकेल। लूपला टाइमआउट आवश्यक आहे, अन्यथा अयशस्वी VPN दोष नोंदवण्याऐवजी लटकलेले युनिट सोडते। मग डेमन टनेल पत्ता बांधते आणि सामान्य इंटरफेस तुमच्या फिल्टर नियमांखाली राहते याची खात्री करा।

स्वच्छ बूट आणि पुन्हा कनेक्शनची चाचणी करा

सर्व काही ऑनलाइन आल्यानंतरचा हाताने रीस्टार्ट बूट क्रमाबद्दल काहीही सिद्ध करत नाही। टनेल स्वयंचलितपणे वर येण्यासाठी कॉन्फिगर केलेल्या स्थितीत मशीन रीबूट करा आणि श्रोता कोणत्याही हस्तक्षेपाशिवाय दिसतो का ते पाहा।

systemctl status ssh.service
ss -ltnp 'sport = :22'

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

यशाचा निकष म्हणजे स्वतःच्या दस्तऐवजीकृत अवलंबित्वाखाली दिसणारा श्रोता, कोणीतरी पुन्हा सुरू करण्याचे आठवलेला श्रोता नाही।