एका VLAN मधून लॅब WAN: सपाट सेगमेंट की राउटेड ट्रान्सपोर्ट

एक व्यवस्थापित स्विच आणि एक जादा VLAN तुम्हाला एका दुपारी वेगळ्या सेगमेंटवर बोलणारे दोन VPN गेटवे देईल। तो सेगमेंट जे सिद्ध करतो ते WAN शब्दापासून लोक अपेक्षा करतात त्यापेक्षा अरुंद आहे। तो थेट Ethernet मार्ग पुनरुत्पादित करतो, जो उपयुक्त आहे, आणि वाटेत इंटरनेट पॅकेट्ससोबत जे काही करते ते जवळपास सर्व सोडून देतो। सपाट सेगमेंट आणि राउटेड लॅब ट्रान्सपोर्ट यातील निवड हा खरंतर तुम्ही कोणती वर्तने तपासू इच्छिता याचा प्रश्न आहे।

दोन रचना, दोन वेगळे धडे

सपाट सेगमेंट दोन्ही WAN इंटरफेस आणि एक चाचणी होस्ट एका VLAN मध्ये ठेवतो, एकाच प्रीफिक्समधील पत्त्यांसह। सर्व काही सर्वांपर्यंत थेट पोहोचते, आणि गेटवेजमधील एकमेव गोष्ट स्विच आहे। ही खरी टोपोलॉजी आहे, फक्त फारशी मनोरंजक नाही।

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

सपाट सेगमेंट काय सिद्ध करतो

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

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

राउटिंग काय जोडते

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

किंमत म्हणजे चूक करण्याच्या अधिक जागा। प्रत्येक जादा उपकरण हे आकृतीशी जुळणार नाही असे आणखी एक कॉन्फिगरेशन आहे, आणि जी लॅब कोणीही नोट्समधून पुन्हा उभारू शकत नाही ती लॅब राहणे थांबवते। राउटरचे कॉन्फिगरेशन त्या नोट्समध्ये ठेवा, केवळ त्याच्या चालू स्थितीत नाही।

दोन्ही रचनांपैकी कोणतीही काय पुनरुत्पादित करत नाही

वाहक अनुवाद ही सर्वात मोठी वगळणी आहे। लिंकवर काम करणारा गेटवे पत्ता अनुवादामागे अपयशी होऊ शकतो, आणि सपाट सेगमेंटमध्ये कोणताही अनुवाद नाही। स्रोत पत्ते बदलणे, सेल्युलर हस्तांतरण आणि कॉल हेलकावणारी रांग हे सारखेच अनुपस्थित आहेत।

मार्गाचा आकार ही दुसरी वगळणी आहे। एक स्विच आणि एक राउटर असलेली लॅब जवळपास कधीही वास्तविक मार्ग लादतो तो लहान कमाल आकार निर्माण करत नाही, त्यामुळे विभाजन बग उपकरणे साइटवर पोहोचेपर्यंत लपून राहतो। हे अंतर स्पष्ट करते की बोगदा प्रत्येक लॅब चाचणी कशी उत्तीर्ण होतो आणि तरीही पहिल्या स्थापनेत अपयशी होतो। लॅब काय वचन देऊ शकते याबद्दलच्या अपेक्षाही ते ठरवते।

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

लॅब मर्यादेत ठेवणे

उत्पादनाशी ओव्हरलॅप न होणारी मंजूर खाजगी श्रेणी वापरा आणि वाटप नोंदवा। दस्तऐवजीकरण श्रेणी आकृत्यांसाठी उदाहरणे आहेत, चालू लॅबसाठी पत्ते नाहीत, आणि नंतर आढळलेला ओव्हरलॅप VPN बगसारखा दिसणारा राउटिंग दोष निर्माण करतो।

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

उपकरणाचा कोणताही भाग खऱ्या अपलिंकवर परतण्यापूर्वी लॅब-विशिष्ट कॉन्फिगरेशन काढा आणि उत्पादनाच्या मालकाकडून त्याचे पुनरावलोकन करून घ्या। सेगमेंट मौल्यवान आहे कारण त्याचे वर्तन ज्ञात आणि मर्यादित आहे, आणि यामुळेच ते बदलाशिवाय उत्पादनात नेणे असुरक्षित होते।