OpenVPN रीप्ले बैकट्रैक लॉग में: पंक्ति क्या साबित नहीं करती

पंक्ति कहती है PID_ERR replay-window backtrack occurred, और सभी खोज परिणाम इसे गिराए गए पैकेट और टूटी सुरंग के रूप में समझाते हैं। Community OpenVPN 2.6 के UDP रास्ते में वह संदेश तब लिखा जाता है जब रिसीव फ़ंक्शन अभी तय कर रहा होता है कि पैकेट का क्या करना है। यह एक नया अधिकतम बैकट्रैक दर्ज करता है, फिर वही फ़ंक्शन स्वीकार या अस्वीकार करने से पहले दूरी की तुलना विंडो और दर्ज स्थिति से करता है। लॉग लेबल को फ़ैसला मानकर पढ़ना वह गलती है जिसे रोकने के लिए यह चेकलिस्ट है।

पड़ाव एक: पहचानें कि पंक्ति क्या है

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

पुष्टि करें कि किस होस्ट ने इसे लिखा और किस विस्तार स्तर पर। सर्वर और क्लाइंट दोनों पैकेट-ID संदेश भेज सकते हैं, और एक पक्ष का संदेश दूसरे पक्ष की रिसीव स्थिति के बारे में कुछ नहीं कहता।

पड़ाव दो: उस पैकेट का परिणाम खोजें

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

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

अगर लॉग उस समय उस सहकर्मी के लिए कोई अस्वीकृति नहीं दिखाता, तो इस पंक्ति को रुकावट का कारण मानना बंद करें। ऐप के रास्ते पर आगे बढ़ें, क्योंकि जुड़ा हुआ पर ट्रैफ़िक नहीं वाली अधिकांश रिपोर्टें असल में वहीं खत्म होती हैं।

पड़ाव तीन: तय करें कि पुनर्व्यवस्था असली है या नहीं

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

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

पड़ाव चार: विंडो पैरामीटर, और वे क्या नहीं हैं

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

पुराना प्रमाणित पैकेट अभी भी अनचाही पुनरावृत्ति हो सकता है, इसलिए रिसीवर ये जाँचें रखता है। अधिक पुनर्व्यवस्था स्वीकार करने का अर्थ है उस जोखिम का अधिक हिस्सा स्वीकार करना।

mute से चेतावनी शांत करना आप जो देखते हैं उसे बदलता है, डेमन जो करता है उसे नहीं। अगर लक्ष्य किसी ज्ञात घटना के दौरान शांत लॉग है, तो यह वैध परिचालन विकल्प है; अगर लक्ष्य सुरंग ठीक करना है, तो शांत करना प्रमाण छिपाता है।

mute 20
replay-window 64 15

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

पड़ाव पाँच: वह रास्ता जाँचें जो उपयोगकर्ता के लिए मायने रखता है

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

हर पड़ाव पर आपने क्या मापा, लिख लें। यही रिकॉर्ड अगली रिपोर्ट को फिर से डरावनी पंक्ति से शुरू होकर वहाँ से बाहर काम करने से रोकता है।

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