तुमची रूट ओळ नाकारली जाऊन परत येते, आणि तुम्हाला मिळणारा सल्ला 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

तुमचा प्रीफिक्स बरोबर असल्यास तिसरी चौकशी बोगद्याबाहेर पडली पाहिजे, आणि न पडल्यास तुम्ही बांधलेला रूट तुम्ही विचारता त्यापेक्षा रुंद आहे। पुढील सेटिंगला स्पर्श करण्यापूर्वी प्रीफिक्सने काय व्यापायचे होते ते नोंदवा, कारण पार्स होणारा रूट आणि कार्य करणारा मार्ग वेगळी निरीक्षणेच राहतात।

संबंधित लेख