IKEv2 फ्रॅगमेंटेशनला सर्टिफिकेट साखळीच्या समस्येपासून वेगळे ओळखणे

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

दोन फ्रॅगमेंटेशन यंत्रणा, एक लक्षण

IKEv2 ला स्वतःचे फ्रॅगमेंटेशन विस्तार आहे, जे RFC 7383 मध्ये परिभाषित आहे आणि संरक्षित IKE संदेशांना लहान IKE संदेशांमध्ये विभाजित करते। दोन्ही बाजू त्या क्षमतेवर वाटाघाटी करतात, आणि संदेश IP स्तराने नव्हे, तर IKE अंमलबजावणीने पुन्हा जोडला जातो।

साधारण IP फ्रॅगमेंटेशन वेगळ्या अपयश पद्धतीची दुसरी यंत्रणा आहे। दोन्ही बाजूंमधील राउटर मोठा डेटाग्राम विभाजित करतो, किंवा तो टाकून देऊन पाठवणाऱ्यापर्यंत कधीच न पोहोचणारा ICMP संदेश परत पाठवतो। काही नेटवर्क्स तुकडे शांतपणे टाकून देतात, आणि काही मधले उपकरण पहिला तुकडा हाताळते पण बाकीचे नाही। अनुप्रयोगाच्या दृष्टीने तिन्ही प्रकरणे सारखीच दिसतात।

NAT ओलांडणी तिसरे चल जोडते, कारण तेव्हा ESP UDP मध्ये गुंडाळले जाते आणि बाहेरील पॅकेट मोठे होते, त्याचवेळी ते पोर्ट 4500 वर साधारण UDP रहदारीसारखे दिसते। UDP चांगले पाठवणारा मार्गही आता न मावणाऱ्या डेटाग्रामवर अपयशी ठरू शकतो।

अपयशी देवाणघेवाण वाचा

त्रुटीऐवजी संक्रमण शोधा। पहिली देवाणघेवाण पाठवली आणि उत्तर दिली, आणि त्यानंतर काहीही नाही असे दाखवणारा लॉग तुम्हाला सांगतो की पुढील संदेश कधीच पूर्ण झाला नाही। लॉग पातळी तात्पुरती वाढवा आणि दोन्ही बाजूंवर नोंदवलेल्या आकारांची तुलना करा।

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

मार्ग बदला, सर्टिफिकेट नाही

तोच क्लायंट, तेच सर्टिफिकेट आणि तेच कॉन्फिगरेशन दुसऱ्या नेटवर्कवरून तपासा। मोबाइल हॉटस्पॉट सहसा सर्वात स्वस्त दुसरा मार्ग असतो, आणि तो कार्यालयाच्या लिंकपेक्षा खरोखर वेगळा आहे, फक्त नावाने नाही।

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

काहीही संपादित करण्यापूर्वी देवाणघेवाण मोजा

साखळीचा आकार आणि मार्गाचा आकार मिळवा। दोन्ही संख्या हँडशेक काय पाठवू शकतो हे मर्यादित करतात, आणि दोन्ही मोजणे स्वस्त आहे:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

पहिले दोन सर्टिफिकेटची संख्या आणि फाइलचा आकार देतात, जो प्रमाणीकरण संदेश किती मोठा असेल याचा वाजवी निर्देशक आहे। ping तपासणी सांगते की त्या आकाराचा डेटाग्राम मार्गावर टिकतो का, आणि इंटरफेस काउंटर दाखवतात की तुमच्या बाजूला तुकडे टाकले गेले का। Windows वर समतुल्य तपासणी म्हणजे do-not-fragment ध्वज आणि स्पष्ट पेलोड आकार असलेली ping।

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

खरोखर तुटलेला स्तर दुरुस्त करा

मार्ग मोठे डेटाग्राम टाकून देत असेल, तर दोन्ही बाजूंवर IKE फ्रॅगमेंटेशन सुरू करा आणि विस्तार केवळ सुचवला नाही तर वाटाघाटी झाला आहे याची खात्री करा। मार्ग IP स्तरावर तुकड्यांशी वाईट वागत असेल, तर दुरुस्ती तिथे किंवा बाहेरील इंटरफेसच्या MTU मध्ये आहे, सर्टिफिकेट साठवणीत नाही।

साखळी अनावश्यकरीत्या लांब असेल, तर ती बाजूला खरोखर आवश्यक असलेल्या मधल्या सर्टिफिकेटपर्यंत कापून टाका। क्लायंट आधीच विश्वास ठेवत असलेले मूळ काढणे वाजवी देखभाल आहे; मधले काढणे तसे नाही, आणि संदेश कमी करण्यासाठी पडताळणी बंद करणे पोहोचवण्याच्या समस्येची सुरक्षेच्या समस्येशी अदलाबदल करते।

कोणती यंत्रणा बदलली आणि त्यानंतर हँडशेक कसा दिसला हे लिहून ठेवा। पुढील घटना सहसा त्याच लक्षणासह दुसऱ्या नेटवर्कवर घडते, आणि ती नोंदच दोन तासांचे दहा मिनिटे करते।