तपाईंको 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 नीति हो। कुन मालिकले सेवा सुरु गर्छ र रहस्य कहाँ बस्छ लेख्नुहोस्, किनभने यो मेसिन अर्को पटक रिबुट गर्ने व्यक्तिलाई दुवै तथ्य चाहिन्छ।