रीबूटनंतर 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 मध्ये हलवतो।