एक VLAN से लैब WAN: सपाट सेगमेंट या राउटेड ट्रांसपोर्ट

एक प्रबंधित स्विच और एक अतिरिक्त VLAN आपको एक दोपहर में दो VPN गेटवे दे देंगे जो एक अलग सेगमेंट पर बात करते हैं। वह सेगमेंट जो साबित करता है वह WAN शब्द से लोगों की अपेक्षा से संकरा है। यह सीधा Ethernet पथ दोहराता है, जो उपयोगी है, और रास्ते में इंटरनेट पैकेटों के साथ जो कुछ भी करता है उसे लगभग सब छोड़ देता है। सपाट सेगमेंट और राउटेड लैब ट्रांसपोर्ट के बीच चुनना असल में इस बात का सवाल है कि आप कौन-से व्यवहार परखना चाहते हैं।

दो डिज़ाइन, दो अलग सबक

सपाट सेगमेंट दोनों WAN इंटरफ़ेस और एक परीक्षण होस्ट को एक VLAN में रखता है, एक ही प्रीफ़िक्स से पते लेकर। सब कुछ सीधे सब तक पहुँचता है, और गेटवे के बीच एकमात्र चीज़ स्विच है। यह वास्तविक टोपोलॉजी है, बस बहुत दिलचस्प नहीं।

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

सपाट सेगमेंट क्या साबित करता है

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

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

राउटिंग क्या जोड़ती है

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

कीमत है गलत होने की अधिक जगहें। हर अतिरिक्त उपकरण एक और कॉन्फ़िगरेशन है जो चित्र से मेल नहीं खा सकता, और जिस लैब को कोई नोट्स से फिर नहीं बना सकता वह लैब रहना बंद कर देती है। राउटर का कॉन्फ़िगरेशन उन नोट्स में रखें, केवल उसकी चल रही स्थिति में नहीं।

दोनों में से कोई डिज़ाइन क्या दोहराता नहीं

कैरियर अनुवाद सबसे बड़ी चूक है। लिंक पर काम करने वाला गेटवे पता अनुवाद के पीछे विफल हो सकता है, और सपाट सेगमेंट में कोई अनुवाद ही नहीं है। स्रोत पते बदलना, सेलुलर हैंडओवर और वह कतारबद्धता जो कॉल को हकलाने पर मजबूर करती है, सब उतने ही अनुपस्थित हैं।

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

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

लैब को सीमित रखना

एक स्वीकृत निजी रेंज इस्तेमाल करें जो उत्पादन से ओवरलैप न हो और आवंटन दर्ज करें। दस्तावेज़ीकरण रेंज आरेखों के लिए उदाहरण हैं, चल रही लैब के लिए पते नहीं, और बाद में पाया गया ओवरलैप एक राउटिंग खराबी पैदा करता है जो VPN बग जैसी दिखती है।

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

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