किन मात्र इन्क्रिप्शनले पुनः पठाइएको प्याकेट रोक्दैन

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

क्रियाविधि सानो छ, र यसको असफलताका तरिकाहरू प्याकेट हानिसँग भ्रमित गर्न सजिलो छ।

वैध साइफरटेक्स्ट ताजा साइफरटेक्स्ट होइन

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

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

पुनः पठाइएको अस्वीकृतिलाई डिक्रिप्शन असफलता भनेर पढ्नु तपाईंलाई पूर्ण रूपमा गलत उपप्रणालीमा पठाउँछ।

क्रम-संख्या र सञ्झ्याल

IPsec ESP ले क्रम-संख्या बोक्छ र प्राप्तकर्ताले हालै स्वीकार गरिएका मानहरूको सर्ने सञ्झ्याल राख्छ, जबकि ESP विनिर्देश ले पूर्वनिर्धारित सञ्झ्याल आकार र त्यसलाई विस्तार गर्ने विकल्प वर्णन गर्छ। WireGuard अर्को बाटो लिन्छ: प्रत्येक कुञ्जीका लागि काउन्टर र त्यसविरुद्ध स्पष्ट जाँच। कुनै पनि डिजाइनले प्याकेटहरू क्रममा आउँछन् भनी मान्दैन, किनकि वास्तविक सञ्जालहरूले तिनलाई पुनः क्रमबद्ध गर्छन्। दुवैले पुनः क्रमबद्धता सहन्छन्, र कुनैले पनि पुनरावृत्ति सहँदैन।

त्यो सहनशीलता सम्भव बनाउने सञ्झ्याल हो। देखिएको उच्चतम मानभन्दा अलिकति पछाडिको प्याकेट पहिले स्वीकार नगरिएको भए अझै स्वीकार गर्न सकिन्छ; धेरै पछाडिको, वा जसको ठाउँ पहिले नै चिन्हित छ, त्यसलाई छाडिन्छ। सञ्झ्याल बढाउनुहोस् र प्रति एसोसिएन बढी अवस्थाको लागतमा बढी पुनः क्रमबद्धता सहनुहुनेछ।

निदान काउन्टरहरूले तपाईं कुन अवस्थामा छ भनी देखाउँछन्। पुनः पठाइएका अस्वीकृतिहरूले सामान्य त्रुटिको सट्टा विशेष काउन्टर बढाउँछन्, र त्यो काउन्टर पढ्नु पहिलो उपयोगी अवलोकन हो।

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

अवस्था कुञ्जीको हो, होस्टको होइन

काउन्टरको अवस्था सुरक्षा एसोसिएन वा कुञ्जी-युगसँग बाँधिएको हुन्छ, त्यसैले कुञ्जी परिवर्तनले नयाँ सन्दर्भ र आफ्नै क्रम-क्षेत्र सिर्जना गर्छ। कुञ्जी नबदली काउन्टर खाली गर्नु, वा म्यानुअल रिसेटपछि एसोसिएन पुनः प्रयोग गर्नु, प्राप्तकर्ताको सञ्झ्याल जुन मान्यतामा अडिएको छ त्यो तोड्छ। त्यसैले अपरेटरलाई देखिने रिसेट बटनको सट्टा प्रोटोकल-निर्देशित कुञ्जी परिवर्तन छ।

म्यानुअल हस्तक्षेपपछि टनेलले नराम्रो व्यवहार गरेमा सोध्नुहोस् कि हस्तक्षेपले क्रम-अवस्थालाई छोयो कि। एउटै जस्तो देखिने कन्फिगरेसन फरक व्यवहार गर्न सक्छ, किनकि यसले पाएको अवस्था यसले अपेक्षा गरेको अवस्था होइन।

केही बन्द गर्नुअघि कारणको निदान गर्नुहोस्

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

सीमित प्रमाण संकलन गर्नुहोस्: एसोसिएन पहिचानकर्ता, क्रम-संख्या र काउन्टर, पेलोड बाहेक। यो नक्कललाई पुनः क्रमबद्ध आगमनबाट छुट्याउन पर्याप्त छ, र यसले तपाईंको निदान फाइललाई प्रयोगकर्ताको ट्राफिकको प्रतिलिपि बनाउँदैन।

जाँचले के वाचा गर्दैन

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

समर्थित सेटिङसहित मर्मत गरिएको सफ्टवेयर नै प्रयोगकर्तासँग उपलब्ध व्यावहारिक नियन्त्रण हो। प्याकेट प्रोटोकलले सम्हाल्छ; बाँकी सबै सञ्चालन निर्णय रहन्छ।