तुमचा VPN पूल LAN चा DHCP श्रेणी नाही: तो का तुटतो

मोहक शॉर्टकट म्हणजे VPN क्लायंट्सना ऑफिसचा DHCP सर्व्हर वापरतो त्याच श्रेणीतील पत्ते देणे, कारण सगळं एकच नेटवर्क आहे अशा कल्पनेने। पण तसं नाही। राउटेड टनेल दोन टोकांमध्ये unicast पॅकेट्स नेते, तर LAN पूल भौतिक विभागावर ब्रॉडकास्ट विनंत्यांना उत्तर देण्यासाठी असतो। तेच क्रमांक पुन्हा वापरल्याने दोन वाटपकर्ते एका पत्ता-क्षेत्राचे जबाबदार होतात आणि रिटर्न मार्ग अपरिभाषित राहतो।

दोन वाटपकर्ते, एक पत्ता-क्षेत्र

LAN चा DHCP सर्व्हर कोणते पत्ते कोणत्या MAC पत्त्याला भाड्याने दिले हे जाणतो आणि ARP ने त्यांचे रक्षण करतो। VPN सर्व्हरकडे स्वतःचा पूल आहे आणि त्या भाडेकरारांबद्दल काहीही माहीत नाही। दोघेही चुकीचे नाहीत; त्यांची कधी ओळख करून दिलीच गेली नाही।

VPN सर्व्हर LAN पूलमधून देतो तो पत्ता आधीच एखाद्या प्रिंटरचा असू शकतो। आता दोन उपकरणे एकाच प्रीफिक्सवर एका पत्त्याचा दावा करतात, आणि स्विचची फॉरवर्डिंग टेबल कोण उत्तर देईल हे ठरवते।

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

राउटर VPN पत्ते का वाटत नाही

DHCP शोध हा ब्रॉडकास्ट असतो, आणि ब्रॉडकास्ट राउटेड सीमेवर थांबतात। जर रचनेने टनेल ब्रिज केले नाही किंवा जुळत्या अधिकाराचा DHCP रिले चालवला नाही, तर क्लायंटची विनंती LAN सर्व्हरपर्यंत कधीच पोहोचत नाही।

म्हणून VPN सर्व्हर स्वतः पत्ता निश्चित करतो: सर्व्हर कॉन्फिगरेशनमधील पूल, WireGuard सेटअपमध्ये प्रत्येक पीअरसाठी एक पत्ता, किंवा IKEv2 अंमलबजावणीत प्रमाणीकरण स्तर ढकलणारा पत्ता। ही यंत्रणा LAN च्या भाडे डेटाबेसपासून स्वतंत्र आहे, आणि म्हणूनच त्यांना स्वतःची श्रेणी हवी।

तोच तर्क सांगतो की DHCP व्याप्ती बदलल्याने कधीच पत्ता न मिळणारा VPN क्लायंट का सुधारत नाही। क्लायंट LAN सर्व्हरला विचारत नाही, आणि व्याप्तीत कितीही संपादन केले तरी तो विचारायला लावता येत नाही।

ओव्हरलॅप संथ नेटवर्क म्हणून नाही, संघर्ष म्हणून दिसतो

समर्थित रचनेशिवाय एकच प्रीफिक्स वाटून घेणारी दोन नेटवर्क दुहेरी मालकीपेक्षा वेगळी समस्या आहेत, आणि त्यांची अनेकदा गल्लत होते। VPN पूल वेगळा प्रीफिक्स असेल, तर मार्गाने रहदारी चुकीच्या बाजूला पाठवल्यावरच ओव्हरलॅप महत्त्वाचा ठरतो। पूल LAN प्रीफिक्सच्या आत असेल, तर संघर्ष तात्काळ आणि स्थानिक असतो।

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

रिटर्न मार्ग वेगळी समस्या आहे

स्वच्छ आणि वेगळ्या पूलसहही, LAN होस्ट्सना क्लायंटला कसे उत्तर द्यायचे हे माहीत असणे आवश्यक आहे। त्यांचा डीफॉल्ट गेटवे राउटर आहे, आणि राउटरला पूलसाठी VPN सर्व्हरकडे निर्देश करणारा मार्ग हवा, जोपर्यंत रचना त्याऐवजी क्लायंट रहदारीचे भाषांतर करत नाही।

काहीही बदलण्यापूर्वी मार्ग दोन्ही दिशांनी वाचा। गेटवेवर विचारा की कर्नेल क्लायंट पत्त्यासाठी कोणते इंटरफेस वापरेल; क्लायंटवर विचारा की तो LAN पत्त्यासाठी कोणता मार्ग वापरतो।

ही कमांड्स गेटवेवरील फॉरवर्डिंग निर्णय आणि डुप्लिकेट उघड करणाऱ्या शेजारी नोंदी दाखवतात:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

पहिली कमांड टनेल इंटरफेसने उत्तर देत असेल, तर रिटर्न मार्ग अस्तित्वात आहे। ती LAN इंटरफेसने उत्तर देत असेल, तर राउटरला वाटते क्लायंट तारेवर आहे आणि तो त्याच्यासाठी ARP करण्याचा प्रयत्न करेल।

ब्रिज्ड रचना अस्तित्वात आहेत, पण त्या निवडाव्या लागतात

टनेल LAN ला ब्रिज करणे ही खरी रचना आहे, जी क्लायंट्सना ब्रॉडकास्ट मिळायला हवे किंवा एकच विभाग गृहीत धरणाऱ्या प्रोटोकॉलने त्यांना शोधायला हवे तेव्हा वापरली जाते। त्यासाठी सर्व्हरकडे ते ब्रिजिंग वर्तन आणि त्यासोबत येणारे पत्ता हाताळणी असणे आवश्यक आहे।

जे चालत नाही ते म्हणजे क्रमांक कॉपी करून निकालाचे अनुकरण करणे। ब्रिजशिवाय सामायिक पूल तुम्हाला शोधाशिवाय संघर्ष देतो, जो दोन्ही मांडणींमध्ये सर्वात वाईट आहे।

ऍप्लिकेशनला खरोखर विभागाची गरज नसेल तर वेगळ्या पूलसह तिसरा स्तर निवडा, आणि पूलाची नोंद ठेवा जेणेकरून पुढचा प्रशासक स्वच्छतेसाठी DHCP श्रेणी पुन्हा वापरणार नाही।