जब IKEv2 TS_UNACCEPTABLE लौटाए, तब असली सबनेट की तुलना करें

TS_UNACCEPTABLE को कवरेज पर असहमति के रूप में पढ़ें, खराब प्रोफ़ाइल के रूप में नहीं। गेटवे कह रहा है कि दोनों पीयर इस बात पर सहमत नहीं हो सके कि यह टनल किन पतों को ढो सकती है। उस क्षण IKE SA पहले से ऊपर हो सकता है, इसीलिए क्लाइंट पीछे कोई चाइल्ड SA के बिना भी जुड़ा दिख सकता है। एक बार इसे इस तरह रखें, तो काम यांत्रिक हो जाता है। दोनों पक्षों के इच्छित प्रीफ़िक्स लिख लें, उन्हें एक ही दिशा में तुलना करें, और तब तक संकीर्ण करें जब तक वे प्रतिच्छेद न करें।

पहले इच्छित जोड़े लिखें

कॉन्फ़िगरेशन छूने से पहले चार मान सूचीबद्ध करें: आरंभकर्ता की स्रोत श्रेणी, उसकी गंतव्य श्रेणी, और वही जोड़ी उत्तरदाता की ओर से देखी गई। हर एक का पता-परिवार भी दर्ज करें। IPv4 श्रेणी और IPv6 श्रेणी अलग चयनकर्ता प्रकार हैं, और कोई भी दूसरे के पेलोड में मोड़ा नहीं जा सकता।

नीति जो भी प्रोटोकॉल या पोर्ट प्रतिबंध लेकर आती है, उसे जोड़ें। केवल TCP 445 को फ़ाइल सर्वर तक अनुमति देने वाला नियम, उस सबनेट से संकरा समुच्चय बताता है जिसमें वह बैठता है। इसे अपने नोट्स से बाहर छोड़ दें तो बातचीत का नतीजा ऐसे कारणों से असंगत दिखेगा जो आपको नहीं दिखते।

तुलना से पहले लेबल उलटें

स्थानीय और दूरस्थ सापेक्ष लेबल हैं। क्लाइंट का स्थानीय प्रीफ़िक्स गेटवे की दूरस्थ श्रेणी है, और गेटवे की स्थानीय श्रेणी क्लाइंट की दूरस्थ है। इसलिए दोनों सिरों के स्क्रीनशॉट कभी मेल नहीं खाते, और उन्हें शब्दशः तुलना करना दोपहर गँवाने का आम तरीका है।

उत्तरदाता अस्वीकार करने के बजाय प्रस्ताव को स्वीकार्य उपसमुच्चय तक संकीर्ण कर सकता है। वह नतीजा साफ़ विफलता से बुरा है, क्योंकि वह आधा-अधूरा काम करता है। जब नीति 10.0.5.0/24 की अनुमति देती है तब 10.0.0.0/16 माँगें, और आप केवल उसी /24 को ढकने वाले चाइल्ड SA पर पहुँच सकते हैं। एक होस्ट जवाब देता है, बाकी सब बाहर रह जाता है, और क्लाइंट में कुछ भी यह नहीं कहता। यह निष्कर्ष निकालने से पहले कि बातचीत सफल हुई, माँगे गए नहीं बल्कि स्वीकृत चयनकर्ता पढ़ें।

डिफ़ॉल्ट रूट माँगने वाली रोड-वॉरियर प्रोफ़ाइलें यहाँ लगातार आती हैं। विभाजित पहुँच के लिए बना गेटवे पूरी श्रेणी के प्रस्ताव को अपने सबनेट तक संकीर्ण करता है, और क्लाइंट को संकीर्ण परिणाम स्वीकार करना होगा या ज़ोर से विफल होना होगा।

एक ही प्रयास से अस्वीकृति पढ़ें

एक ही कनेक्शन प्रयास के दोनों लॉग इकट्ठा करें। सहेजी गई प्रोफ़ाइल दिखाती है कि आपने क्या कॉन्फ़िगर किया, यह नहीं कि क्या प्रस्तावित हुआ, और strongSwan पर swanctl --log प्राप्त सूचना को उसके साथ ले जाए गए चयनकर्ताओं के साथ छापता है।

