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 संलग्न छ भनी मान्नुअघि सर्भरको पूल जाँच्नुहोस्।

प्राप्तकर्ता सञ्जाल, बाँडफाँटको मालिक, स्कोप, रिले छ कि छैन, र अवरोधका बेला अपेक्षित व्यवहार अभिलेख गर्नुहोस्। त्यसपछि त्यो मोडेलबाट नयाँ लिज र नवीकरण परीक्षण गर्नुहोस्। यदि दुई साइटले एउटै अव्यवस्थित पूललाई सेवा दिन सक्छन् भने, पहिलो घुम्ने ल्यापटपको प्रतीक्षा गरिरहेको द्वन्द्व तपाईंसँग छ।