आपका VPN पूल LAN का DHCP रेंज नहीं है: यह क्यों टूटता है

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

दो आवंटक, एक पता-स्थान

LAN का DHCP सर्वर जानता है कि उसने कौन-से पते और किस MAC पते को लीज़ पर दिए हैं, और वह उन्हें ARP से बचाता है। VPN सर्वर का अपना पूल है और उन लीज़ के बारे में कुछ नहीं जानता। कोई भी गलत नहीं है; बस उनका कभी परिचय नहीं कराया गया।

LAN पूल से दिया गया कोई पता जो VPN सर्वर बांटता है, पहले से किसी प्रिंटर का हो सकता है। अब दो डिवाइस एक ही प्रीफ़िक्स पर एक पते का दावा करते हैं, और स्विच की फ़ॉरवर्डिंग टेबल तय करती है कि कौन जवाब देगा।

यही वह विफलता है जिससे लोग पहले टकराते हैं: एक क्लाइंट जो सफलतापूर्वक जुड़ता है और फिर गलत मशीन तक पहुंचता है, या सही मशीन तक रुक-रुक कर पहुंचता है।

राउटर 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 रेंज दोबारा इस्तेमाल न करे।