VPN मधून DHCP: ब्रॉडकास्ट ब्रिज करायचा की रिले करायचा?
बोगद्याच्या पलीकडील क्लायंटना पत्ता मिळत नाही. ब्रॉडकास्ट नेणार की रिले करणार हे ठरवा, आणि DHCP ला ARP पासून वेगळे ठेवा.
बोगद्याच्या पलीकडील नवीन लॅपटॉपला पत्ता मिळत नाही, तर तोच लॅपटॉप मुख्यालयात चालतो. सहसा पहिला अंदाज असतो की बोगदा 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 अजिबात सहभागी आहे असे गृहीत धरण्यापूर्वी सर्व्हरचा पूल तपासा.
प्राप्तकर्ता नेटवर्क, वाटपाचा मालक, स्कोप, रिले आहे का आणि खंड पडल्यास अपेक्षित वर्तन नोंदवा. नंतर त्या मॉडेलने नवीन लीज आणि नूतनीकरण तपासा. दोन साइट एकाच अनियंत्रित पूलची सेवा देऊ शकत असतील, तर पहिल्या फिरत्या लॅपटॉपची वाट पाहणारा संघर्ष तुमच्याकडे आहे.