FortiGate Azure पुनःकुञ्जी: peer SA प्रस्ताव स्थानीय नीतिसँग मेल खाँदैन

सुरुङ माथि आयो, ट्राफिक बह्यो, र पछि लग भन्छ peer SA proposal not match local policy. धेरै मानिसले त्यो हरफलाई दुई कन्फिगरेसन कहिल्यै मिलेनन् भन्ने प्रमाणका रूपमा पढ्छन्। सामान्यतया यसको अर्थ अझ साँघुरो हुन्छ: तिनीहरू पहिलो CHILD SA का लागि मिले र पहिलो नवीकरणमा मिल्न छोडे, किनकि पहिलो संगठनलाई पछिकाले गर्ने आदानप्रदान कहिल्यै आवश्यक परेन। यही भिन्नताले तपाईं कहाँ हेर्ने भन्ने निर्धारण गर्छ।

पहिलो CHILD SA उत्तराधिकारमा पाउँछ, पछिका वार्ता गर्छन्

IKEv2 मा सुरुवाती CHILD SA IKE_AUTH का क्रममा सिर्जना हुन्छ, र यसका कुञ्जीहरू IKE SA को कुञ्जी सामग्रीबाट व्युत्पन्न हुन्छन्। त्यस क्षणमा छुट्टै Diffie-Hellman आदानप्रदान हुँदैन, त्यसैले एक peer ले स्वीकार गर्न नसक्ने PFS समूह अझै परीक्षण गरिँदैन। सुरुङ स्वस्थ देखिन्छ किनकि तपाईं पछि असफल हुने आवश्यकता कहिल्यै परीक्षण गरिएको थिएन।

CHILD_SA पुनःकुञ्जी फरक सन्देश क्रम हो। PFS कन्फिगर गरिएको बेला, peer हरू नयाँ कुञ्जी आदानप्रदान गर्छन् र दुवै पक्षले स्वीकार गर्ने समूह, साथै नयाँ संगठनका लागि ESP प्रस्तावमा सहमत हुनुपर्छ। असहमति देखिने क्षण त्यही हो, र त्यसैले त्रुटिले मार्गको सट्टा प्रस्तावको नाम लिन्छ।

त्यसैले “हिजो यो चल्थ्यो” ले प्रस्तावबारे तपाईंलाई केही बताउँदैन। यसले सुरुवाती आदानप्रदान सफल भयो भनी बताउँछ, जुन तपाईंलाई पहिले नै थाहा थियो।

असफल आदानप्रदान पढ्नुहोस्, पहिलो ping होइन

केही बदल्नु अघि दुवै छेउबाट सफल IKE प्रमाणीकरण, सुरुवाती CHILD SA र असफल प्रतिस्थापन संकलन गर्नुहोस्। त्यसपछि कार्यलाई ठ्याक्कै नाम दिनुहोस्: IKE SA पुनःकुञ्जी, IKE पुनःप्रमाणीकरण र CHILD SA पुनःकुञ्जी तीन फरक घटना हुन्, र “चरण 2” ले साधारण कुराकानीमा ती सबै समेट्छ।

तलका क्षेत्रहरू असफल भएको जडानका लागि तुलना गर्नुहोस्, सुरुङका लागि सामान्य रूपमा होइन।

FortiGate मा त्यो सुरुङका लागि चरण-2 प्रस्ताव, PFS सेटिङ र स्वीकृत DH समूहहरू खोल्नुहोस्। पहिले स्थापित जडानबाट अनुमान गर्नुको सट्टा लोड गरिएका मानहरू पढ्नुहोस्। GUI पृष्ठको स्क्रिनसट चलिरहेको कन्फिगरेसनभन्दा कमजोर प्रमाण हो, किनकि अपग्रेडपछि दुवै फरक हुन सक्छन्। तपाईंले बदलेको खण्ड निर्यात गर्नुहोस् र टिकटसँग राख्नुहोस्।

Azure को पूर्वनिर्धारित नीति पनि एक नीति हो

जडानमा कुनै अनुकूलित नीति संलग्न नहुनुको अर्थ Azure ले कुनै पनि लागू गर्दैन भन्ने होइन। जडान गेटवेको पूर्वनिर्धारित प्रस्ताव-समूहमा फर्किन्छ, जो तपाईंको FortiGate ले दिनेभन्दा फराकिलो वा साँघुरो हुन सक्छ। यदि दुवै समूह IKE का लागि ओभरल्याप हुन्छन् तर PFS सहित ESP का लागि हुँदैनन् भने, तपाईंले ठ्याक्कै यही असफलता ढाँचा पाउनुहुन्छ।

