केवल एन्क्रिप्शन ही दोबारा भेजे गए पैकेट को क्यों नहीं रोकता

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

तंत्र छोटा है, और इसकी विफलता के तरीक़े पैकेट हानि से आसानी से भ्रमित हो जाते हैं।

वैध सिफ़रटेक्स्ट ताज़ा सिफ़रटेक्स्ट नहीं है

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

वह नियम लागू करना सस्ता है और कहना भी सस्ता है: किसी दिए गए संरक्षित पैकेट को किसी दी गई कुंजी के अंतर्गत एक बार स्वीकार करें। इस क्षेत्र में बाक़ी सब कुछ इसी पर टिका है कि कार्यान्वयन उस एक बार को कैसे ट्रैक करता है।

दोबारा भेजे जाने के निराकरण को डिक्रिप्शन विफलता के रूप में पढ़ना आपको पूरी तरह ग़लत सबसिस्टम की ओर भेजता है।

क्रम-संख्या और एक विंडो

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

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

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

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

स्थिति कुंजी की है, होस्ट की नहीं

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

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

कुछ भी बंद करने से पहले कारण का निदान करें

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

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

जाँच क्या वादा नहीं करती

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

समर्थित सेटिंग्स के साथ अनुरक्षित सॉफ़्टवेयर ही उपयोगकर्ता के पास उपलब्ध व्यावहारिक नियंत्रण है। पैकेट प्रोटोकॉल संभालता है; बाक़ी सब परिचालन निर्णय रहता है।