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-नूतनीकरण अपयश नाही.