तुमचा VPN लॉगिननंतरच चालतो, कारण कीरिंग

तुम्ही लॉगिन असता तेव्हा आदेश चालतो, म्हणून तुम्ही तो स्टार्टअप स्क्रिप्टमध्ये ठेवता आणि घरी जाता. पुढच्या सकाळी मशीन ऑनलाइन असते आणि टनेल नाही. चालणारे इनव्होकेशन म्हणजे चालणारी सेवा हा गैरसमज आहे. प्रत्यक्षात फरक सहसा दोनपैकी एक गोष्ट असतो: प्रोफाइल सिस्टमऐवजी तुमच्या वापरकर्ता सत्राची असते, किंवा रहस्य तुम्ही लॉगिन केल्यानंतरच अस्तित्वात असलेल्या एखाद्या गोष्टीने उघडते. दोन्ही मॅन्युअल चाचणीत उत्तम चालतात आणि कोणीही न पाहणाऱ्या नेमक्या त्या क्षणी अयशस्वी होतात.

लॉगिन हे का चालवते

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

तेच प्रोफाइल लॉगिनपूर्वी आणि नंतर चालवा आणि तुम्हाला एका कॉन्फिगरेशनमधून दोन वेगळे निकाल मिळतील. हे तुटलेल्या टनेलचे नाही, तर क्रेडेन्शियलवरील अवलंबनाचे लक्षण आहे, आणि टर्मिनलमधील मॅन्युअल चाचणी दिसते त्यापेक्षा कमी का सिद्ध करते हे स्पष्ट करते. टनेल ठीक आहे; त्याचे रहस्य उघडणारी गोष्ट गायब आहे.

टनेल कोण सुरू करेल ते ठरवा

दोन समर्थित नमुने आहेत, आणि ते मिसळणे हा हे अयशस्वी होण्याचा दुसरा मार्ग आहे. NetworkManager सिस्टम-स्कोप्ड कनेक्शन सक्रिय करू शकतो, जे मशीनने आधीच तिथे त्याचे नेटवर्किंग केंद्रित केले असेल तेव्हा योग्य आहे. किंवा, एक समर्पित systemd युनिट थेट VPN चालवते आणि स्वतः इंटरफेसची मालक असते.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

एकाच कॉन्फिगरेशनवर दोन्ही मालक चालवू नका. NetworkManager इंटरफेस व्यवस्थापित करत असेल आणि युनिटही तो वर आणत असेल, तर ते मार्ग आणि DNS साठी भांडतील, आणि परिणामी स्थिती कोण शेवटी पूर्ण झाले यावर अवलंबून असते.

सेवा वाचू शकेल तिथे रहस्य ठेवा

पार्श्वभूमी सेवा प्रॉम्प्टला उत्तर देऊ शकत नाही. प्रमाणपत्र पासफ्रेज, खाते पासवर्ड आणि संदर्भित प्रमाणीकरण फाइलींना अशी साठवण व्यवस्था लागते जिथे युनिट माणसाशिवाय पोहोचू शकेल, जी सेवा चालवणाऱ्या खात्याच्या मालकीची असेल आणि बाकी सर्वांना वाचता येणार नाही.

मोहक शॉर्टकट म्हणजे परवानगी त्रुटी नाहीशी होईपर्यंत फाइल सर्वांना वाचनीय करणे. ते स्टार्टअप अपयशाच्या बदल्यात दीर्घकालीन क्रेडेन्शियल उघड करते, आणि तो असा बदल आहे जो कोणी पुन्हा पाहत नाही. डिप्लॉयमेंट आधीच ज्यावर विश्वास ठेवते तो यंत्रणा वापरा: मर्यादित क्रेडेन्शियल फाइल, फाइल परवानग्यांनी संरक्षित अनएन्क्रिप्टेड की, किंवा स्वतःच्या गुप्त साठ्यासह सिस्टम-स्कोप्ड कनेक्शन.

प्रत्यक्षात घडणारी घटना तपासा

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

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

क्रम क्रेडेन्शियलइतकाच महत्त्वाचा आहे. अंतर्निहित अपलिंक कॉन्फिगर होण्यापूर्वी सुरू होणारे युनिट हार मानेल, आणि काही वितरणे कनेक्टिव्हिटीची वाट पाहतात का यात वेगळी आहेत. युनिट बूटवेळी अपयश नोंदवते पण तीस सेकंदांनंतर हाताने सुरू केल्यावर यशस्वी होते, तर तुम्हाला रहस्याची नाही, क्रमाची समस्या सापडली आहे.

फक्त इंटरफेस नाही, मार्ग आणि DNS तपासा

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

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

पत्ता चालत असेल आणि नाव नसेल, तर उरलेली समस्या टनेल नाही, DNS धोरण आहे. कोण मालक सेवा सुरू करतो आणि रहस्य कुठे राहते हे लिहून ठेवा, कारण हे मशीन पुढे रीबूट करणाऱ्या व्यक्तीला दोन्ही तथ्ये लागतील.