LAN ठेगाना भएको VPN क्लाइन्ट LAN मा छैन

क्लाइन्ट जोडिन्छ, 10.50.0.200 पाउँछ र दुवै नम्बर एउटै /24 मा भए पनि 10.50.0.20 को सर्भरमा पुग्न सक्दैन। यो कन्फिगरेसनको पछाडिको विश्वास हो कि LAN प्रिफिक्सको ठेगानाले क्लाइन्टलाई LAN को भाग बनाउँछ। त्यसो गर्दैन। क्लाइन्ट पोइन्ट-टु-पोइन्ट लिङ्कमा छ, सर्भरले गन्तव्यलाई स्थानीय मान्छ, र छुटेको टुक्रा त्यो छिमेकी-जवाफ हो जो कसैले पठाउँदैन।

मिथक: एउटै प्रिफिक्स भनेको एउटै सेग्मेन्ट

ठेगाना प्रिफिक्सले होस्टलाई कुन गन्तव्यमा सिधै पुग्न सकिन्छ र कुनलाई राउटर चाहिन्छ भन्छ। यसले होस्टलाई गन्तव्य भौतिक रूपमा कसरी जोडिएको छ भन्दैन, र गन्तव्यले लिङ्क-तहको अनुरोधको जवाफ दिन सक्छ भन्ने ग्यारेन्टी पनि दिँदैन। यी फरक प्रश्न हुन्, जसको जवाफ होस्टमा भएका फरक तालिकाले दिन्छन्। मास्कले पहिलोको जवाफ दिन्छ र छिमेकी तालिकाले दोस्रोको, र VPN पक्षबाट तपाईंको नियन्त्रणमा पहिलो मात्र छ।

जब सर्भरले 10.50.0.200 मा पठाउँछ, त्यो गन्तव्यलाई आफ्नै मास्कसँग तुलना गर्छ, ठेगानालाई on-link मान्छ, र त्यसको मालिक भएको हार्डवेयर ठेगाना स्थानीय सेग्मेन्टसँग सोध्छ। त्यो अनुरोध Ethernet इन्टरफेसबाट बाहिर जान्छ, र VPN क्लाइन्ट त्यहाँ सुन्न छैन।

क्लाइन्टको कन्फिगरेसनमा केहीले पनि आफ्नो पक्षबाट यो सुधार्न सक्दैन। जवाफको बाटो LAN मा भएको उपकरणले क्लाइन्टको तर्फबाट जवाफ दिने वा क्लाइन्टसँग सर्भरले स्थानीय नमान्ने ठेगाना हुने कुरामा निर्भर छ।

स्थानीय होस्टले ठेगानासँग वास्तवमै के गर्छ

व्यवहार हेर्न सजिलो छ र केही बदल्नु अघि हेर्न लायक छ। क्लाइन्टसम्म पुग्ने प्रयास गरेपछि LAN होस्टको छिमेकी तालिकामा हेर्नुहोस्: अपूर्ण वा असफल प्रविष्टि एकै लाइनमा पूरा निदान हो। त्यो लाइनले त्रुटि सेग्मेन्टमा स्थानीय छ, टनेलभित्र कतै होइन भन्ने पनि बताउँछ।

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

रुट खोजले Ethernet इन्टरफेसबाट गन्तव्यलाई on-link भनी जनाउनेछ, र समस्या ठ्याक्कै त्यही हो। VPN सत्र चालु रहेको बेला छिमेकी प्रविष्टि अपूर्ण रह्यो भने, तपाईंले छुटेको टुक्रा लिङ्क-तहको समाधान हो, राउटिङ वा फायरवाल नीति होइन भनी पुष्टि गर्नुभएको छ।

अर्को सबनेटको होस्टबाट त्यही जाँच गर्नुहोस् र तुलना गर्नुहोस्। राउटरमार्फत क्लाइन्टसम्म पुग्ने होस्टलाई छिमेकी प्रविष्टिको आवश्यकता नै हुँदैन, र त्यो भिन्नता नै सानो रूपमा डिजाइन निर्णय हो।

proxy ARP ले अर्को हप कसरी दिन्छ

proxy ARP ले गेटवेलाई अर्को इन्टरफेसबाट पुग्न सकिने गन्तव्यको तर्फबाट लिङ्क-तहको अनुरोधको जवाफ दिन लगाउँछ। LAN होस्टले हार्डवेयर ठेगाना पाउँछ, फ्रेम गेटवेमा पठाउँछ, र गेटवेले प्याकेट VPN सत्रमा अगाडि पठाउँछ। होस्टको दृष्टिकोणबाट क्लाइन्ट गेटवेको पछाडि भएको जस्तो देखिन्छ। क्लाइन्टको कन्फिगरेसनमा केही बदलिँदैन।

