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

अर्धवट स्थिती हेच सामान्य अपयश

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

अजून नसलेली गोष्ट म्हणजे अयशस्वी पायरीनंतर आलेले सर्व. अपयश रिझॉल्व्हर टप्प्यात असले तर, पत्ते आणि मार्ग आहेत आणि DNS नाही. तो मार्ग असता तर, बोगद्याला पत्ता आहे पण त्यातून जाणारा मार्ग नाही।

परिणाम म्हणजे काही चाचण्यांना उत्तर देणारे आणि काहीत अपयशी होणारे मशीन, म्हणून लोक सेवा लुकलुकत आहे असे ठरवतात, पण ती कधीच यशस्वीरित्या सुरू झाली नाही. कधीही पूर्ण न झालेली सेवा लुकलुकू शकत नाही. ती त्याच कारणाने पुन्हा पुन्हा अयशस्वी होऊ शकते.

पहिली अयशस्वी पायरी शोधा

फक्त सध्याची स्थिती नाही, युनिटचा जर्नल वाचा, आणि तो अयशस्वी फेरीच्या सुरुवातीपासून वाचा. शेवटची ओळ एक्झिट कोड सांगते; पहिली त्रुटी काय दुरुस्त करावे ते सांगते.

हे आदेश युनिटची स्थिती, त्या युनिटचा बूट जर्नल आणि बोगद्याची थेट स्थिती छापतात:

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0

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

दुरुस्ती ठरवणाऱ्या तीन अटी

तुम्ही स्वच्छ करत आहात, जागेवरच दुरुस्त करत आहात की युनिट बूट मार्गातून काढत आहात हे ठरवा, आणि काहीही टाइप करण्यापूर्वी ते ठरवा.

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

ती तीन प्रकरणे गूढ लाल युनिटसारखी दिसणाऱ्यातील बहुतेक भाग व्यापतात. वेगळे करणारा प्रश्न असा की तेच अपयश स्वच्छ स्थितीच्या मशीनवरही होईल का, आणि उत्तर सहसा पहिल्या त्रुटी ओळीतून येते.

पुन्हा प्रयत्न करण्यापूर्वी स्वच्छ करा

सध्याच्या स्थितीवर पुन्हा प्रयत्न नव्या कारणाने अयशस्वी होऊन मूळ कारण लपवू शकतो. इंटरफेस तयार केलेल्या त्याच साधनाने तो खाली उतरवा, नंतर काहीही शिल्लक नाही याची खात्री करा.

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

युनिट नाही, बोगदा सिद्ध करा

हिरवे युनिट म्हणजे सुरुवातीचा क्रम शून्यासह बाहेर पडला. याचा अर्थ पॅकेट पलीकडे पोहोचले असा नाही, आणि रिझॉल्व्हर तुम्ही इच्छिल्याप्रमाणे सेट झाला असाही अर्थ नाही.

बोगद्यातून विनंती पाठवा आणि ती निर्माण करणारी स्थिती वाचा:

systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.net

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

संबंधित लेख