LAN पते वाला VPN क्लाइंट LAN पर नहीं है

क्लाइंट जुड़ता है, 10.50.0.200 पाता है और 10.50.0.20 पर सर्वर तक नहीं पहुँच पाता, जबकि दोनों नंबर एक ही /24 में हैं। इस कॉन्फ़िगरेशन के पीछे की मान्यता यह है कि 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 एक खास रिश्ता ठीक करता है; रूट किया गया पूल उस मरम्मत की ज़रूरत हटा देता है। लिख लें कि आपने कौन-सा चुना और क्यों, फिर अगले व्यक्ति को विफल पड़ोसी प्रविष्टि से इसे फिर से खोजना नहीं पड़ेगा।