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 समूहका रूपमा अभिलेख गर्नुहोस्, त्यसपछि यसले सुरक्षित गर्नुपर्ने आदानप्रदानमा त्यसको पुष्टि गर्नुहोस्। राउटिङ, ट्राफिक चयनकर्ता र अनुप्रयोग अनुमतिहरू अलग रहन्छन्; यो मिलान पूर्ण गेटवे कन्फिगरेसन होइन, र विविधताका लागि थप एल्गोरिदम सक्षम गर्ने सिफारिस पनि होइन।