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 पुनःजडानपछि तेस्रो आदेश दोहोर्याउनुहोस्।

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