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 पुनर्जोडणीनंतर तिसरा आदेश पुन्हा चालवा.

जीवनचक्र जाणीवपूर्वक निवडा: एकतर स्थिर पत्ता परत येण्याची वाट पाहणारा मुक्तपणे बांधलेला श्रोता, किंवा टनेलसोबत थांबणारी आणि पुनर्प्राप्तीवर पुन्हा सुरू होणारी सेवा. हे वेगवेगळे आराखडे आहेत आणि ते वेगवेगळ्या प्रकारे अयशस्वी होतात. नंतर प्रवेश धोरण तुम्ही हेतू असलेल्या स्रोत व मार्गांशी जोडून ठेवा, कारण गंतव्य पत्ता बांधल्याने स्वीकारलेली पॅकेट विश्वासार्ह इंटरफेसने आली असावी अशी अट येत नाही.