FreeBind बनाम After=: systemd सॉकेट को VPN पते से बाँधना

बूट के समय निश्चित VPN पता बाँधने वाली सॉकेट इकाई टनल के उसे सौंपने से पहले ही विफल हो सकती है, और उसके पीछे की सेवा कभी शुरू नहीं होती। दो स्विच समाधान जैसे दिखते हैं और समस्या के अलग-अलग आधे हिस्से हल करते हैं। FreeBind systemd को पता अभी अनुपस्थित रहते हुए ही श्रोता बनाने देता है। After= केवल कार्यों का क्रम तय करता है, इसलिए वह बदलता है कि चीज़ें कब शुरू हों, पर पता जल्दी नहीं आता।

दो अलग समस्याएँ, दो अलग स्विच

पहली समस्या बंधन की विफलता है: कर्नेल ऐसे पते पर सुनने से इनकार करता है जिसका स्वामी होस्ट नहीं है, इसलिए सॉकेट इकाई तुरंत विफल हो जाती है और सेवा कभी सक्रिय नहीं होती। दूसरी समस्या तैयारी की विफलता है: पता अंततः मौजूद होता है, पर कुछ उसे टनल के यातायात ले जाने से पहले उपयोग करने का प्रयास करता है। FreeBind पहली को संबोधित करता है और दूसरी के लिए कुछ नहीं करता। क्रम-निर्देश किसी को भी सीधे संबोधित नहीं करते, क्योंकि वे केवल तय करते हैं कि क्या किस क्रम में शुरू हो। आपके पास जो विफलता वास्तव में है, उसका नाम देना ही पूरा निर्णय है।

आपके पास दोनों में से कौन-सी है, यह सेवा के विवरण से नहीं, जर्नल से पुष्टि करें। बंधन की विफलता एक पता बताती है और सूचित करती है कि उसे सौंपा नहीं जा सकता। तैयारी की विफलता सामान्यतः बाद में दिखती है, समय-समाप्ति या दूसरे छोर से देखे गए अस्वीकृत कनेक्शन के रूप में, जबकि लॉग में पूरी तरह स्वस्थ सॉकेट इकाई होती है।

FreeBind: पते से पहले श्रोता मौजूद

FreeBind कर्नेल को गैर-स्थानीय पते पर बंधन की अनुमति देने को कहता है, ताकि systemd बूट पर सुनने वाला सॉकेट बना सके और जब भी एप्लिकेशन शुरू हो उसे सौंप सके। सॉकेट सक्रियण का यही अर्थ है, और सॉकेट अपनी पीछे की सेवा से अधिक टिक सकता है, इसका कारण भी यही है।

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

खाली असाइनमेंट नई प्रविष्टि जोड़ने से पहले विक्रेता इकाई से विरासत में मिली सुनने की प्रविष्टियाँ साफ़ करता है, जो हर इंटरफ़ेस पर जवाब देते बचे हुए wildcard श्रोता को रोकता है। पता और पोर्ट अपने से बदलें और केवल drop-in फ़ाइल नहीं, प्रभावी इकाई सत्यापित करें। पैकेज फ़ाइल को उसकी जगह संपादित करने के बदले इकाई के नाम के अंतर्गत drop-in इस्तेमाल करें, क्योंकि अगला पैकेज अद्यतन संपादन को अधिलेखित कर देगा और मंशा का कोई चिह्न नहीं छोड़ेगा। फिर सॉकेट इकाई जिस पुनःलोड और पुनःआरंभ प्रक्रिया की अपेक्षा करती है, उससे लागू करें।

systemd सॉकेट संदर्भ इस विकल्प के पीछे का IPv4 और IPv6 व्यवहार दस्तावेज़ित करता है, और महत्वपूर्ण ब्यौरा यह है कि यह बंधन पर लागू होता है, रूटिंग पर नहीं। इसमें कुछ भी पता नहीं सौंपता या VPN शुरू नहीं करता। FreeBind श्रोता को दी गई अनुमति है, इंटरफ़ेस का विकल्प नहीं।

After= और Wants=: क्रम तैयारी नहीं है

