रुक-रुक कर टूटता VPN: हर बार क्या दर्ज करें

रुक-रुक कर टूटना कॉन्फ़िगरेशन की समस्या बनने से पहले डेटा इकट्ठा करने की समस्या है। हर बार वही फ़ील्ड दर्ज करें, वरना घटनाओं की तुलना नहीं हो सकती। हर घटना के बाद तीन सेटिंग बदलने से आपके पास मौजूद इकलौता सबूत नष्ट हो जाता है।

नीचे दी गई प्रक्रिया प्रति घटना लगभग दो मिनट लेती है और प्रति घटना एक पंक्ति बनाती है। यह मानती है कि जिस डिवाइस को आप संभालते हैं, उस पर केवल पढ़ने की पहुँच है।

पहली विफलता से पहले फ़ील्ड तय करें

कुछ टूटने से पहले फ़ील्ड की सूची बना लें, क्योंकि घटना के बीच में गढ़ा गया टेम्पलेट हमेशा एक कॉलम छोड़ देता है। शुरू करने के लिए पाँच फ़ील्ड काफ़ी हैं: अपने ऑफ़सेट के साथ स्थानीय समय, ट्रिगर, जो चरण टूटा, त्रुटि का सटीक पाठ, और क्या नए प्रयास में सफलता मिली।

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

खाली जगहों को खाली ही रहने दें। जो टेम्पलेट उत्तर देने को बाध्य करता है, वह मनगढ़ंत को न्योता देता है, और गढ़ा हुआ संदर्भ खाली जगह से बुरा है।

विफलता के समय वही पाँच तथ्य दर्ज करें

हर बार वही कमांड उसी क्रम में चलाएँ। दो मिनट का आउटपुट ट्रे आइकन की तस्वीर से बेहतर है, और जब बाद में टाइमस्टैम्प न मिलें तो क्रम मायने रखता है।

date -Is
journalctl -u wg-quick@wg0 --since "-2 min" --no-pager
wg show wg0 latest-handshakes transfer
ip route get 203.0.113.10
ping -c 3 -W 2 192.0.2.1

पहली पंक्ति अवलोकन पर ऑफ़सेट के साथ मुहर लगाती है, और अलग-अलग ज़ोन में दर्ज तीन स्रोतों को मिलाने का यही एकमात्र तरीका है। जर्नल का अंश सेवा के जीवनचक्र को कवर करता है, और हैंडशेक की पंक्ति बताती है कि साथी ने जवाब दिया या नहीं। मार्ग की खोज उस इंटरफ़ेस का नाम बताती है जिसे कोई विशेष गंतव्य इस्तेमाल करेगा, और यह इंटरफ़ेस के होने जैसा तथ्य नहीं है। सुरंग के पते पर पिंग दिखाता है कि क्या कुछ कड़ी पार करता है, यह नहीं कि दूसरा पक्ष पहुँच में है।

चलते लॉग में प्रति घटना एक पंक्ति लिखें, केवल उन्हीं फ़ील्ड के साथ और कुछ नहीं। पाँच या छह प्रविष्टियों के बाद ट्रिगर से और फिर चरण से क्रमबद्ध करें। पैटर्न दोहराए जाने वाले जोड़ों के रूप में दिखते हैं, और जो जोड़ा कभी नहीं दोहराता वह संभवतः संयोग है।

जो चरण टूटा उसे खोजें

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

नाम विश्लेषण भी उसी रिकॉर्ड का हिस्सा है। सोमवार को सुरंग और मंगलवार को स्थानीय नेटवर्क का अनुसरण करने वाला रिज़ॉल्वर ऐसी विफलताएँ पैदा करता है जो एप्लिकेशन परत पर अनियमित लगती हैं।

अधिकृत सर्वर पहुँच के लिए पास के पुनःकनेक्शन को नहीं, उसी प्रयास को सहसंबद्ध करें। मूल टाइमस्टैम्प सुरक्षित रखें और किसी भी ऑफ़सेट को अलग दर्ज करें, क्योंकि उन्हें वहीं बदल देने से रूपांतरण का सबूत मिट जाता है। एक प्रयास, टाइमस्टैम्प का एक सेट, एक निष्कर्ष।

एक बार में एक शर्त की तुलना करें

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

विफल रन को रिकॉर्ड में रखें। काम करने वाले के पक्ष में उसे मिटाना उस सीमा का इकलौता सबूत फेंक देता है जिसे आप खोज रहे हैं।

प्रोफ़ाइल नहीं, अंश साझा करें

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

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