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 समूह के रूप में दर्ज करें, फिर उन विनिमयों पर उसकी पुष्टि करें जिनकी उसे रक्षा करनी है। रूटिंग, ट्रैफ़िक चयनक और अनुप्रयोग अनुमतियाँ अलग रहती हैं; यह मिलान पूर्ण गेटवे कॉन्फ़िगरेशन नहीं है, और विविधता के लिए अतिरिक्त एल्गोरिदम सक्षम करने की सिफ़ारिश भी नहीं है।