Windows र FortiGate मा IKEv2: मानिसहरूले जोड्ने तीन सेटिङ
IKE कुञ्जी आदानप्रदान, CHILD SA सुरक्षा र पीयर प्रमाणीकरण तीन अलग पङ्क्ति हुन्। दुई संवादमा समूह नम्बर मिले पनि तिनीहरू जोडिँदैनन्।
Windows क्लाइन्ट र FortiGate गेटवेबीचको IKEv2 सम्झौता बारम्बार असफल भइरहन्छ, र नमिल्ने नम्बरको खोजीले अझ लामो नम्बरको सूची बनाउँछ। सूची तब मात्र व्यवस्थापनयोग्य हुन्छ जब यसलाई स्वतन्त्र रूपमा असफल हुने तीन पङ्क्तिमा विभाजन गरिन्छ: IKE लाई सुरक्षित गर्ने कुञ्जी आदानप्रदान, CHILD SA मा लागू गरिने सुरक्षा, र प्रत्येक पक्ष को हो भनी प्रमाणित गर्ने प्रमाणीकरण। समूह नम्बर ती पङ्क्तिमध्ये दुईमा देखिन्छन् र फरक अर्थ राख्छन्।
स्वतन्त्र रूपमा असफल हुने तीन पङ्क्ति
पहिलो पङ्क्ति IKE भित्रको कुञ्जी आदानप्रदान हो, जसले वार्तालापलाई सुरक्षित गर्ने कुञ्जी उत्पादन गर्छ। दोस्रो CHILD SA का लागि प्रस्ताव हो, जसले सुरुङले बोक्ने ट्राफिकलाई सुरक्षित गर्छ। तेस्रो प्रमाणीकरण हो, जसले प्रत्येक पक्षले के प्रस्तुत गर्छ र अर्को पक्षले त्यसलाई कसरी प्रमाणित गर्छ भन्ने निर्धारण गर्छ।
असफलताहरू फरक ठाउँमा हुन्छन्। आदानप्रदानको असफलताले कुनै सुरुङ बन्नुअघि नै वार्तालाप रोक्छ। CHILD SA को असफलता प्रमाणीकरण सफल भएपछि हुन्छ, कहिलेकाहीँ कुञ्जी नवीकरणमा मात्र। प्रमाणीकरणको असफलता लगमा आदानप्रदानको असफलताजस्तो देखिन सक्छ, यदि तपाईं पहिलो त्रुटि मात्र पढ्नुहुन्छ।
पङ्क्ति अलग गर्नु लेखाजोखा होइन। यसले कुन सेटिङ परिवर्तन गर्न योग्य छ भनी बदल्छ, र यो सम्पूर्ण क्षेत्रको सबैभन्दा महँगो कदम रोक्छ, अर्थात् प्रस्तावको असमझदारी सुधार्न काम गर्ने प्रमाणपत्र पुनः उत्पादन गर्नु। एक पङ्क्तिको परिवर्तनले अरू दुईलाई आफूसँगै परिवर्तन गर्न बाध्य पार्नु हुँदैन। त्यही स्वतन्त्रता नै तिनीहरूलाई अलग लेख्नुको सम्पूर्ण उद्देश्य हो।
Windows का दुई फिल्डले के नियन्त्रण गर्छन्
Windows दुई फिल्ड अलग राख्छ: DHGroup ले IKE आदानप्रदान आफैं कन्फिगर गर्छ, जबकि PfsGroup ले सुरुङभित्रको ट्राफिक सुरक्षित गर्ने IPsec नीति कन्फिगर गर्छ। ती फरक चरणका हुन्। Windows को IKE फिल्डलाई FortiGate को चरण 2 मानसँग तुलना गर्नु गलत जोडी परीक्षण गर्नु हो, र नम्बर मिल्न सक्छन् तर आधारभूत आदानप्रदान अझै असफल हुन्छ।
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAदोस्रो र तेस्रो आदेशले वास्तवमै अवस्थित सुरक्षा सम्बद्धता रिपोर्ट गर्छन्, र यो क्लाइन्टले तपाईंलाई दिन सक्ने उत्तरको सबैभन्दा नजिकको कुरा हो। मुख्य मोड सम्बद्धता हुँदा पनि द्रुत मोड सम्बद्धता नहुनु CHILD SA को समस्या हो, र यो प्रमाणपत्रको समस्या नभई चरण 2 को असमझदारीको संकेत हो।
एक प्रयासमा के प्रस्ताव गरियो र के छानियो त्यो लेख्नुहोस्। स्वीकार्य प्रस्ताव भएको प्रस्ताव सूची र गेटवेको नीतिसँग नमिल्ने छानिएको प्रस्ताव कन्फिगरेसन असहमति हो, अन्तरसञ्चालनीयताको रहस्य होइन।
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
दीर्घवृत्तीय वक्रको समूहले तपाईंको हस्ताक्षर कुञ्जी छान्दैन
यस क्षेत्रको सबैभन्दा जिद्दी गलत अनुमान भनेको दीर्घवृत्तीय वक्रको DH समूह छान्न दीर्घवृत्तीय वक्रको प्रमाणपत्र आवश्यक हुन्छ भन्ने हो। DH समूहले कुञ्जी आदानप्रदानको सामग्री दिन्छ; हस्ताक्षर एल्गोरिदम प्रमाणीकरण ढाँचाले वार्ता गर्छ, र IKEv2 मा यी दुई अलग निर्णय हुन्।
RFC 7427 ती निर्णयहरू पहिले जोडिएका थिए भनेर नै अवस्थित छ, र हस्ताक्षर एल्गोरिदमहरू कुञ्जी आदानप्रदानबाट स्वतन्त्र रूपमा कसरी घोषणा र छनोट हुन्छन् भनी परिभाषित गर्छ। गेटवेले एकै समयमा वक्र समूह र हस्ताक्षर योजनाको छनोट दुवैलाई समर्थन गर्न सक्छ।
त्यसैले समूह परिवर्तनपछि वार्तालाप असफल भए, प्रमाणपत्रको कुञ्जी प्रकार हेर्नुअघि प्रमाणीकरण विधि हेर्नुहोस्। प्रमाणपत्र परिवर्तन गर्नु ढिलो र जोखिमपूर्ण कार्य हो जो विरलै उत्तर हुन्छ, र यसलाई पहिल्यै गर्नाले कुन परिवर्तनले साँच्चै मद्दत गर्यो भन्ने जान्ने क्षमता नष्ट गर्छ। प्रमाणपत्र भण्डार छुनुअघि प्रमाणीकरण पङ्क्ति पढ्नुहोस्।
दुवैलाई सम्झौता पत्रको अलग पङ्क्तिमा राख्नुहोस् र गल्ती प्रलोभनकारी रहन छोड्नेछ। एउटा पङ्क्तिले समूह सूचीबद्ध गर्छ, अर्कोले हस्ताक्षर योजना र पहिचान, र कुनै पनि अर्कोको प्रमाण होइन।
प्रत्येक निजी कुञ्जीलाई यसको वास्तविक मालिकसँग राख्नुहोस्
आफ्नै प्रमाणपत्र प्रस्तुत गर्ने गेटवेलाई त्यससँग मिल्ने निजी कुञ्जी चाहिन्छ। शृंखला प्रमाणित गर्ने पीयरलाई CA प्रमाणपत्र चाहिन्छ, र विशेष रूपमा CA को हस्ताक्षर कुञ्जी चाहिँदैन। यी तीन तत्व मिसाउनु नै मानिसहरूले प्रमाणपत्र अर्को श्रेणीमा देखाउन VPN उपकरणमा CA को निजी कुञ्जी आयात गर्ने कारण हो।
FortiOS मा भूमिका फरक छन्: कुञ्जीसहितको स्थानीय प्रमाणपत्र, पीयर पहिचान गर्न प्रयोग हुने दूरस्थ प्रमाणपत्र, र त्यो CA ले हस्ताक्षर गरेका प्रमाणपत्रमा विश्वास स्थापना गर्ने दूरस्थ CA प्रविष्टि। निजी कुञ्जी नभएको दूरस्थ CA प्रविष्टि अपूर्ण होइन; त्यो आफ्नो उद्देश्यका लागि सही छ।
आयात गरिएका CA हस्ताक्षर कुञ्जीले त्यो उपकरण पढ्न सक्ने जोसुकैको अधिकार फराकिलो बनाउँछन्। तिनले सामान्य पीयर प्रमाणीकरण पनि समाधान गर्दैनन्, किनकि प्रमाणीकरणलाई सार्वजनिक प्रमाणपत्र र विश्वासको निर्णय चाहिन्छ, नयाँ प्रमाणपत्र जारी गर्ने क्षमता होइन।
CA को हस्ताक्षर कुञ्जी जारीकर्ताको आफ्नै प्रक्रियामा राख्नुहोस्, र कुन उपकरणले कुन कुञ्जी राख्छ लेख्नुहोस्। अडिटले को-को रूप धारण गर्न सक्थ्यो भनी सोध्दा मालिकहरूको छोटो तालिका एल्गोरिदमको लामो तालिकाभन्दा बढी मूल्यवान हुन्छ। कसैले पनि आफूलाई थाहा भएको जम्मा सूचीका लागि मात्र भएको कुञ्जी आयात गर्दैन। घटनापछि होइन, अघि जम्मा सूची लेख्नुहोस्।