IPsec लैब में दो रूट बही रखें: अंडरले और सुरक्षित

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

दो बहियाँ, दो सवाल

लैब छोटी होने तक बहियाँ हाथ से रखने लायक छोटी रहती हैं, और ठीक तभी वे सबसे उपयोगी होती हैं। दो कॉलम काफ़ी हैं: प्रविष्टि क्या है, और उस तक कैसे पहुँचा जाता है।

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

प्रोटोकॉल से पहले गंतव्य लिखें

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

रूटिंग प्रोटोकॉल चुनने से पहले ऐसा करना चर्चा को ईमानदार रखता है। डिज़ाइन पसंद के साथ नहीं, ज़रूरतों के साथ आता है। कौन-सा प्रोटोकॉल चलाना है, यह बहस तब इस सवाल में बदल जाती है कि कौन-सी ज़रूरत वाकई कठिन है।

स्थिर या गतिशील, हर बही के लिए अलग फ़ैसला

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

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

पुनर्वितरण नीति की सीमा है

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

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

सुरक्षा का उदाहरण रूटिंग जितना ही अद्यतन रखें

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

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

कुछ टूटता है तो बही बताती है कि कौन-सी परत खोलनी है। पीयर तक पहुँच न होना ट्रांसपोर्ट है, भीतरी रूट न होना निजी मार्ग है, और बिना मेल खाते चयनकर्ता के मौजूद रूट नीति है। तीन वाक्य, एक निदान, कोई अनुमान नहीं।