वेगवेगळ्या विक्रेत्यांचे दोन साइट गेटवे, त्यांची अंमलबजावणी वाटाघाटी होणाऱ्या पॅरामीटर्सवर सहमत झाल्यास बोगदा तयार करतील. एकसारखे ब्रँड अट नाहीत, आणि जुळणारे ब्रँडही हमी नाहीत. सुसंगततेचा प्रश्न वैशिष्ट्ये आणि आवृत्त्यांशी आहे; क्षमतेचा प्रश्न उपकरणाने सॉफ्टवेअरमध्ये करायच्या कामाशी आहे. यांना दोन तपासण्या माना, त्याच क्रमाने.

यादी क्रमाने पाहा आणि उत्तर नसलेल्या पहिल्या मुद्द्यावर थांबा.

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

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

AWS च्या ग्राहक गेटवे आवश्यकता AWS शी जोडले न गेल्यासही उपयुक्त नमुना आहेत, कारण त्या करार प्रोटोकॉल व राउटिंगच्या जबाबदाऱ्यांचा संच म्हणून मांडतात. विशिष्ट मॉडेलसाठी विक्रेत्याची नमुना फाइल कोणीतरी ते संयोजन तपासले याचा सभ्य पुरावा आहे. IPsec आधाराचा दावा करणारे सामान्य लेबल आवृत्तीही सिद्ध करत नाही आणि धोरण नमुनाही नाही. विपणन सारांशाऐवजी प्रकाशन टिपा वाचा.

आवृत्ती तपासा, डेटाशीटवरील लेबल नाही

IKEv2 ची आंतरकार्यक्षमता वाटाघाटी झालेल्या पॅरामीटर्सवर ठरते, म्हणून प्रश्न असा आहे की सध्याचे फर्मवेअर कोणते प्रस्ताव देते आणि स्वीकारते. सामान्यपणे प्रोटोकॉलला आधार देणारे उपकरणही तुमचे दुसरे टोक ज्यावर आग्रह धरते ते विशिष्ट संयोजन नाकारू शकते. दोन्ही बाजूंना आवृत्ती श्रेणी आणि प्रस्ताव यादीची पुष्टी करा.

एखादे वैशिष्ट्य नंतरच्या फर्मवेअर श्रेणीत आले अशी टीप पुरेशी सामान्य आहे की ती स्वतःच्या चेकलिस्ट मुद्द्यास पात्र ठरते.

क्षमतेकडे स्वतंत्र प्रश्न म्हणून पाहा

एन्क्रिप्शनला काम लागते, आणि किती हे अल्गोरिदमइतकेच अंमलबजावणीवरही अवलंबून असते. काही गतीवर्धक मार्ग फक्त विशिष्ट अल्गोरिदम किंवा विशिष्ट फॉरवर्डिंग मार्गांना लागू होतात, त्यामुळे उपकरण एका संरचनेत वेगवान आणि दुसऱ्यात संथ असू शकते. सामान्य WAN थ्रूपुट हे एन्क्रिप्टेड बोगद्याचे थ्रूपुट नाही. तुम्ही प्रत्यक्षात संरक्षित कराल त्या रहदारीनुसार उपकरणाचे मापन करा.

पॅकेटचा आकारही महत्त्वाचा आहे, कारण एन्कॅप्स्युलेशन आणि कोणताही अतिरिक्त भार प्रत्येक पॅकेट वाहून नेणारा पेलोड कमी करतो.

राउटिंग धोरण स्पष्टपणे ठरवा

साइट-ते-साइट म्हणजे फक्त निवडक रहदारी बोगदा वापरू शकते असे नाही, आणि सर्व काही वापरलेच पाहिजे असेही नाही. रचना विशिष्ट खाजगी प्रीफिक्स वाहू शकते, किंवा गेटवेमधून डीफॉल्ट मार्ग पाठवू शकते. एक निवडा आणि लिहून ठेवा, कारण काय जाहीर केले जाते आणि काय स्वीकारले जाते यावर दोन्ही टोकांनी सहमत व्हावे. येथे विसंगती असल्यास वर असलेला बोगदा आणि अर्धा पोहोचणारे जाळे मिळते.

गतिशील राउटिंगच्या रचना आणखी एक अट जोडतात: दोन्ही टोकांना राउटिंग प्रोटोकॉलचा आधार.

खरेदीपूर्वी काय तुलना करावी

अद्यतनांची गती, आंतरकार्यक्षमतेचे पुरावे, संरचनेची पुनर्प्राप्ती आणि इच्छित फेलओव्हर वर्तन यांची सर्वोच्च हस्तांतरण दरासह तुलना करा. जुन्या संरचनेसह उपकरण रीबूट झाल्यावर काय होते ते विचारा. तुम्ही वापरणार असलेल्या नेमक्या समकक्षासाठी विक्रेता आंतरकार्यक्षमता यादी प्रकाशित करतो का ते विचारा. फर्मवेअर अद्यतन डीफॉल्ट प्रस्ताव बदलल्यास बदल कोणाचा आहे ते विचारा.

हार्डवेअर वॉरंटी यापैकी कोणत्याही प्रश्नाचे उत्तर नाही.

मग संपूर्ण ताफ्यासाठी बांधील होण्यापूर्वी जोडी तपासा. एक बोगदा, प्रत्यक्ष प्रस्ताव, प्रत्यक्ष राउटिंग मोड आणि कामाच्या भारासारखे हस्तांतरण कोणत्याही तपशील तक्त्यापेक्षा अधिक सांगतील.

संबंधित लेख