रीबूट के बाद 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'

फिर टनल को गिराएँ और फिर से स्थापित करें, क्योंकि पुनः कनेक्शन पता बदल सकता है और हार्डकोडेड बाइंडिंग उसका पीछा नहीं करेगी। परीक्षण के दौरान आउट-ऑफ़-बैंड रिकवरी पथ रखें, ताकि खराब क्रम परिवर्तन आपको होस्ट से बाहर लॉक न कर दे।

सफलता का मानदंड ऐसा श्रोता है जो अपनी प्रलेखित निर्भरता के अंतर्गत दिखता है, न कि वह जिसे किसी ने फिर से शुरू करना याद रखा।