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 नीति रखता है और क्लाइंट पूरी संगत नीति तैनात करता है, या गेटवे दोनों परिवार स्वीकार करता है और क्लाइंट अपना मौजूदा सूट रखता है। सुरक्षा नीति जिस फ़ॉलबैक को मना करती है उसे सक्षम करना समाधान नहीं है, चाहे वह त्रुटि को कितनी भी जल्दी हटा दे।

दोनों सूट सत्यापित करें, फिर कुंजी नवीनीकरण

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

उस साक्ष्य को परिवर्तन के साथ रखें। बार-बार होने वाला डिस्कनेक्ट किसी के द्वारा टाइमर या प्लेटफ़ॉर्म दोष को दोषी ठहराने से पहले अपना विफल-एक्सचेंज रिकॉर्ड माँगता है।