Windows र strongSwan: IKE प्रस्तावमा चार ट्रान्सफर्म मिलाउने
कुञ्जी आदानप्रदान समूहमा दुवै पक्ष सहमत नभए साझा साइफर पर्याप्त हुँदैन। चारै ट्रान्सफर्मको तुलना गर्नुहोस्, त्यसपछि एउटा सीमित प्रोफाइल नीति लागू गर्नुहोस्।
दुवै पक्ष AES लाई समर्थन गर्छन्, दुवैले SHA-256 स्वीकार गर्छन्, तर पनि सुरुङ माथि आउँदैन। प्रस्ताव कसैले तुलना नगरेको घटकमा असफल भयो, सामान्यतया कुञ्जी आदानप्रदान समूहमा। यो मार्गदर्शिकाले केही पनि बदल्नुअघि वास्तविक आदानप्रदान पढ्छ, एउटा सीमित नीति लागू गर्छ र अघिल्ला प्यारामिटर पुनर्स्थापित गर्ने रोलब्याक छोड्छ।
समूह बदल्नुअघि असफलता पढ्नुहोस्
«नीति मिलान त्रुटि» सारांश हो, निदान होइन। यसको अर्थ परस्पर स्वीकार्य कुनै प्रस्ताव भेटिएन, र कुन घटक अस्वीकृत भयो भन्ने बारे यसले केही बताउँदैन। यसलाई अनुसन्धानको सुरुवात मान्नुहोस्, कुनै विशेष समूहको प्रमाण होइन।
उत्तर सामान्यतया सर्भर पक्षमा हुन्छ। उपयुक्त तहको strongSwan लगले क्लाइन्टबाट प्राप्त प्रस्ताव र स्वीकार गर्न कन्फिगर गरिएको प्रस्ताव सूचीबद्ध गर्छ, र दुई सूचीको फरकले असफल घटकको नाम बताउँछ।
पुरानो फोरम पोस्टले भनेको कुरा क्लाइन्टले दिन्छ भनी नमान्नुहोस्। सक्रिय प्रोफाइल र त्यसमा स्थापित नीतिले प्रस्तावित सूची निर्धारण गर्छन्, र अद्यावधिक Windows बिल्डले तपाईंले प्रतिलिपि गरिरहनुभएको स्क्रिनसटको भन्दा फरक सेट दिन सक्छ।
दुवै सूची लेख्नुहोस्। चार ट्रान्सफर्म स्थान र एउटा समूह छोटो सूची हो, र यसलाई लाइन-लाइन तुलना गर्न कुनै पनि प्रयोगभन्दा कम समय लाग्छ। चार स्थान आँखासामु राख्न सजिलो छ। लग फाइल होइन।
एउटा परिचित नामको होइन, हरेक ट्रान्सफर्मको तुलना गर्नुहोस्
IKE प्रस्ताव भनेको सबै मिल्नुपर्ने विकल्पहरूको समूह हो। इन्क्रिप्शनले वार्तालापको रक्षा गर्छ, अखण्डता वा कुनै PRF ले त्यसलाई प्रमाणित गर्छ, र Diffie-Hellman समूहले नयाँ कुञ्जी सामग्री स्थापित गर्छ। पहिलो दुईमा मिल्ने र तेस्रोमा फरक पर्ने प्रस्ताव दुवै पक्षका लागि अझै अस्वीकार्य छ।
यहाँ भ्रमित हुने दुई Windows फिल्ड फरक चरणका हुन्। DHGroup IKE कुञ्जी आदानप्रदानमा लागू हुन्छ, जबकि PfsGroup ट्राफिकको रक्षा गर्ने चाइल्ड एसोसिएसनमा लागू हुन्छ। दोस्रो बदल्दा पहिलोको असफलता सुधार्न सकिँदैन।
समूहका नाम कार्यान्वयनहरूमा फरक हुन्छन्, र यो भ्रमको अलग स्रोत हो। strongSwan ले modp2048 र ecp256 लेख्छ, जबकि Windows ले Group14 र ECP256 जस्ता गणना नाम प्रयोग गर्छ, त्यसैले तुलना गर्नुअघि अनुवाद गर्नुपर्छ। दुवै नामसहित दुई स्तम्भको टिप्पणी राख्नुहोस्। त्यसपछि अर्को असंगति सेकेन्डमै वर्गीकृत हुन्छ।
| Transform | Windows parameter | strongSwan name | Failure it causes |
|---|---|---|---|
| Encryption | CipherTransformConstants | aes, aes256gcm and similar | No common proposal at all |
| Integrity or PRF | AuthenticationTransformConstants | sha256, sha512 and similar | Proposal rejected after encryption matches |
| Key-exchange group | DHGroup | modp2048, ecp256 | Exchange fails during key establishment |
| Child SA protection | PfsGroup | esp proposal groups | Tunnel negotiates, data association does not |
एउटा पूर्ण र सीमित नीति लागू गर्नुहोस्
मूल IKEv2 प्रोफाइलका लागि समर्थित साधन प्रति-जडान IPsec नीति हो, जुन फिल्ड-फिल्ड होइन, एउटा वस्तुका रूपमा सेट गरिन्छ। पहिले पूर्वावलोकन गर्नुहोस्, त्यसपछि लागू गर्नुहोस्, र अघिल्ला प्यारामिटर परिवर्तन अभिलेखमा राख्नुहोस्।
Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf-WhatIf स्विचले स्थानीय परिवर्तनको पूर्वावलोकन देखाउँछ र केही लागू गर्दैन। यो उपयोगी छ र साथै सामान्य जाल पनि हो, किनकि पूर्वावलोकनले प्यारामिटरहरू स्थानीय cmdlet का लागि वाक्यरचनाका हिसाबले स्वीकार्य छन् भन्ने मात्र प्रमाणित गर्छ। गेटवेले नतिजा प्रस्ताव स्वीकार्छ कि स्वीकार्दैन भन्ने यसले बताउँदैन।
त्यहीँ हुँदा दायरा पनि मिलाउनुहोस्। सबै प्रयोगकर्ताको भण्डारमा रहेको जडानलाई सम्बन्धित सबै-प्रयोगकर्ता प्यारामिटर चाहिन्छ, र त्यही देखिने नामसहित प्रति-प्रयोगकर्ता प्रोफाइल सम्पादन गर्दा सुरुङले प्रयोग नगर्ने अर्को वस्तु बदलिन्छ।
त्यसपछि परीक्षणअघि strongSwan पक्षलाई पनि त्यही सेटमा ल्याउनुहोस्। दुवै छेउमा समन्वित परिवर्तन नै यसको एकमात्र संस्करण हो जो अभिसरण हुन्छ; एउटा पक्ष बदलेर पटक-पटक पुनः प्रयास गर्दा त्यही अस्वीकृतिले भरिएको लग बन्छ।
आदानप्रदान र कुञ्जी नवीकरण छुट्टाछुट्टै जाँच्नुहोस्
सफल जडान एउटा अवलोकन हो, र कुञ्जी नवीकरण अर्को। प्रारम्भिक IKE वार्ताले एउटा प्यारामिटर सेट प्रयोग गर्छ, र ट्राफिक बोक्ने चाइल्ड एसोसिएसन पछि आफ्नै नीतिसहित पुनः वार्ता गर्न सकिन्छ। जोडिएर केही समयपछि खस्ने सेटअप सामान्यतया दोस्रो केस हो।
ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *पहिलो आदेशले स्थापित एसोसिएसनबारे सर्भरको दृष्टिकोण देखाउँछ, जसमा चाइल्ड SA र त्यसको बाँकी आयु समावेश छ। दोस्रोले क्लाइन्ट प्रोफाइलमा अहिले के छ देखाउँछ, र तपाईंले सेट गरेको नीति नै प्रभावकारी नीति हो भनी पुष्टि गर्ने एकमात्र उपाय त्यही हो।
सफलता घोषणा गर्नुअघि पूर्ण कुञ्जी नवीकरण हेर्नुहोस्। यसको अर्थ चाइल्ड एसोसिएसन बदलिने जति समय जडान माथि राख्नु र त्यसपछि ट्राफिक जारी छ भनी पुष्टि गर्नु हो। अधिकांश नीति असंगति त्यही चरणमा लुकेका हुन्छन्, किनकि प्रारम्भिक वार्ता नवीकरणले स्वीकार नगर्ने सेटसँग पनि सफल हुन सक्छ।
रोलब्याक अघिल्लो प्यारामिटर सेट हो, ढिलो विकल्प होइन। यदि क्लाइन्टले कमजोर पुरानो समूह मात्र दियो भने, उत्तर क्लाइन्ट र सर्भरको साझा नीति सुधार्नु हो, त्यो समूहलाई गेटवेमा थप्नु होइन जहाँ भविष्यको हरेक पक्षले त्यसतर्फ तल वार्ता गर्न सक्नेछ।
चार प्यारामिटर, समूह, जडानको दायरा र कुञ्जी नवीकरणको नतिजा अभिलेख गर्नुहोस्। यो छोटो टिप्पणी हो, र मार्गदर्शिका र सुरुङ एकचोटि माथि आएको कथा बीचको फरक त्यही हो।