होस्ट बिटका कारण रुट अस्वीकृत भयो? अभिप्रेत प्रिफिक्स खोज्नुहोस्

तपाईंको रुट लाइन अस्वीकृत भएर फर्कन्छ, र तपाईंले भेट्ने सल्लाहले IP फर्वार्डिङ खोल्न भन्छ। यी दुई कुरा समस्याका फरक चरणमा छन्। फर्वार्डिङले होस्टले इन्टरफेसहरूबीच प्याकेट सार्न सक्छ कि भन्ने निर्णय गर्छ; तपाईंले टाइप गरेको गन्तव्य मान्य नेटवर्क हो कि भन्नेमा यसको कुनै राय छैन। पहिले प्रिफिक्स ठीक गर्नुहोस्, किनकि नमिल्ने ठेगाना र मास्कलाई फर्वार्डिङले बचाउँदैन।

पार्सरले वास्तवमा केको गुनासो गरिरहेको छ

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

यी असंगतिलाई उपकरणहरूले फरक तरिकाले सम्हाल्छन्। कडा पार्सरहरूले लाइन अस्वीकार गरी होस्ट बिटको नाम दिन्छन्। नरम पार्सरहरूले ठेगाना मास्क गरी तपाईंले नमागेको कुरा स्थापना गर्छन्, जो बढी खराब हो, किनकि कन्फिगरेसनले अब तपाईंले कहिल्यै नचाहेको दायरा रुट गर्छ। Python को 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

तपाईंको प्रिफिक्स सही भए तेस्रो प्रश्न सुरुङबाहिर पर्नुपर्छ, र नपरेमा तपाईंले बनाएको रुट सोचेभन्दा फराकिलो छ। अर्को सेटिङ छुनुअघि प्रिफिक्सले के ढाक्नुपर्थ्यो लेख्नुहोस्, किनकि पार्स हुने रुट र काम गर्ने मार्ग अलग अवलोकन नै रहन्छन्।