यो पढ्ने-मात्र दृश्यले वास्तवमा संलग्न नीति देखाउँछ, रहस्य नखोली:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

आफ्ना वास्तविक स्रोत नामहरू प्रयोग गर्नुहोस्। स्पष्ट नीति आवश्यक हुँदा त्यसलाई जडान स्रोतमा सेट गर्नुहोस्। यो पूरै गेटवेको स्विच होइन, र एउटै गेटवेका अन्य सुरुङहरूमा चुपचाप लागू हुँदैन।

पोर्टलमा, त्यो जडानको Configuration पृष्ठ भनेको अनुकूलित IPsec/IKE नीति राखिने ठाउँ हो। Microsoft को अनुकूलित नीति मार्गदर्शिका ले समर्थित प्यारामिटर र SKU आवश्यकताहरू सूचीबद्ध गर्छ। Azure ले प्रत्येक जडानका लागि एउटा पूर्ण संयोजन लिन्छ, त्यसैले तपाईं IKE क्षेत्रहरू र IPsec क्षेत्रहरू सँगै निर्दिष्ट गर्नुहुन्छ, एक-एक गरेर होइन।

PFS एक आवश्यकता हो, पल्टाउने स्विच होइन

यदि तपाईंको सुरक्षा आधाररेखाले PFS माग्छ भने, समाधान भनेको दुवै पक्षका दुवै peer ले स्वीकार गर्ने समूह हो, जो मिल्ने नीतिमार्फत व्यक्त गरिन्छ। त्रुटि हराउन PFS बन्द गर्नु भनेको तपाईं जोगाउन खोजेको सुरक्षा गुण परिवर्तन गर्नु हो, र यो सामान्यतया पछि अर्को असहमतिका रूपमा फर्किन्छ।

Azure-विशेष एउटा जाल: ESP का लागि GCM छान्दा, इन्क्रिप्सन र अखण्डताका छनोटहरूले एउटै GCM एल्गोरिदम र एउटै कुञ्जी लम्बाइ नाम दिनुपर्छ। GCM साइफरलाई छुट्टै अखण्डता एल्गोरिदमसँग मिसाउँदा सेवाले अस्वीकार गर्ने संयोजन बन्छ, र नीति ध्यान दिएर नपढेसम्म त्यो peer असहमतिजस्तो देखिन्छ।

दुवै छेउले समर्थन गर्ने र तपाईंको आवश्यकताले अनुमति दिने सबैभन्दा बलियो संयोजन छान्नुहोस्, त्यसपछि त्यसलाई परिवर्तन-अभिलेखमा लेख्नुहोस्। अर्को व्यक्तिले त्यही अभिलेखसँग तुलना गर्नेछ, चलिरहेको सुरुङको सम्झनासँग होइन। त्यसमा PFS समूह र ESP प्रस्ताव राख्नुहोस्, केवल नीतिको नाम होइन। पछि कसैले लेखापरीक्षण किन असफल भयो वा पुनःकुञ्जी किन ढिलो छ भनी सोध्दा, त्यो हरफले दुवै प्रश्नको उत्तर दिन्छ।

असफल भएको आदानप्रदान प्रमाणित गर्नुहोस्

परिवर्तनलाई पुनःप्राप्ति मार्गसँग योजना गर्नुहोस्, किनकि नीति सम्पादन गर्दा तपाईं सुधार्न खोजेको सुरुङ अवरुद्ध हुन सक्छ। ट्राफिक फर्किएपछि CHILD_SA नवीकरणको प्रतीक्षा गर्नुहोस् वा त्यसलाई सुरु गर्नुहोस् र नयाँ संगठन इच्छित PFS समूहसँग स्थापित भएको पुष्टि गर्नुहोस्। त्यसपछि अनुप्रयोग ट्राफिक त्यसबाट जारी रहेको पुष्टि गर्नुहोस्।

दुई भ्रामक संकेतको नाम दिन लायक छ। SA आयु स्थानीय विशिष्टता हुन्, त्यसैले असमान मान सामान्य हुन् र ती बदल्दा समस्या कहिले देखिन्छ भन्ने मात्र सर्छ। DPD ले peer जीवित छ कि छैन पत्ता लगाउँछ; यसको समयसीमा बढाउँदा ESP वा PFS छनोटहरू मिल्दैनन्।

परिवर्तनपछि वार्ता भएको नतिजा र अर्को घटना रेकर्ड गर्नुहोस्। यदि जडान अब IKE प्रमाणीकरण पूरा हुनुअघि असफल हुन्छ भने, तपाईं भर्खरै सम्पादन गरेका IKE सेटिङहरू हेर्दै हुनुहुन्छ, मूल CHILD-नवीकरण असफलता होइन।