VPN रूट तालिका आपको क्या बताती है और क्या नहीं बता सकती

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

तालिका को स्थानीय निर्देशों की तरह पढ़ें

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

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

चौड़ा प्रीफ़िक्स सूची नहीं है

टनल से रूट किया गया /16 का अर्थ सोलह हज़ार पहुँचने योग्य होस्ट नहीं है, और डिफ़ॉल्ट रूट का अर्थ उससे भी कम है। सर्वर तय करता है कि कौन उत्तर देगा, फ़ायरवॉल तय करता है कि क्या अनुमत है, और खाता तय करता है कि क्या अधिकृत है।

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

प्रविष्टियाँ कहाँ से आती हैं

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

किसी रुकावट के दौरान टाइप किया गया रूट वही है जो रीबूट पर गायब हो जाता है और किसी के दस्तावेज़ में नहीं दिखता। सर्वर द्वारा धकेला गया रूट सर्वर बदलने पर बदल जाता है, इसीलिए बिना व्याख्या वाला नया प्रीफ़िक्स अक्सर गेटवे अपडेट के बाद दिखता है, क्लाइंट बदलाव के बाद नहीं। यह ip-route मैनुअल तालिका और फ़ील्ड के सिंटैक्स का दस्तावेज़ीकरण करता है यदि आपको फ़्लैग पढ़ने हों।

सेवा अनुबंध के सामने रूट जाँचें

उपयोगी तुलना तालिका और आपसे वादा की गई सेवा के बीच है: नाम, पता सीमा, पोर्ट और मालिक। इन चारों को प्रीफ़िक्स के पास लिखें और खाली जगहें दिखाई देने लगेंगी।

ip route show table all dev tun0
ip route get 10.20.5.9
ip rule show

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

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