होस्ट बिट के साथ रूट अस्वीकृत? इच्छित प्रीफ़िक्स खोजें

आपकी रूट पंक्ति अस्वीकृत होकर लौटती है, और जो सलाह आपको मिलती है वह कहती है कि IP फ़ॉरवर्डिंग चालू करें। ये दो चीज़ें समस्या के अलग-अलग चरणों में हैं। फ़ॉरवर्डिंग तय करती है कि कोई होस्ट इंटरफ़ेस के बीच पैकेट भेज सकता है या नहीं; इसकी कोई राय नहीं है कि आपने जो गंतव्य लिखा है वह वैध नेटवर्क है या नहीं। पहले प्रीफ़िक्स ठीक करें, क्योंकि फ़ॉरवर्डिंग ऐसे पते और मास्क को नहीं बचा सकती जो आपस में नहीं मिलते।

पार्सर वास्तव में किस बात की शिकायत कर रहा है

पता और मास्क के रूप में लिखा गया गंतव्य एक नेटवर्क का वर्णन करना चाहिए, और नेटवर्क शून्य किए गए होस्ट बिट से शुरू होता है। जब आपका दिया पता अभी भी होस्ट भाग में कोई मान रखता है, तो यह जोड़ी आंतरिक रूप से असंगत है: 172.20.130.0 साफ़ दिखता है क्योंकि यह शून्य पर खत्म होता है, लेकिन चौथे ऑक्टेट में शून्य ही एकमात्र मायने रखने वाली बात नहीं है। यहाँ तीसरा ऑक्टेट ही भटके हुए बिट रखता है।

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

उदाहरण हाथ से करें

ऐसी सुरंग लें जिसे /20 मास्क के साथ 172.20.130.0 तक पहुँचना है। /20 तीसरे ऑक्टेट से चार बिट उधार लेता है, इसलिए वह ऑक्टेट केवल 16 के चरणों में गिना जाता है: 0, 16, 32 और आगे 240 तक। मान 130, 128 और 143 के बीच आता है, यानी घेरने वाला नेटवर्क 172.20.128.0 पर शुरू होता है, अंतिम ऑक्टेट शून्य किए 172.20.130.0 पर नहीं।

लिखित रूप में ब्लॉक 172.20.128.0 से 172.20.143.255 तक चलता है और 4,096 पते रखता है। वही मान गैर-कठोर पार्सर को देने पर वह प्रतिस्थापन दिखता है जो वह आपकी ओर से करता:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

तय करें कि आप वास्तव में कौन-सा गंतव्य चाहते थे

अस्वीकृत पंक्ति आमतौर पर तीन इरादों में से एक छिपाती है, और चुन सकते हैं केवल आप। अगर सुरंग को पूरा ब्लॉक चाहिए, तो 172.20.128.0/20 लिखें, जो विहित नेटवर्क पता है। अगर सुरंग को केवल 130 खंड चाहिए, तो मास्क गलत था और 172.20.130.0/24 ईमानदार रूप है। अगर लक्ष्य एक ही मशीन है, IPv4 होस्ट रूट /32 है और इसमें कोई मास्क-गणित शामिल नहीं है।

इनमें से हर एक अलग मात्रा में ट्रैफ़िक को अधिकृत करता है, और शिकायत रुकने तक मास्क न चौड़ा करने का यही असली कारण है। /16 लगभग हर जगह पंक्ति स्वीकार करता है और ट्रैफ़िक ऐसे गंतव्यों की ओर भेजता है जिन्हें आपने कभी सुरंग से रूट करना नहीं चाहा। इरादे से मेल खाता सबसे संकरा प्रीफ़िक्स लिखें, फिर उसे उस अगले हॉप के सामने पुष्ट करें जिसकी आप अपेक्षा करते हैं, पार्सर की चुप्पी के सामने नहीं।

फ़ॉरवर्डिंग कभी समाधान क्यों नहीं थी

अस्वीकृत रूट कभी फ़ॉरवर्डिंग पथ तक नहीं पहुँचता, इसलिए net.ipv4.ip_forward बदलने से परिणाम नहीं बदल सकता। वह सेटिंग बाद में मायने रखती है, जब होस्ट को इंटरफ़ेस के बीच पैकेट भेजने पड़ते हैं, और तालिका सही होने से पहले उसे चालू करना केवल यह बदलता है कि अगली बार कौन-सा चरण विफल होगा।

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

स्थापित रूट और उसके जीतने वाले पथ की जाँच करें

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

ब्लॉक के अंदर का एक सदस्य पता और बाहर का एक पता पूछें, ताकि तुलना एक ही तसल्लीदेह पंक्ति के बजाय अर्थपूर्ण हो:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

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