सँगै काम गर्ने साइट-देखि-साइट VPN गेटवे कसरी छान्ने

फरक फरक आपूर्तिकर्ताका दुई साइट गेटवेले सुरुङ बनाउँछन् यदि तिनका कार्यान्वयनहरू वार्तामा तय हुने प्यारामिटरहरूमा सहमत हुन्छन्। एउटै ब्रान्ड सर्त होइन, र मिल्ने ब्रान्ड पनि ग्यारेन्टी होइन। अनुकूलताको प्रश्न विशेषता र संस्करणसँग सम्बन्धित छ; क्षमताको प्रश्न यन्त्रले सफ्टवेयरमा गर्नुपर्ने कामसँग सम्बन्धित छ। यिनलाई दुई जाँचका रूपमा, ठ्याक्कै त्यही क्रममा लिनुहोस्।

सूचीमा क्रमैसँग अघि बढ्नुहोस् र उत्तर नभएको पहिलो बुँदामा रोकिनुहोस्।

ब्रान्डबाट होइन, प्रोटोकलका विशेषताबाट सुरु गर्नुहोस्

तपाईंले चलाउन चाहेको प्रोटोकलका लागि डिजाइनलाई के चाहिन्छ सूचीबद्ध गर्नुहोस्: प्रमाणीकरण विधि, सहमत भएका इन्क्रिप्शन र अखण्डताका प्रस्ताव, इन्टरफेस वा संरक्षित ट्राफिकको संरचना, राउटिङ मोड र कुनै पक्ष NAT पछाडि छ कि छैन। यीमध्ये प्रत्येक कार्यान्वयनले समर्थन गर्नुपर्ने विशेषता हो, उत्पादन पृष्ठको चेकबक्स होइन।

AWS का ग्राहक गेटवे आवश्यकताहरू AWS सँग नजोडिए पनि उपयोगी ढाँचा हुन्, किनकि तिनले करारलाई प्रोटोकल र राउटिङका दायित्वहरूको समूहका रूपमा व्यक्त गर्छन्। कुनै निश्चित मोडेलका लागि आपूर्तिकर्ताको नमुना फाइल कसैले त्यो संयोजन परीक्षण गरेको सभ्य प्रमाण हो। IPsec समर्थनको दाबी गर्ने सामान्य लेबलले न संस्करण प्रमाणित गर्छ न नीति मोडेल। मार्केटिङ सारांशको सट्टा रिलिज नोट पढ्नुहोस्।

संस्करण जाँच्नुहोस्, डेटासिटको लेबल होइन

IKEv2 को अन्तरसञ्चालनीयता वार्तामा तय भएका प्यारामिटरहरूले निर्धारण गर्छ, त्यसैले प्रश्न यो हो कि हालको फर्मवेयरले कुन प्रस्ताव दिन्छ र स्वीकार गर्छ। सामान्य रूपमा प्रोटोकललाई समर्थन गर्ने यन्त्रले पनि तपाईंको अर्को छेउले जोड दिने विशिष्ट संयोजन अस्वीकार गर्न सक्छ। दुवै पक्षमा संस्करण स्ट्रिङ र प्रस्ताव सूची पुष्टि गर्नुहोस्।

कुनै विशेषता पछिको फर्मवेयर रेलमा आयो भन्ने टिप्पणी यति सामान्य छ कि त्यो आफ्नै चेकलिस्ट बुँदाको योग्य हुन्छ।

क्षमतालाई अलग प्रश्नका रूपमा लिनुहोस्

इन्क्रिप्शनले काम खर्च गर्छ, र कति भन्ने एल्गोरिदमजत्तिकै कार्यान्वयनमा पनि निर्भर छ। केही गति बढाउने मार्गहरू विशेष एल्गोरिदम वा विशेष फर्वार्डिङ मार्गमा मात्र लागू हुन्छन्, त्यसैले यन्त्र एउटा कन्फिगरेसनमा छिटो र अर्कोमा ढिलो हुन सक्छ। सामान्य WAN थ्रुपुट इन्क्रिप्टेड सुरुङको थ्रुपुट होइन। तपाईंले वास्तवमै संरक्षण गर्ने ट्राफिकअनुसार यन्त्रको मापन गर्नुहोस्।

प्याकेटको आकार पनि महत्त्वपूर्ण छ, किनकि इन्क्याप्सुलेसन र कुनै पनि अतिरिक्त ओभरहेडले प्रत्येक प्याकेटले बोक्ने पेलोड घटाउँछ।

राउटिङ नीति स्पष्ट रूपमा तय गर्नुहोस्

साइट-देखि-साइट भन्नाले चुनिएको ट्राफिकले मात्र सुरुङ प्रयोग गर्न पाउँछ भन्ने होइन, र सबैथोक अनिवार्य रूपमा प्रयोग गर्नुपर्छ भन्ने पनि होइन। डिजाइनले विशेष निजी प्रिफिक्सहरू बोक्न सक्छ, वा गेटवेबाट पूर्वनिर्धारित मार्ग पठाउन सक्छ। एउटा छान्नुहोस् र लेख्नुहोस्, किनकि दुवै छेउले के घोषणा गरिन्छ र के स्वीकार गरिन्छ भन्नेमा सहमत हुनुपर्छ। यहाँको असङ्गति उठेको सुरुङ र आधा पुग्ने सञ्जाल दिन्छ।

गतिशील राउटिङ भएका डिजाइनहरूले अर्को सर्त थप्छन्: दुवै छेउमा राउटिङ प्रोटोकलको समर्थन।

किन्नु अघि के तुलना गर्ने

अद्यावधिकको गति, अन्तरसञ्चालनीयताका प्रमाण, कन्फिगरेसनको पुनःप्राप्ति र इच्छित फेलओभर व्यवहारको तुलना उच्चतम स्थानान्तरण दरसँगै गर्नुहोस्। पुरानो कन्फिगरेसनसँग यन्त्र रिबुट हुँदा के हुन्छ भनी सोध्नुहोस्। तपाईंले प्रयोग गर्न खोजेको ठ्याक्कै सहकर्मीका लागि आपूर्तिकर्ताले अन्तरसञ्चालनीयता सूची प्रकाशित गर्छ कि भनी सोध्नुहोस्। फर्मवेयर अद्यावधिकले पूर्वनिर्धारित प्रस्ताव बदल्दा परिवर्तन कसको जिम्मामा छ भनी सोध्नुहोस्।

हार्डवेयर वारेन्टी तीमध्ये कुनैको उत्तर होइन।

त्यसपछि पूरै बेडाका लागि प्रतिबद्ध हुनुअघि जोडी परीक्षण गर्नुहोस्। एउटा सुरुङ, वास्तविक प्रस्ताव, वास्तविक राउटिङ मोड र कामको भारजस्तो स्थानान्तरणले कुनै पनि विशिष्टता तालिकाभन्दा बढी बताउनेछ।