IPsec सुरक्षा धोरण रूट टेबलमधील नोंद का नाही

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

टेबलपासून नाही, लुकअपपासून सुरुवात करा

कर्नेलला विचारा ते खरेच काय करेल: ip route get 10.20.0.5 निवडलेला रूट, बाहेर जाणारा इंटरफेस आणि वापरणारा स्रोत पत्ता छापते। प्रीफिक्स, धोरण नियम, मार्क किंवा पसंतीचा स्रोत हे सर्व ते उत्तर बदलू शकतात, म्हणून जिवंत लुकअप डोळ्यांनी टेबल वाचण्यापेक्षा चांगला।

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

दोन्ही बाजूंनी सिलेक्टर जुळवा

धोरण डेटाबेसला स्वतःच्या नोंदी असतात, आणि प्रत्येक दिशा, स्रोत, गंतव्य आणि प्रोटोकॉल सांगून, जुळणाऱ्या पॅकेट्सना काय व्हायचे ते सांगते। त्या यादी करण्यासाठी ip xfrm policy वापरा; कृती संरक्षण, बायपास की ब्लॉक हे फ्लॅग दाखवतात। ज्या धोरणाचे सिलेक्टर तुमच्या चाचणी प्रवाहापेक्षा रुंद किंवा अरुंद आहेत ते त्याला जुळणार नाही, आणि पॅकेट असंरक्षित बाहेर पडते। तुम्ही शोधत असलेली हीच बिघाड आहे, गहाळ रूट नाही।

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

धोरण जुळणे म्हणजे स्थापित स्थिती नाही

जुळणारे धोरण फक्त पॅकेट संरक्षित व्हायला हवे असे सांगते; संरक्षण करण्यासाठी कर्नेलला अजूनही सुरक्षा असोसिएशन लागते। ती ip xfrm state ने यादी करा, किंवा strongSwan बोलणी करत असेल तर swanctl --list-sas ने, आणि प्रत्येक नोंदीवरील सिलेक्टर आणि काउंटर वाचा।

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

रूट-आधारित टनेलला अजून काय लागते

XFRM इंटरफेस टनेलला तुम्ही रूट करू शकता अशा उपकरणासारखे दाखवतो, जे खरोखर उपयुक्त आहे। पण पॅकेट तिथे पोहोचल्यावर काय होते हे ठरवणारे धोरण आणि स्थिती तो काढून टाकत नाही। रूट फक्त पुढील हॉप देतो, त्याहून अधिक नाही।

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

काहीही संपादित करण्यापूर्वी मालकी स्पष्ट करा

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

कॉन्फिगरेशनची मालकी तुमची दुरुस्ती रीस्टार्टनंतर टिकेल का हे ठरवते। एक घटक स्थिती स्थापित करू शकतो तर दुसरा रूट व्यवस्थापित करतो, आणि दुसऱ्यावरील हाताने केलेले संपादन टनेल पुढच्या वेळी वर येतेवेळी पुन्हा लिहिले जाते। मालक कॉन्फिगरेशन बदला, नंतर दोन्ही दृश्ये पुन्हा वाचा; RFC 4301 हे विभाजन दुसऱ्या कोणाला समजावावे लागल्यास दोन्ही डेटाबेस वेगळे ठेवते।