IPsec रहदारी निवडक: ते काय व्यापतात आणि काय व्यापत नाहीत

रहदारी निवडक IPsec करार ज्या अंतर्गत रहदारीचे रक्षण करतो त्याला नाव देतात, आणि ती जोडी गृहीत न धरता वाटाघाटीतून ठरते। दोन टोके एकमेकांचे पूर्ण प्रमाणीकरण करू शकतात आणि तरीही कोणती पाकिटे बोगद्याच्या आत मोडतात यावर एकमत होऊ शकत नाहीत। ते मतभेद जोडणीच्या स्थितीत दिसत नाहीत, जी सहसा निरोगी बोगदा असे सांगते। निवडक दोन्ही टोकांकडून वाचून मग एका गंतव्याचा पाठलाग केल्यास कितीही धोरण संपादन करण्यापेक्षा ते लवकर सापडते।

ते दोन्ही टोकांकडून वाचा

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

मूल्ये नेहमी एकट्या उपजाळ्या नसतात। IKEv2 निवडक पत्ता-श्रेणी, प्रोटोकॉल क्रमांक आणि पोर्ट-श्रेणी वाहू शकतात, आणि अशा रीतीने धोरण संपूर्ण जाळ्याऐवजी एका सेवेचे रक्षण करते। इच्छित रहदारीपेक्षा अरुंद निवडक अशी बोगदा तयार करते जी काही गंतव्ये वाहते आणि बाकीची गुपचूप वगळते।

काहीही बदलण्यापूर्वी दोन्ही बाजू एका तक्त्यात लिहा। हा सराव सहसा संरचना-संचिकेला हात न लावता प्रश्न मिटवतो।

अरुंद करणे हा प्रतिसादकाचा निर्णय

आरंभकर्ता प्रस्ताव देतो, आणि प्रतिसादक फक्त उपसंच स्वीकारू शकतो। IKEv2 प्रतिसादकाला मांडलेले रहदारी निवडक अरुंद करण्याची परवानगी देतो, आणि अरुंद झालेला निकालच प्रत्यक्षात बसवला जातो। म्हणून आरंभकर्त्याची संरचना वाचणे हे प्रस्ताव वर्णन करते, करार नाही।

म्हणूनच ग्राहकाला जोडलेली उपजाळ चालणारा बोगदा तयार करूनही नवीन गंतव्य नाकारू शकते। सर्व्हरने आपल्या धोरणाला परवानगी असेल तितके प्रस्ताव अरुंद केले, तर ग्राहकाची संचिका अजूनही रुंद श्रेणी सूचीबद्ध करते। फक्त वाटाघाटीतून ठरलेली स्थिती सत्य दाखवते: Linux वर ip xfrm policy आणि strongSwan च्या IKEv2 दस्तऐवजातील child SA सूची मागितलेले नाही तर बसवलेले सांगते। दोन्ही वेगळे पडल्यास प्रतिसादकाचे धोरण बदलायचे असते।

नाकारलेला प्रस्ताव अरुंद झालेल्या प्रस्तावापेक्षा वेगळे लक्षण आहे। नाकारणे वाटाघाटी नोंदीत दिसते आणि कोणतेही child संबंध सोडत नाही।

एका गंतव्याचा सुरुवातीपासून शेवटपर्यंत पाठलाग करा

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

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

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

अनुप्रयोग अजूनही अपयशी होत असताना child मोजणी हलत असल्यास समस्या बोगद्यापलीकडे आहे। त्यामुळे तपास निवडकांकडे नाही तर दूरच्या यजमानाच्या श्रोत्याकडे किंवा फायरवॉलकडे सरकतो।

दोन्ही ध्येये वेगळी ठेवा

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

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