रीबूट के बाद 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.target की प्रतीक्षा करता है, network-online.target की नहीं, तो नेटवर्क ऑनलाइन होने से पहले स्टार्टअप पूरा हो सकता है। प्रमाणपत्र, कुंजियाँ या CRL जैसी संदर्भित फ़ाइलें उस समय अपठनीय हो सकती हैं क्योंकि माउंट या रहस्य का मार्ग अभी तैयार नहीं है। unit का जर्नल पढ़ने तक दोनों में से कोई समस्या systemctl status में नहीं दिखती।

होस्ट के बाहर से परीक्षण करें। उसी LAN का क्लाइंट ऐसे मार्ग से सफल हो सकता है जिसे कोई दूरस्थ क्लाइंट कभी नहीं अपनाएगा, और बॉक्स तक SSH सत्र टनल के बारे में कुछ साबित नहीं करता। कनेक्ट करें, आंतरिक नाम हल करें, निजी संसाधन तक पहुँचें, फिर निरसन स्थिति और कुंजियाँ अभी भी लागू हैं यह पुष्टि करने के लिए एक बार फिर कनेक्ट करें।

आपका सुधार तय करने वाली तीन शर्तें

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

सुधार वहीं करें जहाँ सेटिंग का स्वामित्व है। फ़ॉरवर्डिंग को sysctl drop-in में रखें, NAT नियमों को उस नियम-समुच्चय में रखें जो बूट पर लोड होता है, unit को शुरू करने के बजाय सक्षम करें, और रहस्य ऐसे मार्ग पर रखें जो unit शुरू होने से पहले मौजूद हो। unit में नींद जोड़ना निर्भरता को घोषित करने के बजाय छिपाता है।

runbook में परिणाम दर्ज करें

लिखें कि अपने आप क्या लौटा, आपको क्या शुरू करना पड़ा, और अंतर कितनी देर रहा। सत्यापन के लिए इस्तेमाल किए गए ठीक-ठीक कमांड शामिल करें, ताकि अगला व्यक्ति नया गढ़ने के बजाय परीक्षण दोहराए। यदि किसी कदम को हाथ से कमांड चाहिए था, तो वह कमांड कॉन्फ़िगरेशन का हिस्सा है, runbook में स्थायी कदम के रूप में नहीं।

फिर अगला परीक्षण होस्ट के नेटवर्क स्टैक में अगले बदलाव के बाद के लिए निर्धारित करें, छह महीने बाद की कैलेंडर तारीख के लिए नहीं। जिस विफलता से आप बचाव कर रहे हैं वह एक अस्थायी कमांड है जो स्थायी लगी, और वे ठीक तब दिखती हैं जब कोई फ़ायरवॉल नियम संपादित करता है या किसी सेवा को नए unit में ले जाता है।