अनेक सबनेट असलेला IPsec परतीचा रहदारी गमावतो? reqid मोजा

रहदारी एका ठिकाणाहून निघते आणि कधीही परत येत नाही, दोन्ही गेटवे पूर्ण झालेल्या वाटाघाटीचा अहवाल देतात, आणि एकमेव सुगावा म्हणजे उत्तरांशिवाय बाहेर जाणाऱ्या पॅकेटचा ढीग. Linux एंडपॉइंटवर नेहमीचे कारण एन्क्रिप्शनची ताकद, MTU किंवा राउटिंग तक्ता नाही. ते धोरण नोंदींची सूक्ष्मता आणि प्रत्येक धोरणाला सुरक्षा संलग्नतेशी जोडणारी संख्या आहे. खालील प्रक्रिया दुसरे काही स्पर्श करण्यापूर्वी ते दोन्ही डेटाबेस वाचते.

काहीही बदलण्यापूर्वी लक्षण वेगळे करा

पूर्ण झालेल्या IKE वाटाघाटीसह एकतर्फी बिघाड समस्या डेटा मार्गापर्यंत मर्यादित करतो. एकतर बाहेर जाणारे धोरण जुळले आणि उत्तर फेकून दिले गेले, किंवा उत्तर कधीच पोहोचले नाही कारण दुसऱ्या बाजूकडे ते पाठवण्याचे काही नव्हते. एखाद्या अनुप्रयोगातून दोन्ही सारखेच दिसतात, आणि xfrm डेटाबेस त्यांना वेगळे करतात.

MTU ने सुरुवात करू नका. चुकीचा MTU अडकणे आणि तुकडे होण्याची लक्षणे निर्माण करतो, वाढणाऱ्या बाहेर जाणाऱ्या काउंटरसह स्वच्छ दिशा विभाजन नाही.

धोरण डेटाबेस आणि स्थिती डेटाबेस वाचा

Linux मध्ये एन्क्रिप्शन धोरण नोंदी ठरवतात, म्हणून जुळणारे धोरण, मार्ग नाही, पॅकेट बोगद्यात टाकते. ip xfrm policy चालवा जेणेकरून प्रत्येक नोंदीचे निवडक, दिशा, प्राधान्य आणि साचा दिसेल, आणि ip xfrm state जेणेकरून प्रस्थापित संलग्नता त्यांच्या reqid सह दिसतील. धोरण आणि संलग्नता त्याच reqid ने जोडली जाते.

तीनही दिशा पहा. बाहेर जाणे आणि आत येणे या यजमानाकडे आणि येथून रहदारी व्यापते; पुढे पाठवण्याची दिशा तेव्हा महत्त्वाची असते जेव्हा यजमान इतरांसाठी मार्ग करतो. एका दिशेने गहाळ किंवा न जुळणारी नोंद कोणत्याही क्रिप्टोग्राफिक दोषाशिवाय एकतर्फी निकाल स्पष्ट करते.

अभिजात असमानता: अनेक सबनेटसाठी एक reqid

सामान्य बिघाड अशा सहकाऱ्याकडून येतो जो सर्व ठरलेल्या सबनेटची धोरणे एकाच reqid खाली स्थापित करतो, जे racoon च्या generate_policy require सह घडते. रहदारी नंतर शेवटी प्रस्थापित संलग्नतेतून बाहेर जाते, तर दुसरी बाजू प्रत्येक सबनेटसाठी वेगळी संलग्नता ठेवते. उत्तरे अशा संलग्नतेवर येतात जिचे reqid ते धोरण दर्शवत नाही ज्याने ती स्वीकारायला हवी होती, आणि कर्नल डिक्रिप्शननंतर ती फेकून देतो.

दुरुस्ती ही संरचना बदल आहे, फायरवॉल नियम नाही: generate_policy unique; प्रत्येक धोरणाला त्याचे स्वतःचे reqid देते, त्यामुळे सहकाऱ्याच्या प्रति-धोरण संलग्नतांना जुळणारे भागीदार मिळतात. ते लागू करा, पुन्हा वाटाघाटी करा, आणि यश जाहीर करण्यापूर्वी अपेक्षित सबनेटसाठी वेगळे reqid मोजा.

जर दोन सबनेट अजूनही एक reqid सामायिक करतात आणि दुसरी बाजू दोन अपेक्षित ठेवते, तर तुम्हाला असमानता सापडली. मॅपिंग नोंदवा, कारण पुढील बदलाने ती दुरुस्त केली किंवा टिकवली याचा हा पुरावा आहे.

निवडक वाटाघाटीतून येतात, तुमच्या संरचनेतून नाही

संरक्षित श्रेणी म्हणजे दोन्ही टोकांनी मान्य केलेले, एका बाजूने मागितलेले नाही. जो क्लायंट रुंद दूरच्या श्रेणीसमोर यजमान-जोडी सादर करतो त्याला गेटवेची अरुंद आवृत्ती मिळते, आणि क्लायंट ती रुंद करू शकत नाही. स्थापित निवडक वाचा, तुमच्या स्थानिक फाइलमधील नाही.

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

या क्रमाने पडताळा, आणि कसे मागे हटायचे ते जाणा

प्रत्येक सबनेटसाठी दोन्ही दिशांनी धोरणे सूचीबद्ध करा, यजमान मार्ग करत असल्यास पुढे पाठवण्याची दिशा समाविष्ट करा. वेगळे reqid मोजा आणि अपेक्षा करणाऱ्या बाजूने प्रति-धोरण एकाची खात्री करा. स्थापित निवडकांची ठरलेल्या निवडकांशी तुलना करा. की नूतनीकरणानंतर प्रति-संलग्नता काउंटर पुन्हा वाचा, कारण तपासलेली संलग्नता आधीच गेलेली असू शकते. मार्ग सर्वात शेवटी तपासा, कारण दूरच्या सबनेटचा गहाळ मार्ग स्वच्छ धोरण काउंटरसह तत्सम एकतर्फी लक्षण निर्माण करतो.

सहकारी बदलण्यापूर्वी दोन्ही xfrm आदेशांचे सध्याचे आउटपुट जतन करा. जर नवीन सेटिंग परतीची दिशा पुनर्संचयित करत नसेल, तर ते आउटपुट पुनर्संचयित करणे स्मरणातून बोगदा पुन्हा बांधण्यापेक्षा जलद माघार आहे, आणि तुलना प्रामाणिक ठेवते.