LAN होस्ट OpenVPN क्लायंटच्या पत्त्यासाठी ARP का पाठवतो

LAN होस्ट आणि VPN क्लायंटमधील पोहोचेच्या समस्या अनेकदा पत्त्यांच्या आराखड्याकडेच परत जातात। त्या होस्टला 10.0.100.0/22 वर इंटरफेस द्या आणि ते 10.0.100.0 ते 10.0.103.255 पर्यंतचा प्रत्येक पत्ता थेट जोडलेला मानेल, यात 10.0.101.0/24 वर शांतपणे ठेवलेला क्लायंट पूलही आहे। उत्तर कधीही राउटरकडे जात नाही, कारण होस्टच्या दृष्टिकोनातून कोणताही राउटर सहभागी नसतो। पॅकेट शेजाऱ्याला उद्देशून असते आणि तारेवर मागितले जाते।

हा यंत्रणा अहवालांच्या संपूर्ण कुटुंबामागे आहे: टनेल सुरू आहे, सर्व्हरकडे मार्ग आहे, आणि तरीही LAN होस्ट क्लायंटपर्यंत पोहोचू शकत नाही।

ती /22 जी /24 गिळून टाकते

प्रीफिक्स श्रेणी म्हणून वाचा, स्ट्रिंग म्हणून नाही। /22 मध्ये 1024 पत्ते असतात, आणि 10.0.100.0/22 10.0.100.0 पासून 10.0.103.255 पर्यंत पसरते, म्हणून 10.0.101.0/24 वरचा पूल पूर्णपणे त्याच्या आत आहे। ही चूक पुनरावलोकनातून वाचते कारण पूलचे पहिले ऑक्टेट LAN च्या पहिल्या ऑक्टेटपेक्षा वेगळे दिसतात, आणि केवळ तिसरे ऑक्टेट हे आत असणे उघड करते। दोन्ही श्रेणी अंकांत लिहा, त्यांना वेगळ्या जाहीर करण्यापूर्वी।

तेच आत असणे उलट दिशेनेही दिसू शकते। सध्या कोणीही वापरत नसल्यामुळे मोकळा दिसणारा पूल तरीही कोणत्या तरी साइट राउटरने जाहीर केलेल्या प्रीफिक्समध्ये येऊ शकतो, आणि पत्त्यांचा आराखडा हाच ते दाखवणारा एकमेव दस्तऐवज आहे।

थेट कनेक्शन म्हणजे ARP, राउटिंग नाही

/22 इंटरफेस असलेला होस्ट जेव्हा 10.0.101.25 वर पाठवतो, तेव्हा कर्नेल गंतव्याची तुलना इंटरफेसच्या प्रीफिक्सशी करते आणि जुळणी सापडते। पॅकेट राउट केलेल्या पॅकेटऐवजी शेजारी शोध बनते, आणि इथरनेटवर शेजारी शोध त्या पत्त्यासाठी ARP विनंती असते। जर पत्ता राउटेड गेटवेमागील VPN क्लायंटचा असेल, तर LAN वर कोणताही होस्ट त्याचा मालक नसतो, म्हणून विनंती अनुत्तरित राहते आणि पॅकेट टाकाऊ होतात। टनेल दोषी नाही, आणि क्लायंट ट्रॅफिक कधीही पाहत नाही।

म्हणूनच बिघाड असममित आणि कधीकधी खंडित दिसतो। VPN होस्ट अनेकदा LAN पर्यंत पोहोचतो कारण त्याचे स्वतःचे मार्ग योग्य दिशेने दाखवतात, तर LAN होस्ट उत्तर देऊ शकत नाही, आणि जुनी ARP नोंद कॅश करणारी कोणतीही गोष्ट लक्षणाला चमकत ठेवते।

TUN, TAP आणि प्रत्येकजण काय वाहून नेतो

TUN उपकरण IP पॅकेट वाहून नेते, आणि TAP उपकरण इथरनेट फ्रेम वाहून नेते। राउटेड TUN दुव्याला IP पोहोच देण्यासाठी ARP वाहून नेण्याची गरज नाही, आणि म्हणूनच वरील अनुत्तरित विनंती अपेक्षित आहे, खराब नाही। TAP जाणूनबुजून बनवलेल्या ब्रिजसह प्रसारण क्षेत्र वाढवू शकते आणि ARP कार्यान्वित करू शकते, पण ते क्लायंट काय पाहू शकतो हे बदलते, त्याच फ्रेमिंगला समर्थन देणारे टोक आवश्यक करते, आणि हे आच्छादित प्रीफिक्सची दुरुस्ती नसून नेटवर्क मॉडेलची पुनर्रचना आहे। पत्त्यांच्या आराखड्यातील चूक बरी करण्यासाठी राउटेड तैनाती TAP वर नेणे लहान समस्या मोठ्याशी बदलते।

निष्कर्ष काढण्यापूर्वी ARP विनंती कुठे दिसली आणि कोणत्या प्रणालीने पाठवली ते नोंदवा। प्रेषक तुम्हाला सांगतो की तो गंतव्याबद्दल काय विचार करतो, टनेल काय करते हे नाही।

आच्छादित होऊ शकत नाही असा पूल रचा

प्रत्येक जोडलेल्या प्रीफिक्स आणि प्रत्येक जाहीर केलेल्या साइट प्रीफिक्सच्या बाहेर पूल निवडा, नंतर ती मार्ग जोडा जी त्याला दोन्ही दिशांनी पोहोचण्यायोग्य करतात। आराखड्याच्या न वापरलेल्या भागात 10.8.0.0/24 सारखी श्रेणी विचार करणे सोपे आहे, आणि ज्या LAN ला तिथपर्यंत पोहोचायचे आहे त्याला VPN सर्व्हरकडे निर्देश करणारा स्थिर मार्ग मिळतो। वाटप, जाहीर केलेले मार्ग, परवानगी असलेले स्रोत पत्ते आणि फायरवॉल नियम एकत्र बदला, कारण ते चार सेटिंग्ज नसून एक रचना सांगतात।

सर्व्हरवरील Source NAT पूल LAN मधून राउट करण्यायोग्य पत्त्यामागे लपवू शकते, आणि हे कायदेशीर स्थलांतर साधन आहे। ते स्रोतही पुन्हा लिहिते, म्हणून LAN कनेक्शन वैयक्तिक क्लायंटशी जोडण्याची आणि प्रति-क्लायंट नियम लागू करण्याची क्षमता गमावते।

स्वीकृतीसाठी खऱ्या क्लायंटचा प्रत्यक्षात दिलेला पत्ता आणि LAN होस्टकडून खरी अनुप्रयोग विनंती वापरा, नंतर उत्तर तारेऐवजी नियोजित गेटवेचे अनुसरण करते याची पुष्टी करा।