फक्त एन्क्रिप्शनच पुन्हा पाठवलेले पॅकेट का थांबवत नाही

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

यंत्रणा लहान आहे, आणि तिच्या अपयशाच्या पद्धती पॅकेट हानीसोबत गोंधळवणे सोपे आहे।

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

प्रमाणीकरण एकाच प्रश्नाचे उत्तर देते: हे बाइट किल्ली धारण करणाऱ्याकडून बदल न करता आले आहेत का। प्राप्तकर्ता हे पहिल्यांदा पाहत आहे का याचे उत्तर ते देत नाही। पुन्हा पाठवलेले पॅकेट पहिली कसोटी पूर्णपणे उत्तीर्ण होते, आणि म्हणूनच केवळ अखंडता तपासणी पुन्हा पाठवणे थांबवू शकत नाही आणि म्हणूनच प्रोटोकॉलला स्वीकृतीबद्दल दुसरा नियम आवश्यक आहे। केवळ प्रमाणीकरण करणाऱ्या प्राप्तकर्त्याकडे रेकॉर्डिंग धारण करणाऱ्या हल्लेखोराविरुद्ध कोणतेही संरक्षण नाही।

हा नियम राबवणे स्वस्त आहे आणि सांगणेही स्वस्त आहे: दिलेले संरक्षित पॅकेट दिलेल्या किल्लीखाली एकदा स्वीकारा। या क्षेत्रातील बाकी सर्व अंमलबजावणी ती एक वेळ कशी मागोवा घेते यावरून येते।

पुन्हा पाठवण्याच्या नाकारण्याला डिक्रिप्शन अपयश म्हणून वाचणे तुम्हाला पूर्णपणे चुकीच्या उपप्रणालीकडे पाठवते।

क्रम-क्रमांक आणि विंडो

IPsec ESP क्रम-क्रमांक वाहून नेतो आणि प्राप्तकर्ता नुकत्याच स्वीकारलेल्या मूल्यांची सरकती विंडो ठेवतो, तर ESP विनिर्देश डीफॉल्ट विंडो आकार आणि ती वाढवण्याचा पर्याय वर्णन करतो। WireGuard वेगळा मार्ग घेतो: प्रत्येक किल्लीसाठी काउंटर आणि त्याविरुद्ध स्पष्ट तपासणी। कोणतीही रचना पॅकेट क्रमाने येतात असे गृहीत धरत नाही, कारण वास्तविक नेटवर्क त्यांना पुनर्रचित करतात। दोन्ही पुनर्रचना सहन करतात, आणि कोणतेही पुनरावृत्ती सहन करत नाही।

ती सहनशीलता शक्य करणारी विंडोच आहे। पाहिलेल्या सर्वोच्च मूल्यापेक्षा थोडे मागे असलेले पॅकेट पूर्वी स्वीकारले नसल्यास अजूनही स्वीकारले जाऊ शकते; खूप मागे असलेले, किंवा ज्याचे स्थान आधीच चिन्हांकित आहे ते टाकून दिले जाते। विंडो वाढवा आणि प्रति असोसिएशन अधिक स्थितीच्या किंमतीवर अधिक पुनर्रचना सहन कराल।

निदान काउंटर दाखवतात की तुम्ही कोणत्या बाबतीत आहात। पुन्हा पाठवण्याची नाकारणी सामान्य त्रुटीऐवजी विशिष्ट काउंटर वाढवते, आणि तो काउंटर वाचणे हे पहिले उपयुक्त निरीक्षण आहे।

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

स्थिती किल्लीची आहे, होस्टची नाही

काउंटरची स्थिती सुरक्षा असोसिएशन किंवा किल्ली-युगाशी बांधलेली असते, म्हणून किल्ली बदलल्याने नवीन संदर्भ आणि स्वतःचे क्रम-क्षेत्र तयार होते। किल्ली न बदलता काउंटर साफ करणे, किंवा मॅन्युअल रीसेटनंतर असोसिएशन पुन्हा वापरणे, प्राप्तकर्त्याची विंडो ज्या गृहीतकावर अवलंबून आहे ते मोडते। म्हणूनच ऑपरेटरला दिसणाऱ्या रीसेट बटणाऐवजी प्रोटोकॉल-चालित किल्ली बदल आहे।

मॅन्युअल हस्तक्षेपानंतर टनेलने वाईट वागल्यास विचारा की हस्तक्षेपाने क्रम-स्थितीला स्पर्श केला का। सारखे दिसणारे कॉन्फिगरेशन वेगळे वागू शकते, कारण त्याला वारसा मिळालेली स्थिती ही त्याची अपेक्षित स्थिती नाही।

काहीही बंद करण्यापूर्वी कारणाचे निदान करा

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

मर्यादित पुरावे गोळा करा: असोसिएशन ओळखकर्ते, क्रम-क्रमांक आणि काउंटर, पेलोड वगळून। हे नकलीला पुनर्रचित आगमनापासून वेगळे करण्यासाठी पुरेसे आहे, आणि ते तुमची निदान फाइल वापरकर्त्याच्या ट्रॅफिकची प्रत बनवत नाही।

तपासणी काय वचन देत नाही

पुन्हा पाठवण्यापासून संरक्षण हा एका प्रोटोकॉलमधील पॅकेट प्रक्रियेचा गुणधर्म आहे। याचा अर्थ ऑपरेटर कोणतीही नोंद ठेवत नाही, वेबसाइट खाते ओळखू शकत नाही, किंवा सत्र निनावी आहे असा नाही। ती वेगवेगळ्या प्रणालींबद्दलची वेगवेगळी प्रश्ने आहेत, आणि मजबूत पुनःप्रेषण-विरोधी रचना त्यातील कोणत्याहीचे उत्तर देत नाही।

समर्थित सेटिंग्जसह देखभाल केलेले सॉफ्टवेअर हे वापरकर्त्याकडे उपलब्ध असलेले व्यावहारिक नियंत्रण आहे। पॅकेट प्रोटोकॉल हाताळतो; बाकी सर्व कार्यान्वयन निर्णय राहते।