जेव्हा 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 ला परवानगी देते, तिथे ICMP आणि UDP बाहेर असतानाही चाइल्ड SA वर येऊ शकते, आणि वापरकर्ता तुटलेल्या टनेलची तक्रार करतो जेव्हा फक्त एकच प्रोटोकॉलला परवानगी होती.
म्हणून केवळ पत्ते रुंदावल्याने पोर्ट-मर्यादित धोरण सुधारत नाही, आणि हाच तो प्रसंग आहे जो तीन फेऱ्या समस्या-निवारणानंतरही अपरिवर्तित राहण्याची सर्वाधिक शक्यता ठेवतो.
जुळणाऱ्या रहदारीने कव्हरेज सिद्ध करा
चाइल्ड SA स्थापित झाल्यावर, स्वीकारलेल्या श्रेणींच्या आत निश्चितपणे पडणारी एक विनंती पाठवा. स्थिती चिन्हाऐवजी काउंटर पहा: पॅकेट जुळून संरक्षित होतो तेव्हा ip -s xfrm state आणि ip xfrm policy मागील काउंटर वाढतात. खऱ्या रहदारीनंतरही शून्यावर राहणारी बाइट-संख्या म्हणजे कर्नेलने ते धोरण कधीच निवडले नाही.
ते शून्य ही राउटिंग किंवा धोरण-क्रमाची समस्या आहे, क्रिप्टोची नाही. वापरकर्त्याच्या जागेवरून ते निवडक नकारासारखेच दिसते, म्हणून प्रोफाइल पुन्हा उघडण्यापूर्वी काउंटर गोळा करणे योग्य आहे. एका दिशेनेच वाढणारे काउंटर त्याऐवजी परतीच्या मार्गाकडे निर्देश करतात.
स्वीकारलेली जोडी तिकिटात, मूळ मागितलेल्या श्रेणीच्या शेजारी लिहून पूर्ण करा. निवड आवश्यकतेइतकी अरुंद ठेवा, कारण खाजगी श्रेणी सर्व पत्त्यांनी बदलून त्रुटी काढणे खात्यासाठी मंजूर केलेल्यापेक्षा कितीतरी जास्त प्रवेश देते.