AWS Site-to-Site VPN मध्ये MODP3072 कुठे बसतो
MODP3072 हा IANA चा गट 15 आहे, पण गट एका टप्प्याशी संबंधित आहे। टनेल संपादित करण्यापूर्वी आवश्यकता Phase 1 किंवा Phase 2 च्या DH याद्यांशी जुळवा।
कोणीतरी तुम्हाला अशी आवश्यकता पाठवतो ज्यात IKEv2, ESP आणि MODP3072 लिहिलेले असते, आणि कन्सोलमध्ये त्या नावाचे कोणतेही फील्ड नसते। असे फील्ड शोधायला जाणे ही चूक आहे। IKEv2 ही वाटाघाटीची आवृत्ती आहे, ESP हा तुमचा संरक्षित रहदारी वाहून नेणारा प्रोटोकॉल आहे, आणि MODP3072 हा की-एक्स्चेंज गट आहे, म्हणजे IANA चा गट 15। या तीन तथ्ये तीन वेगळ्या ठिकाणी राहतात, आणि गट दोन वेळा दिसतो।
हे वाक्य एकच सेटिंग नाही
काहीही स्पर्श करण्यापूर्वी आवश्यकता पर्याय याद्यांमध्ये रूपांतरित करा। खालील तक्ता हे संपूर्ण जुळणी आहे।
| Agreed requirement | AWS option to review | Still a separate decision |
|---|---|---|
| IKEv2 | Allowed IKE versions | Encryption, integrity, key-exchange choices |
| MODP3072 for the IKE exchange | Phase 1 DH groups, group 15 | Phase 2 key-exchange and PFS policy |
| MODP3072 for the protected-traffic exchange | Phase 2 DH groups, group 15 | The initial IKE exchange group |
| A named encryption algorithm | That phase's encryption list | Integrity and DH-group agreement |
MODP3072 हा गट 15 आहे, आणि AWS सध्या Phase 1 आणि Phase 2 या दोन्हींच्या DH गट याद्यांमध्ये 15 स्वीकारते। दोन्ही ठिकाणी तो स्वीकारणे हे दोन्ही ठिकाणी त्याची मागणी करण्यासारखे नाही, आणि याचा अर्थ तुमच्या भागीदाराने दोन्हीचा उद्देश ठेवला होता असा अजिबात नाही।
Phase 1 आणि Phase 2 वेगवेगळ्या गोष्टींवर वाटाघाटी करतात
Phase 1 IKE सुरक्षा संघटन तयार करते: दोन गेटवे एकमेकांना कसे प्रमाणित करतात, कींवर कसे सहमत होतात आणि स्वतःचा संवाद कसा संरक्षित करतात। Phase 2 तुमची प्रत्यक्ष रहदारी वाहून नेणारे CHILD SA तयार करते, आणि त्याची की-एक्स्चेंज वारसाहक्काने मिळालेली नसून नवीन असू शकते।
या विभाजनामुळेच भागीदार पूर्ण पुढे जाणाऱ्या गोपनीयतेबद्दल बोलतो तेव्हा ते महत्त्वाचे ठरते। PFS हा Phase 2 चा गुणधर्म आहे, आणि Phase 1 यादीतील गट तो देत नाही। प्रत्येक आवश्यकता कोणत्या एक्स्चेंजला लागू होते, सोबत एन्क्रिप्शन मोड, अखंडता AEAD सायफर देतो का, आणि दोन्ही बाजूंच्या की-नूतनीकरणाच्या अपेक्षा विचारा।
AES शब्दातून किंवा एका DH क्रमांकातून पूर्ण स्वीकार्य संच काढू नका। दोन संवादांच्या दोन अर्ध्या भागांतून जोडलेले धोरण हेच टनेल कोणत्याही संघाने मान्य न केलेले काहीतरी सुचवण्याचे कारण ठरते।
परवानगी दिलेली यादी वाटाघाटीचा निकाल नाही
पर्याय याद्या प्रत्येक बाजू काय स्वीकारण्यास तयार आहे हे वर्णन करतात। काय निवडले गेले हे त्या सांगत नाहीत। नवीन कनेक्शनसाठी प्रत्यक्षात निवडलेल्या IKE आणि CHILD-SA प्रस्ताव वाचा, नंतर आवश्यकता केवळ परवानगी दिलेली नसून पूर्ण झाली आहे याची खात्री करा। यादीत असलेला मजबूत पर्याय तो उपलब्ध होता एवढेच सिद्ध करतो।
नूतनीकरणाकडेही लक्ष द्या। पहिले IKEv2 CHILD SA आणि नंतरचे PFS असलेले CHILD एक्स्चेंज वेगवेगळ्या सुसंगतीच्या अटी दाखवू शकतात, कारण दुसरे एक्स्चेंज PFS गटासह नवीन की सामग्री तयार करते। तुमची स्वीकृती चाचणी टनेलच्या केवळ पहिल्या मिनिटाला व्यापत असेल, तर तिने तुमच्या भागीदाराला महत्त्वाचा भाग तपासलेला नाही।
AWS टनेल-पर्याय संदर्भ Phase 1 आणि Phase 2 स्वतंत्रपणे सूचीबद्ध करतो, आणि पुढील आवश्यकता येण्यापूर्वी ही रचना आत्मसात करण्यासारखी आहे।
खरोखर ज्या टनेलचा उद्देश आहे तीच बदला
Site-to-Site VPN कनेक्शनमध्ये स्वतःचे पर्याय आणि स्वतःची स्थिती असलेली दोन टनेल असतात। काहीही पुनरावलोकन किंवा संपादित करण्यापूर्वी AWS टनेलचा बाह्य पत्ता ग्राहक-गेटवे बाजूच्या पीअरशी जुळवा, आणि एक सेव्ह दोन्ही अद्ययावत करतो असे मानू नका।
मंजूर बदलासाठी ग्राहक-गेटवे बाजू त्याच धोरणासाठी तयार असणे आणि निवडलेल्या टनेलला जी व्यत्यय सहन करावा लागेल त्यासाठी एक वेळ खिडकी आवश्यक आहे। तुम्ही बदलत असलेल्या टप्प्यात पीअर गट 15 साठी तयार नसेल, तर टनेल वर येणे थांबवेल, आणि कोणत्या बाजूने नकार दिला हे कन्सोल सांगणार नाही।
सहमतीचे धोरण टप्पा, प्रोटोकॉल आवृत्ती, एन्क्रिप्शन, अखंडता आणि DH गट म्हणून नोंदवा, नंतर ते ज्या एक्स्चेंजचे संरक्षण करायचे आहे तिथे त्याची पुष्टी करा। राउटिंग, रहदारी निवडक आणि अनुप्रयोग परवानग्या वेगळ्या राहतात; ही जुळणी संपूर्ण गेटवे कॉन्फिगरेशन नाही, आणि विविधतेसाठी अतिरिक्त अल्गोरिदम सक्षम करण्याची शिफारसही नाही।