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 पछाडिका काउन्टर बढ्छन्। वास्तविक ट्राफिकपछि पनि शून्यमै रहने बाइट-सङ्ख्या भन्नाले कर्नेलले त्यो नीति कहिल्यै छानेन।
त्यो शून्य राउटिङ वा नीति-क्रमको समस्या हो, क्रिप्टोको होइन। प्रयोगकर्ताको ठाउँबाट त्यो छनोट अस्वीकृतिजस्तै देखिन्छ, त्यसैले प्रोफाइल फेरि खोल्नुअघि काउन्टर सङ्कलन गर्न लायक छ। एउटै दिशामा मात्र बढ्ने काउन्टरले बरु फर्किने बाटोतर्फ सङ्केत गर्छन्।
स्वीकारिएको जोडी टिकटमा, सुरुमा मागिएको दायराको छेउमा लेखेर अन्त्य गर्नुहोस्। छनोटलाई आवश्यकताजति साँघुरो राख्नुहोस्, किनकि निजी दायरालाई सबै ठेगानाले बदलेर त्रुटि हटाउनु खाताका लागि स्वीकृतभन्दा धेरै पहुँच दिन्छ।