FortiGate Azure रीकी: peer SA प्रस्ताव स्थानीय नीति से मेल नहीं खाता

सुरंग ऊपर आई, ट्रैफ़िक बहा, और बाद में लॉग कहता है peer SA proposal not match local policy. ज़्यादातर लोग उस पंक्ति को इस प्रमाण के रूप में पढ़ते हैं कि दोनों कॉन्फ़िगरेशन कभी मेल नहीं खाए। आम तौर पर इसका अर्थ कुछ संकरा होता है: वे पहले CHILD SA के लिए मेल खाए और पहले नवीनीकरण पर मेल खाना बंद कर दिया, क्योंकि पहले साहचर्य को कभी उस अदला-बदली की ज़रूरत नहीं पड़ी जो बाद वाले करते हैं। यही अंतर तय करता है कि आप कहाँ देखें।

पहला CHILD SA विरासत में लेता है, बाद वाले बातचीत करते हैं

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

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-नवीनीकरण विफलता नहीं।