VPN के पार DHCP: ब्रॉडकास्ट को पुल करें या रिले करें?

सुरंग के दूसरी ओर का नया लैपटॉप कोई पता नहीं पाता, जबकि वही लैपटॉप मुख्यालय में काम करता है। सामान्य पहला अनुमान यह होता है कि सुरंग DHCP को अवरुद्ध कर रही है। अधिकतर ब्रॉडकास्ट के पास कभी मार्ग ही नहीं था: बिना कॉन्फ़िगर किया गया क्लाइंट 255.255.255.255 पर भेजता है, और साधारण IP राउटर उस पैकेट को आगे नहीं भेजता। सुरंग ठीक वही कर रही है जो एक रूटेड सुरंग करती है।

दो डिज़ाइन इसे बदल सकते हैं, और वे समतुल्य नहीं हैं। एक ब्रॉडकास्ट ले जाता है; दूसरा अनुरोध रिले करता है।

ब्रॉडकास्ट कभी राउटर को पार नहीं करता

बिना पते का DHCPv4 क्लाइंट 0.0.0.0 से सीमित ब्रॉडकास्ट पते पर UDP पोर्ट 67 और 68 पर भेजता है। वह पैकेट डिज़ाइन के अनुसार अपनी लिंक पर ही रहता है। जो राउटर उसे आगे भेजता, वह अपनी सेवा देने वाले हर सेगमेंट में बाढ़ ला देता।

इसलिए एक रूटेड साइट-से-साइट सुरंग रिले को सर्वर से जोड़ती है। यह क्लाइंट का ब्रॉडकास्ट डोमेन नहीं बढ़ाती, और कोई फ़ायरवॉल नियम इसे ऐसा नहीं करा सकेगा।

पुल की गई सुरंग वास्तव में क्या बढ़ाती है

जान-बूझकर पुल की गई VPN अपनी समर्थित टोपोलॉजी में Ethernet ब्रॉडकास्ट ले जा सकती है, और तब DHCP स्थानीय ट्रैफ़िक के रूप में पार कर सकता है। यह वास्तविक विकल्प है, पर यह 2 परत का डिज़ाइन निर्णय है। आप ब्रॉडकास्ट के साथ विफलता-क्षेत्र और पहुँच-सीमा भी बढ़ा रहे हैं।

पुल करना यह भी बदलता है कि ब्रॉडकास्ट तूफ़ान, ARP स्कैन या दुर्भावनापूर्ण DHCP सर्वर कहाँ तक पहुँच सकते हैं। यदि आप दूरस्थ कार्यालय को उसी स्विच में न जोड़ते, तो केवल पते बाँटने के लिए सुरंग को पुल न करें। सक्षम करने से पहले उस प्रभाव-त्रिज्या को जाँचें।

यह पता देने से बड़ा निर्णय है, और इसे जान-बूझकर लिया जाना चाहिए।

इसके बजाय अनुरोध रिले करें

सामान्य उत्तर क्लाइंट के स्थानीय नेटवर्क पर एक रिले है। वह ब्रॉडकास्ट प्राप्त करता है, उसे unicast अनुरोध में बदलता है, और अपना पता गेटवे-पता फ़ील्ड में रखता है। सर्वर उस रिले पते पर उत्तर देता है।

उदाहरण के लिए दूरस्थ कार्यालय में, रिले कार्यालय के LAN पर बैठता है और सर्वर तक साइट VPN से पहुँचा जाता है। उस कार्यालय के लिए स्कोप, रिले और सर्वर की पहचान, और पूरा वापसी-मार्ग कॉन्फ़िगर करें। सुरंग से UDP 67 की अनुमति देना सर्वर को यह नहीं बताता कि कौन-सा पूल उपयोग करना है।

जो रिले आगे भेजता है पर कभी उत्तर नहीं पाता, वह सामान्यतः वापसी-मार्ग की समस्या है। स्कोप बदलने से पहले रिले पते तक वापसी मार्ग जाँचें।

DHCP को ARP से और सुरंग के पतों से अलग रखें

DHCP UDP/IP पर चलता है। Ethernet पर, होस्ट ARP का भी उपयोग कर सकता है यह देखने के लिए कि उम्मीदवार पता पहले से उपयोग में है या नहीं। वह टकराव-जाँच एक अलग लिंक-स्थानीय क्रिया है, DHCP संदेशों का परिवहन नहीं। यह कहना कि DHCP मूलतः ARP है, ग़लत है; यह कहना कि दोनों का कभी संबंध नहीं, बहुत व्यापक है।

VPN क्लाइंट अपना सुरंग-पता DHCP ब्रॉडकास्ट के बजाय VPN प्रोटोकॉल या सर्वर के अपने पूल से भी पा सकता है। जिस विकल्प के नाम में DHCP है, वह धकेली गई क्लाइंट सेटिंग्स बता सकता है, रिले किया गया DHCP पैकेट नहीं। यह मानने से पहले कि DHCP शामिल ही है, सर्वर का पूल जाँचें।

प्राप्तकर्ता नेटवर्क, आवंटन का स्वामी, स्कोप, रिले है या नहीं, और रुकावट के दौरान अपेक्षित व्यवहार दर्ज करें। फिर उस मॉडल से नई लीज़ और नवीनीकरण जाँचें। यदि दो साइटें एक ही अनियंत्रित पूल की सेवा कर सकती हैं, तो आपके पास पहले घूमने वाले लैपटॉप की प्रतीक्षा करता टकराव है।