क्रम और अपेक्षा अलग अक्ष हैं, और इन्हें मिलाने से ऐसी इकाइयाँ बनती हैं जो सही क्रम में शुरू होकर भी विफल होती हैं। After=vpn-client.service का अर्थ केवल यह है कि यदि दोनों कार्य शुरू हों, तो यह दूसरे के शुरू होने की प्रतीक्षा करता है। यह VPN को खींचता नहीं और VPN के जुड़ना पूरा होने की प्रतीक्षा नहीं करता।

Wants= और Requires= जैसे अपेक्षा-निर्देश सक्रियण संभालते हैं, और निर्भरता विफल होने पर क्या होता है इसमें भिन्न हैं: एक जारी रहता है, दूसरा रुक जाता है। इनमें से कोई नहीं जानता कि जुड़ी हुई टनल का क्या अर्थ है। VPN प्रक्रिया बिना पता सौंपे सक्रिय हो सकती है, या पता सौंपे जाने पर भी साथी तक मार्ग बिना, और दोनों स्थितियाँ निर्भरता पूरी करती हैं। यदि एप्लिकेशन को पते का होना आवश्यक है, तो प्रक्रिया के शुरू होने को तैयारी का प्रमाण मानने के बदले उस शर्त को स्पष्ट रूप से प्रतिरूपित करें।

systemctl cat और systemctl show -p After -p Wants -p Requires से जाँचें कि इकाई वास्तव में क्या घोषित करती है। तीन अलग निर्देशिकाओं के drop-in ऐसे निर्देश जोड़ सकते हैं जो आपने कभी नहीं लिखे, और systemd केवल प्रभावी इकाई पढ़ता है।

network-online.target जो नहीं करता

network-online.target के बाद क्रमित इकाई प्रतीक्षा करती है कि नेटवर्क प्रबंधक नेटवर्क को उपयोगी घोषित करे, जो बूट का समन्वय-बिंदु है, निरंतर शर्त नहीं। यह नहीं बताती कि कोई विशेष टनल चालू है या नहीं, और दोपहर बाद VPN के फिर जुड़ने पर यह दोबारा नहीं चलेगी। इसे पुनःकनेक्शन मॉनिटर मानना उस लक्ष्य की सबसे आम गलत व्याख्या है।

systemd परियोजना उस अंतर को सीधे दस्तावेज़ित करती है, और व्यावहारिक परिणाम यह है कि टनल पता चाहने वाली हर चीज़ को निर्भरता स्वयं रखनी होगी। जो इकाई network-online की प्रतीक्षा करके फिर टनल पता बाँधती है, वह केवल तब सही है जब टनल संयोगवश पहले ऊपर आए, और वह संयोग है, अभिकल्प नहीं।

जो जीवनचक्र आपने वास्तव में चुना, उसे जाँचें

स्वच्छ बूट, पता आने के बाद का अनुरोध, और VPN के गिरकर लौटने के बाद का व्यवहार जाँचें। ये तीन स्थितियाँ काम करने वाले श्रोता को काम करने वाली सेवा से अलग करती हैं।

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

पहला आदेश पुनःआरंभ से पहले इकाई-फ़ाइल की त्रुटियाँ पकड़ता है, दूसरा मिली-जुली इकाई दिखाता है, और तीसरा सिद्ध करता है कि श्रोता है या नहीं और किस पते पर। जहाँ आपने टनल पता अपेक्षित किया था वहाँ wildcard पते पर श्रोता ठीक वही बचा हुआ अंश है जिसे खाली ListenStream हटाने के लिए था। पता खिसका या नहीं, यह देखने के लिए VPN के पुनःकनेक्शन के बाद तीसरा आदेश दोहराएँ।

जीवनचक्र सोच-समझकर चुनें: या तो स्थिर पते के लौटने की प्रतीक्षा करता मुक्त रूप से बँधा श्रोता, या टनल के साथ रुकने वाली और पुनर्प्राप्ति पर फिर शुरू होने वाली सेवा। ये अलग अभिकल्प हैं और अलग तरह से विफल होते हैं। फिर पहुँच नीति को उन्हीं स्रोतों और पथों से बाँधे रखें जिनका आपने इरादा किया था, क्योंकि गंतव्य पता बाँधने से यह आवश्यक नहीं होता कि स्वीकृत पैकेट किसी विश्वसनीय इंटरफ़ेस से आए हों।