इंटरफ़ेस चालू है पर wg-quick विफल: अब क्या करें

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

आधी अवस्था ही सामान्य विफलता है

इस व्यवहार की अपेक्षा करनी चाहिए, उसे भ्रष्टाचार मानने के बजाय। इंटरफ़ेस सेटअप का सबसे सस्ता हिस्सा है और पीछे छोड़ना सबसे आसान, और यही वह हिस्सा है जो मशीन को आधा चलता हुआ दिखाता है।

जो अभी मौजूद नहीं है वह है विफल चरण के बाद आया सब कुछ। अगर विफलता रिज़ॉल्वर चरण में हुई थी, तो पते और मार्ग मौजूद हैं और 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

बिना जवाब का हैंडशेक फिर भी बताता है कि टनल बना और दूसरा छोर शांत है, जो कभी शुरू न हुई यूनिट से अलग समस्या है। यूनिट की स्थिति, हैंडशेक और अनुरोध का नतीजा एक ही रिकॉर्ड में रखें, क्योंकि ये स्वतंत्र रूप से विफल होते हैं और केवल संयोजन ही सिस्टम का वर्णन करता है।