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

सूची में क्रम से आगे बढ़ें और उस पहले मद पर रुकें जिसका कोई उत्तर नहीं है।

ब्रांड से नहीं, प्रोटोकॉल की विशेषताओं से शुरू करें

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

AWS की ग्राहक गेटवे आवश्यकताएँ एक उपयोगी खाका हैं, भले ही आप AWS से न जुड़ रहे हों, क्योंकि वे अनुबंध को प्रोटोकॉल और राउटिंग के दायित्वों के समूह के रूप में कहती हैं। किसी विशेष मॉडल के लिए विक्रेता की नमूना फ़ाइल यह ठोस प्रमाण है कि किसी ने वह संयोजन आज़माया है। IPsec समर्थन का दावा करने वाला सामान्य लेबल न संस्करण सिद्ध करता है न नीति मॉडल। मार्केटिंग सारांश के बजाय रिलीज़ नोट पढ़ें।

संस्करण जाँचें, डेटाशीट का लेबल नहीं

IKEv2 की अंतर-संचालनीयता बातचीत किए गए पैरामीटरों से तय होती है, इसलिए सवाल यह है कि मौजूदा फ़र्मवेयर कौन से प्रस्ताव देता है और स्वीकार करता है। जो डिवाइस सामान्य रूप से प्रोटोकॉल का समर्थन करता है, वह फिर भी उस विशिष्ट संयोजन को अस्वीकार कर सकता है जिस पर आपका दूसरा सिरा ज़ोर देता है। दोनों पक्षों पर संस्करण स्ट्रिंग और प्रस्ताव सूची की पुष्टि करें।

यह नोट कि कोई विशेषता बाद की फ़र्मवेयर श्रृंखला में आई, इतना सामान्य है कि वह अपना अलग चेकलिस्ट मद हकदार है।

क्षमता को अलग सवाल मानिए

एन्क्रिप्शन में काम लगता है, और कितना, यह एल्गोरिदम जितना ही कार्यान्वयन पर निर्भर करता है। कुछ त्वरण पथ केवल विशेष एल्गोरिदम या विशेष फ़ॉरवर्डिंग पथ पर लागू होते हैं, इसलिए कोई डिवाइस एक विन्यास में तेज़ और दूसरे में धीमा हो सकता है। सामान्य WAN थ्रूपुट एन्क्रिप्टेड टनल थ्रूपुट नहीं है। डिवाइस का माप उस ट्रैफ़िक से करें जिसे आप वास्तव में सुरक्षित करेंगे।

पैकेट का आकार भी मायने रखता है, क्योंकि एन्कैप्सुलेशन और कोई भी अतिरिक्त ओवरहेड हर पैकेट द्वारा ले जाए जाने वाले पेलोड को घटा देते हैं।

राउटिंग नीति स्पष्ट रूप से तय करें

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

गतिशील राउटिंग वाले डिज़ाइन एक और शर्त जोड़ते हैं: दोनों सिरों पर राउटिंग प्रोटोकॉल का समर्थन।

खरीदने से पहले क्या तुलना करें

अद्यतन की गति, अंतर-संचालनीयता के प्रमाण, विन्यास की पुनर्प्राप्ति और इच्छित फ़ेलओवर व्यवहार की तुलना शिखर स्थानांतरण दर के साथ करें। पूछें कि जब डिवाइस पुराने विन्यास के साथ रीबूट होता है तो क्या होता है। पूछें कि क्या विक्रेता उस ठीक पीयर के लिए अंतर-संचालनीयता सूची प्रकाशित करता है जिसे आप उपयोग करने की योजना बना रहे हैं। पूछें कि जब फ़र्मवेयर अद्यतन किसी डिफ़ॉल्ट प्रस्ताव को बदलता है तो बदलाव किसका है।

हार्डवेयर वारंटी इनमें से किसी का उत्तर नहीं है।

फिर पूरे बेड़े के लिए प्रतिबद्ध होने से पहले जोड़ी को जाँचें। एक टनल, वास्तविक प्रस्ताव, वास्तविक राउटिंग मोड और कार्यभार जैसा स्थानांतरण आपको किसी भी विशिष्टता तालिका से अधिक बताएँगे।

संबंधित लेख