रिबुटपछि VPN सर्भरको रिकभरी परीक्षण गर्नुहोस्: पहिले के जाँच्ने

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

चार मालिक, चार फरक परीक्षण

रिस्टार्ट अघि, टनेललाई केले फर्काउनुपर्ने हो भनेर नाम दिनुहोस्। तपाईंले चलाउने परीक्षण र लागू गर्ने सुधार दुवै त्यही जवाफमा निर्भर छन्, र चार सामान्य मालिक हुन्छन्: VPN डेमनका लागि systemd unit, WireGuard इन्टरफेसका लागि wg-quick इन्स्टेन्स unit, कन्टेनर रनटाइम, वा नेटवर्क म्यानेजर प्रोफाइल। मालिकको नाम बताउन सक्नुहुन्न भने रोक्नुहोस् र खोज्नुहोस्, किनकि अपेक्षित स्टार्टअप मार्ग बिना रिबुट परीक्षणले केही भयो भन्ने मात्र बताउँछ।

प्रत्येक मालिकले आफ्नो कन्फिगरेसन अर्कै ठाउँमा राख्छ। systemd द्वारा व्यवस्थापित OpenVPN सर्भरले सुरु हुँदा आफ्नो कन्फिगरेसन पढ्छ, त्यसैले बुटको समयमा फाइलमा जे छ त्यही चल्छ। wg-quick इन्टरफेसले आफ्ना ठेगाना, रुट र DNS एही फाइलबाट लिन्छ, जसको अर्थ शेलबाट हातले माथि उठाइएको र कहिल्यै unit का रूपमा सक्षम नगरिएको इन्टरफेस फर्कंदैन। कन्टेनरले आफ्नो प्रवेश बिन्दु फर्काउँछ, तर होस्टको फायरवाल परिवर्तन फर्काउँदैन, ती कन्टेनर बाहिर छन् भने बाहेक।

पहिले आधारभूत अवस्था, नत्र परिणामको कुनै अर्थ हुँदैन

काम गरिरहेको बेला कार्यरत अवस्था रेकर्ड गर्नुहोस्: टनेलमा ठेगानाहरू, क्लाइन्ट सबनेटका रुटहरू, NAT वा फर्वार्डिङ नियमहरू, सुनिरहेको सकेट, र फर्वार्डिङ sysctl। ip addr show wg0, ip route, nft list ruleset वा iptables-save, ss -lunp र sysctl net.ipv4.ip_forward अधिकांश होस्टमा पर्याप्त छन्।

सेवा चलिरहेको छ कि भन्ने मात्र होइन, यो सुरु हुन कसरी कन्फिगर गरिएको छ त्यो पनि रेकर्ड गर्नुहोस्। systemctl is-enabled wg-quick@wg0 र systemctl is-active wg-quick@wg0 फरक प्रश्नको जवाफ दिन्छन्, र बुटको समयमा सक्षम अवस्था नै महत्त्वपूर्ण हुन्छ, systemctl(1) मा वर्णन गरिएअनुसार। OpenVPN का लागि, होस्टले कुन टेम्प्लेट प्रयोग गर्छ जाँच्नुहोस्, किनकि openvpn@server र openvpn-server@server फरक डिफल्ट भएका फरक unit हुन्।

रिस्टार्ट चलाउनुहोस् र पहिलो असफलता पढ्नुहोस्

तपाईंले छानेको समयमा जानाजान रिबुट गर्नुहोस्, कन्सोल वा आउट-अफ-ब्यान्ड मार्ग खुला राखेर। अन्तिम अवस्था नभई घटनाको क्रम हेर्नुहोस्: होस्ट पुग्न सकिने, unit सक्रिय, इन्टरफेस उपस्थित, रुट स्थापित, फायरवाल नियम उपस्थित, श्रोता बाँधिएको, क्लाइन्ट स्वीकृत। नहुने पहिलो चरण नै निष्कर्ष हो; त्यसपछिको सबै हल्ला हो।

टनेल प्रयोगयोग्य नहुँदा पनि डेमन सक्रिय हुन सक्छ, र यो सबैभन्दा सामान्य झुटो उत्तीर्ण हो। unit ले network-online.target को सट्टा network.target को मात्र प्रतीक्षा गर्छ भने नेटवर्क अनलाइन हुनुअघि नै स्टार्टअप पूरा हुन सक्छ। प्रमाणपत्र, कुञ्जी वा CRL जस्ता सन्दर्भित फाइलहरू त्यस क्षणमा पढ्न नसकिने हुन सक्छन्, किनकि माउन्ट वा गोप्य मार्ग अझै तयार छैन। unit को जर्नल नपढेसम्म दुवै समस्यामध्ये कुनै पनि systemctl status मा देखिँदैन।

होस्ट बाहिरबाट परीक्षण गर्नुहोस्। उही LAN को क्लाइन्ट कुनै पनि टाढाको क्लाइन्टले कहिल्यै नप्रयोग गर्ने मार्गबाट सफल हुन सक्छ, र मेसिनमा SSH सत्रले टनेलबारे केही प्रमाणित गर्दैन। जडान गर्नुहोस्, आन्तरिक नाम समाधान गर्नुहोस्, निजी स्रोतमा पुग्नुहोस्, त्यसपछि रद्द अवस्था र कुञ्जीहरू अझै लागू छन् भनी पुष्टि गर्न एकपटक फेरि जडान गर्नुहोस्।

तपाईंको सुधार निर्धारण गर्ने तीन सर्त

टनेल फर्कियो तर क्लाइन्टहरू कतै पुग्न सकेनन् भने असफलता राउटिङ वा NAT स्थायित्वमा छ। क्लाइन्टहरूले ह्यान्डसेक पनि पूरा गर्न सकेनन् भने असफलता इन्टरफेस वा प्रमाणीकरण सामग्रीमा छ। सेवा कहिल्यै सुरु भएन भने असफलता unit फाइल वा त्यसका निर्भरताहरूमा छ। यी तीन शाखा फरक सुधारतर्फ लैजान्छन्, त्यसैले आधारभूत अवस्था बिना अन्धो रिबुटले बचत गरेभन्दा बढी समय लिन्छ।

सेटिङको स्वामित्व भएकै ठाउँमा सुधार गर्नुहोस्। फर्वार्डिङलाई sysctl drop-in मा राख्नुहोस्, NAT नियमहरूलाई बुटमा लोड हुने नियमसमूहमा राख्नुहोस्, unit लाई सुरु गर्नुको सट्टा सक्षम गर्नुहोस्, र गोप्य कुराहरू unit सुरु हुनुअघि अवस्थित मार्गमा राख्नुहोस्। unit मा निद्रा थप्नु निर्भरता घोषणा गर्नुको सट्टा लुकाउनु हो।

नतिजा runbook मा रेकर्ड गर्नुहोस्

आफैं के फर्कियो, के सुरु गर्नुपर्‍यो, र अन्तर कति समय रह्यो लेख्नुहोस्। प्रमाणित गर्न प्रयोग गरेका ठ्याक्कै आदेशहरू समावेश गर्नुहोस्, ताकि अर्को व्यक्तिले नयाँ बनाउनुको सट्टा परीक्षण दोहोर्‍याओस्। कुनै चरणलाई हातले आदेश चाहिएको थियो भने त्यो आदेश कन्फिगरेसनको हो, runbook मा स्थायी चरणका रूपमा होइन।

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