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 होस्टबाट वास्तविक अनुप्रयोग अनुरोध प्रयोग गर्नुहोस्, त्यसपछि जवाफले तारको सट्टा योजना गरिएको गेटवे पछ्याउँछ भनी पुष्टि गर्नुहोस्।