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 अंमलबजावणी आकडेवारी आणि निर्णयाचा क्रम दाखवते, आणि पुस्तिका विंडोचा क्रम आणि वेळ व्याप्ती वर्णन करते। दोन्ही एकत्र वाचणे हेच भयावह लॉग ओळीला ज्ञात परिमाणात बदलते। यापैकी कोणीही तुमच्या विशिष्ट मार्गाबद्दल काहीच सांगत नाही, म्हणून वरील मोजमाप अजूनही महत्त्वाची आहेत।