Windows र strongSwan साइफर: सही तह मिलाउनुहोस्

दुवै छेउले AES-128 भन्छन् र सुरुङ अझै बन्न मान्दैन। CBC र GCM फरक रूपान्तरण हुन् जसले संयोगवश एउटै की लम्बाइ साझा गर्छन्, र एउटा प्रस्ताव गर्ने क्लाइन्टले अर्को मात्र स्वीकार गर्ने गेटवेलाई सन्तुष्ट पार्दैन। AES शब्दले एउटा परिवार वर्णन गर्छ, सम्झौता होइन।

दोस्रो अक्ष पनि छ, र अलमल्याउने त्रुटिहरू त्यहीले उत्पन्न गर्छ।

दुई तह, दुई स्वतन्त्र सूचीहरू

IKE आफैं वार्तालापको रक्षा गर्छ, जबकि चाइल्ड एसोसिएसनले तपाईंलाई साँच्चै महत्त्वपूर्ण ट्राफिकको रक्षा गर्छ। Windows पहिलोलाई इन्क्रिप्सन विधि र अखण्डता विधिका रूपमा, र दोस्रोलाई साइफर तथा प्रमाणीकरण रूपान्तरण स्थिरांकका रूपमा देखाउँछ। ती क्षेत्रहरू एकअर्काका उपनाम होइनन्, र एउटामा मान्य मान अर्कोमा अर्थहीन वा गलत हुन सक्छ। यो विभाजन मनमा राखेर प्रोफाइल पढ्दा धेरैजसो अलमल हट्छ।

व्यावहारिक परिणाम यो हो कि तपाईंसँग पूर्ण रूपमा स्वीकार्य की-आदानप्रदान नीति र साथीले स्वीकार नगर्ने डेटा-च्यानल नीति हुन सक्छ। एउटा सूचीले वार्ता गर्छ; अर्कोले प्याकेटको रक्षा गर्छ। कन्फिगरेसन संवादमा दुवै जतिसुकै समान देखिए पनि पहिलोमा मान बदल्नुको अर्कोमा कुनै प्रभाव पर्दैन।

गेटवेसँग तुलना गर्नुअघि दुवै सूची लेख्नुहोस्। सम्झनाबाट गरिएको तुलना भनेको एउटा क्षेत्र दुई पटक सम्पादन गर्ने र अर्को कहिल्यै नगर्ने तरिका हो। प्रोफाइलको छेउमा गेटवे कन्सोल खुला राख्नुहोस्।

त्रुटि प्रस्तावहरूको छेउमा पढ्नुहोस्

असफल भएको चरणले कुन सूची जाँच्ने भनेर बताउँछ। सुरुवाती की-आदानप्रदानका क्रममा अस्वीकृति IKE प्रस्तावको समस्या हो, र यो कुनै पनि चाइल्ड एसोसिएसन अस्तित्वमा आउनुअघि नै हुन्छ। संरक्षित-ट्राफिक एसोसिएसनमा वार्ता हुँदै गर्दाको असफलता ESP प्रस्तावको समस्या हो, र की-आदानप्रदान पहिले नै सफल भइसकेको छ। क्लाइन्टको सामान्य नीति-मिलान सन्देशले दुवैमध्ये कुनै चरणको नाम लिँदैन, त्यसैले गेटवेकै दृष्टिकोण उपयोगी हुन्छ।

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

प्राप्त प्रस्ताव, कन्फिगर गरिएको प्रस्ताव र छानिएको प्रस्तावको तुलना गर्नुहोस् त्यही एउटा प्रयासका लागि। यहाँ तीन फरक सूचीहरू महत्त्वपूर्ण छन्, र वास्तवमा के प्रयोग भयो भन्ने अन्तिमले मात्र बताउँछ। सारांश बनाउनुको सट्टा टिकटमा यसलाई शब्दशः उद्धृत गर्नुहोस्।

CBC र GCM लाई अलग विकल्पका रूपमा राख्नुहोस्

कुनै पनि परिवार स्वीकार गर्न जानाजानी अनुमति दिइएको गेटवेलाई एउटा होइन, दुई प्रस्ताव चाहिन्छ। strongSwan मा अल्पविरामले विकल्पहरू अलग गर्छ, र हाइफनले एउटै सेटका घटकहरू जोड्छ। दुवै परिवारलाई हाइफनले जोड्दा दुई स्वीकार्य प्रस्तावको सट्टा एउटा असम्भव प्रस्ताव बन्छ।

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

पहिलो विकल्पले प्रमाणित इन्क्रिप्सन बोक्छ र अझै पनि स्युडो-अनियमित फङ्सनको नाम लिन्छ, किनकि अखण्डता साइफरबाट आए पनि की व्युत्पत्तिलाई एउटा चाहिन्छ। दोस्रो विकल्प अलग अखण्डता एल्गोरिदमसहितको परम्परागत इन्क्रिप्सन हो। दुवै लोड गरिएको क्रिप्टो कार्यान्वयनले के समर्थन गर्छ भन्नेमा निर्भर छन्।

ESP प्रस्ताव पुनर्नामित IKE प्रस्ताव होइन

साइफर टोकन दुवै सूचीमा उस्तै देखिन्छ, र अरू लगभग केही पनि सर्दैन। ESP प्रस्तावमा की-आदानप्रदानको स्युडो-अनियमित फङ्सन हुँदैन, र यसको अखण्डता तथा अगाडिको गोपनीयताका आवश्यकताहरू IKE लाइनबाट प्रतिलिपि गर्नुको सट्टा अर्कोतर्फको Windows नीतिविरुद्ध तर्क गरिन्छ। एउटा सूचीलाई अर्कोमा यान्त्रिक रूपमा अनुवाद गर्दा मान्यता पाउने तर कहिल्यै वार्ता नगर्ने कुरा बन्छ।

एउटा दिशा छान्नुहोस् र त्यसमै रहनुहोस्। या त गेटवेले GCM-मात्र नीति राख्छ र क्लाइन्टले पूर्ण अनुकूल नीति तैनाथ गर्छ, वा गेटवेले दुवै परिवार स्वीकार गर्छ र क्लाइन्टले आफ्नो विद्यमान सेट राख्छ। सुरक्षा नीतिले निषेध गरेको फलब्याक सक्षम गर्नु त्रुटि जतिसुकै छिटो हटाए पनि समाधान होइन।

दुवै सेट प्रमाणित गर्नुहोस्, त्यसपछि की नवीकरण

छानिएको की-आदानप्रदान सेट र छानिएको ट्राफिक सेट अलग-अलग पुष्टि गर्नुहोस्, किनकि ती फरक सूचीबाट आउँछन् र स्वतन्त्र रूपमा सफल हुन सक्छन्। त्यसपछि की नवीकरण हुन दिनुहोस् र त्यसलाई पनि पुष्टि गर्नुहोस्। काम गर्ने पहिलो ह्यान्डशेक र असफल हुने की नवीकरणले आंशिक रूपमा मात्र स्वीकार्य प्रस्ताव-सेटको वर्णन गर्छन्।

त्यो प्रमाण परिवर्तनसँगै राख्नुहोस्। बारम्बार हुने जडान विच्छेदनलाई कसैले टाइमर वा प्लेटफर्म दोषलाई दोष दिनुअघि आफ्नै असफल-आदानप्रदान रेकर्ड चाहिन्छ।