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 एक विशिष्ट संबंध दुरुस्त करतो; राउट केलेला पूल त्या दुरुस्तीची गरज टाळतो। तुम्ही कोणते निवडले आणि का ते लिहा, मग पुढच्या व्यक्तीला अयशस्वी शेजारी नोंदीतून ते पुन्हा शोधावे लागणार नाही।