रिबुटपछि 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'

त्यसपछि टनेल खसाल्नुहोस् र पुनः स्थापित गर्नुहोस्, किनकि पुनः जडानले ठेगाना बदल्न सक्छ र हार्डकोड गरिएको बाइन्डिङले त्यसको पछि लाग्दैन। परीक्षणका क्रममा ब्यान्डबाहिरको पुनःप्राप्ति मार्ग राख्नुहोस्, ताकि खराब क्रम परिवर्तनले तपाईंलाई होस्टबाट बाहिर लक नगरोस्।

सफलताको मापदण्ड भनेको आफ्नै अभिलेखित निर्भरताअन्तर्गत देखिने श्रोता हो, कसैले पुनः सुरु गर्न सम्झेको श्रोता होइन।