फिर देखें कि असल में क्या स्थापित हुआ। swanctl --list-sas चाइल्ड SA के चयनकर्ता दिखाता है, और ip xfrm policy वही श्रेणियाँ कर्नेल नीति प्रविष्टियों के रूप में दिखाता है। उस सूची में ऐसे चयनकर्ताओं वाला चाइल्ड SA जो आपने नहीं चाहे थे, संकुचन की घटना है; लॉग में चाइल्ड SA के बिना TS_UNACCEPTABLE होना अस्वीकृति है।

वहाँ रहते हुए निकट पड़ोसियों को अलग करें। INVALID_SELECTORS स्थापित चाइल्ड SA के भीतर के चयनकर्ता की शिकायत करता है, जबकि INTERNAL_ADDRESS_FAILURE का अर्थ है कि उत्तरदाता वर्चुअल पता आबंटित नहीं कर सका, जो पूल की समस्या है, कवरेज की नहीं।

जाँचें कि क्या चुपचाप समुच्चय घटाता है

तीन चीज़ें बिना कुछ कहे चयनकर्ता समुच्चय घटा देती हैं। पहली उत्तरदाता की नीति है, सबनेट सूचियों, समूह नियमों या प्रति-उपयोगकर्ता प्राधिकरण के ज़रिए जो प्रस्ताव को उपसमुच्चय तक घटा देते हैं। दूसरा पता-परिवार है: दोहरे स्टैक वाला क्लाइंट अक्सर IPv4 के साथ IPv6 प्रस्तावित करता है और गेटवे द्वारा कभी कॉन्फ़िगर न की गई श्रेणियों के लिए अस्वीकृति पा लेता है।

तीसरी प्रोटोकॉल और पोर्ट प्रतिबंध हैं। जहाँ नीति केवल TCP 445 की अनुमति देती है, वहाँ चाइल्ड SA ऊपर आ सकता है जबकि ICMP और UDP उसके बाहर रहते हैं, और उपयोगकर्ता टूटी टनल की शिकायत करता है जबकि केवल एक ही प्रोटोकॉल अनुमत था।

इसलिए केवल पतों को चौड़ा करने से पोर्ट-सीमित नीति ठीक नहीं हो सकती, और यही वह मामला है जो तीन दौर की समस्या-निवारण के बाद भी अपरिवर्तित बचने की सबसे अधिक संभावना रखता है।

फ़िट होने वाले ट्रैफ़िक से कवरेज सिद्ध करें

चाइल्ड SA स्थापित होने के बाद, एक अनुरोध भेजें जो निश्चित रूप से स्वीकृत श्रेणियों के भीतर पड़े। स्थिति चिह्न के बजाय काउंटर देखें: ip -s xfrm state और ip xfrm policy के पीछे के काउंटर तब बढ़ते हैं जब पैकेट मिलान और सुरक्षित होता है। असली ट्रैफ़िक के बाद शून्य पर टिकी बाइट-संख्या का अर्थ है कि कर्नेल ने वह नीति कभी नहीं चुनी।

वह शून्य रूटिंग या नीति-क्रम की समस्या है, क्रिप्टो की नहीं। उपयोगकर्ता की जगह से यह चयनकर्ता अस्वीकृति जैसा ही दिखता है, इसलिए प्रोफ़ाइल दोबारा खोलने से पहले काउंटर जमा करना उचित है। केवल एक ही दिशा में बढ़ने वाले काउंटर इसके बजाय वापसी मार्ग की ओर इशारा करते हैं।

स्वीकृत जोड़ी को टिकट में लिखकर समाप्त करें, मूल रूप से माँगी गई श्रेणी के बगल में। चयन को आवश्यकता जितना संकरा रखें, क्योंकि निजी श्रेणी को सभी पतों से बदलकर त्रुटि हटाना खाते के लिए स्वीकृत से कहीं अधिक पहुँच देता है।