MikroTik को RouterOS ARP कागजात ले जोडिएको LAN को ठेगाना ठाउँ उधारो लिने डायल-इन क्लाइन्टका लागि त्यो प्रयोग वर्णन गर्छ। यो संयन्त्र छिमेकी-समाधानको मर्मत हो, र गेटवे साँच्चै दुवै बाटोमा भएकोले यो काम गर्छ।

यो क्लाइन्टलाई LAN मा ब्रिज गर्नु जस्तै होइन। गेटवेले अझै प्याकेट सही सक्रिय सत्रमा पठाउनुपर्छ, र यसको राउटिङ र फायरवाल नीतिले अझै सेवालाई अनुमति दिनुपर्छ। proxy ARP ले छिमेकी अनुरोधको जवाफ को दिन्छ भन्ने बदल्छ, को बोल्न पाउँछ भन्ने होइन।

प्लेटफर्मका मोड नाम ध्यानपूर्वक पढ्नुहोस्। RouterOS ले proxy-arp लाई local-proxy-arp बाट अलग गर्छ, र दोस्रोले त्यही इन्टरफेसबाट भित्र आउने र बाहिर जाने ट्राफिक सम्हाल्छ। यी एकअर्कामा बदल्न मिल्ने हिज्जे होइनन्, र दुवैलाई भेद नगरी सक्रिय गर्नु छोटो बाटो होइन।

proxy ARP ले तपाईंलाई के दिँदैन

यसले broadcast वा multicast खोज दिँदैन। broadcast मार्फत सेवा खोज्नुपर्ने क्लाइन्ट अझै असफल हुनेछ, किनकि गेटवेले unicast सत्रमा पठाउँछ र क्लाइन्टलाई LAN को broadcast डोमेनको सदस्य बनाउँदैन। broadcast मा निर्भर खोज प्रोटोकलहरू उधारो ठेगानाका डिजाइनमा «एउटा कुराका लागि काम गर्छ, अर्कोका लागि गर्दैन» भन्ने रिपोर्टको सामान्य स्रोत हुन्।

यसले ठेगाना आरक्षित गर्दैन। उधारो लिइएको नम्बर DHCP पूल वा स्थिर बाँडफाँटमा पनि छ भने, दुई उपकरण एउटै ठेगानामा पुग्न सक्छन् र परिणाम व्यवहार समयमा निर्भर हुन्छ। सफल लगइन आरक्षण होइन।

र यसले LAN को मालिकसँग समन्वय गर्ने आवश्यकता हटाउँदैन। ठेगाना योजनाको मालिकलाई छक्क पार्ने proxy ARP प्रविष्टि शान्त हप्ताको प्रतीक्षामा रहेको सहयोग घटना हो।

अलग रुट गरिएको पूलसँग तुलना

विकल्प भनेको VPN क्लाइन्टलाई आफ्नै प्रिफिक्स दिने र LAN होस्टलाई त्यहाँ रुट गर्न दिने हो। त्यसपछि सर्भरले आफ्नो गेटवेमा off-link जवाफ पठाउँछ, गेटवेले प्रिफिक्सलाई VPN अन्त्य बिन्दुमा रुट गर्छ, र LAN सेग्मेन्टमा छिमेकी-समाधानको आवश्यकता नै हुँदैन। यो उधारो ठेगाना र proxy जवाफभन्दा कम चल्ने भागहरू हो।

त्यो डिजाइन सोच्न सजिलो र अडिट गर्न सजिलो छ, किनकि क्लाइन्ट दायरा LAN दायराबाट देखिने गरी अलग छ। यसको लागत एउटा रुट, फर्कने बाटो र एउटा पहुँच नियम हो, अर्थात् proxy ARP डिजाइनलाई कम स्पष्ट ठाउँमा चाहिने तीही कुरा।

मोडेलहरूबीच जानाजान छान्नुहोस्, संयोगले होइन। proxy ARP ले एउटा निश्चित सम्बन्ध मर्मत गर्छ; रुट गरिएको पूलले त्यो मर्मतको आवश्यकता हटाउँछ। तपाईंले कुन छान्नुभयो र किन लेख्नुहोस्, अनि अर्को व्यक्तिले असफल छिमेकी प्रविष्टिबाट यो फेरि पत्ता लगाउनु पर्दैन।