DHCP क्लाइंट कैसे जानते हैं कि कौन से DHCPOFFERS को स्वीकार करना है?

Question

कल्पना कीजिए कि हमारे पास चित्र में जैसा नेटवर्क है। एक परत 2 नेटवर्क पर छह होस्ट, कोई वीएलएएन नहीं। नेटवर्क को दो सबनेट में विभाजित किया जाना चाहिए, जिसमें एक डीएचसीपी सर्वर होगा। डीएचसीपी सर्वर ने आईपी पते तय किए हैं, इसलिए उन्हें पता है कि वे किस सबनेट में हैं, जाहिर है।

तब नए क्लाइंट प्लग इन हो जाते हैं। उन्हें इस बारे में कुछ भी पता नहीं होता है कि वे किस सबनेट में आने वाले हैं और अपने DHCPDISCOVER को ईथरनेट पर 255.255.255.255 पर प्रसारित करते हैं, इसलिए यह दोनों डीएचसीपी सर्वर पर जाता है। दोनों सर्वर एक प्रस्ताव के साथ उत्तर देते हैं। अब यहाँ मेरा सवाल है: ग्राहक को कैसे पता चलता है कि उसे कौन सा DHCPOFFER स्वीकार करना है?

Comments

इस सवाल और जवाब की वहां तुलना करें ।

— कामिल मैकियोरोस्की

यहाँ एक और संबंधित प्रश्न है ।

— कास्परड

"ईथरनेट प्रसारण 255.255.255.255" - यह स्थानीय नेटवर्क के लिए आईपी प्रसारण पता है, न कि ईथरनेट पता। प्रारंभिक डीएचसीपी डिस्कोवर संदेश भी ईथरनेट प्रसारण पते ff: ff: ff: ff: ff: ff: का उपयोग करने की बहुत संभावना है, लेकिन वे वास्तव में एक ही चीज नहीं हैं।

— ilkachachu

Answer 1

सरलतम उत्तर - पहले आओ पहले पाओ।

यदि आपके पास कई वीएलएएन थे और 10.10.10.0/24 एक अलग वीएलएएन से 10.10.20.0/24 पर था - प्रसारण वीएलएएन को पार नहीं करेगा।

यदि डीएचसीपी सर्वर ग्राहकों के लिए एक अलग वीएलएएन पर था, तो vlans के बीच रूटिंग इंटरफ़ेस पर एक iphelper सही स्थान पर प्रसारण को निर्देशित करेगा।

आपके परिदृश्य में जहां आपके पास एक ही वीएलएएन (या इसके अभाव) के भीतर 2 अलग-अलग नेटवर्क हैं, जो अलग-अलग सबनेट की सेवा करते हैं - इसकी एक दौड़।

डीएचसीपी निम्नलिखित लेनदेन का उपयोग करते हुए कार्य करता है:

1. DHCP डिस्कवरी (DHCPDISCOVER) - क्लाइंट ब्रॉडकास्ट - "क्या वहाँ DHCP सर्वर बाहर है?"
2. DHCP ऑफ़र (DHCPOFFER) - क्लाइंट को सर्वर - "हाँ, मैं यहाँ हूँ और उपलब्ध हूँ!"
3. DHCP अनुरोध (DHCPREQUEST) - क्लाइंट टू सर्वर "विस्मयकारी, क्या मुझे कोई पता हो सकता है?"
4. DHCP पावती (DHCPACK) - सर्वर टू क्लाइंट "ज़रूर, यहाँ एक IP, एक मुखौटा, एक प्रवेश द्वार, कुछ DNS / WINS सर्वर, एक समय सर्वर और आपके कार्यक्षेत्र के लिए कॉन्फ़िगर किए गए अन्य सभी सामान"

यह सब सर्वर के लिए यूडीपी पोर्ट 67 और क्लाइंट के लिए 68 पर होता है।

जैसे ही चरण 2 पहुंच जाता है - ग्राहक अन्य डीएचसीपी सर्वर प्रतिक्रियाओं के लिए "सुनना" बंद कर देगा - इसका खुश सर्वर पहले सर्वर के साथ इसे कुछ ध्यान देने के लिए।

साइड नोट के रूप में - वास्तव में DoS (Denial of Service) हमलों की एक प्रसिद्ध श्रृंखला है जो इस अधिकार का दुरुपयोग करती है। एक हमलावर एक उपकरण में प्लग करता है जो प्रतिक्रिया करता है और DHCPOFFER पैकेट भेजता है और फिर पूछे जाने पर DHCPACK बाहर नहीं भेजता है ... बार-बार। एक और DoS हमला भी है जहाँ "नकली" डीएचसीपी सर्वर उन पतों की पेशकश करते हैं जिन्हें रूट नहीं किया जा सकता है या जो अन्य आईपी के साथ संघर्ष करता है वह नेटवर्क के साथ गड़बड़ करने के लिए सूँघा हुआ है।

Comments

और इसलिए "लेकिन फिर मैं एक लेयर -2 सेगमेंट पर कई सबनेट कैसे चलाते हैं?" " आप नहीं हैं। " (हां, इसके तरीके हैं, लेकिन यह कुछ ऐसा नहीं है जो आपको आम तौर पर करना चाहिए । एक परत -2 डोमेन

— user1686

धन्यवाद दोस्तों, कि वास्तव में मेरे साथ क्लिक किया। मैं हमेशा सोचता था कि यह कैसे संभव होगा, लेकिन यह बस नहीं है। तो दूर ले जाना है: वीएलएएन के साथ सबनेट या सेगमेंट के बीच एक राउटर / लेयर 3 स्विच करें, क्या मैं सही हूं?

— माइकल नीमानंद

सामान्य तौर पर, हाँ, आपको वीएलएएन या भौतिक विभाजन की आवश्यकता है। L2 डोमेन को साझा करना केवल तभी उचित होगा जब आपके दोनों डीएचसीपी सर्वर "ज्ञात" क्लाइंट्स को संभालने के लिए प्रतिबंधित हों (उदाहरण के लिए अनुमत मैक पते के साथ 'स्थिर पट्टों की सूची')।

— user1686

मुझे लगता है कि आप प्रत्येक डीएचसीपी सर्वर को मैक पते का एक श्वेत सूची दे सकते हैं और नियंत्रण कर सकते हैं कि किस ग्राहक को उस सर्वर से एक पता मिलता है।

— डैरेन

@ शुद्धता, आप आसानी से एक ही लेयर -2 सेगमेंट पर कई आईपी सबनेट चला सकते हैं, यदि सबनेट बराबर हैं, और आपको ध्यान नहीं है कि किस क्लाइंट को किस सबनेट से एड्रेस मिलता है। आपके पास बस एक डीएचसीपी सर्वर है जो दोनों ब्लॉकों से पते देता है, और एक रूटर जो दोनों ब्लॉकों के लिए एक प्रवेश द्वार के रूप में कार्य करता है (प्रत्येक में एक पते के साथ)। किया हुआ। केवल "आप नहीं" कहना सादा गलत है।

— ilkkachu

Answer 2

मौजूदा उत्तर @ Fazer87 से व्यवहार में मोटे तौर पर सही है और मैं upvoting और यह स्वीकार करने की सलाह देते हैं। यह उत्तर एक छोटे से अधिक सटीक विस्तार की पड़ताल करता है।

---

दोनों DHCP सर्वर एक DHCPOffer संदेश के साथ प्रतिक्रिया कर सकते हैं।

एक डीएचसीपी क्लाइंट उन्हें "पहले आओ, पहले पाओ" आधार पर स्वीकार कर सकता है। हालांकि, उस दृष्टिकोण को लेने की आवश्यकता नहीं है।

RFC2131 निर्दिष्ट करता है:

क्लाइंट को एक या अधिक सर्वर से एक या अधिक DHCPOFFER संदेश प्राप्त होते हैं। ग्राहक कई प्रतिक्रियाओं के लिए प्रतीक्षा करना चुन सकता है। क्लाइंट एक सर्वर चुनता है जिसमें से DHCPOFFER संदेशों में दिए गए कॉन्फ़िगरेशन मापदंडों के आधार पर कॉन्फ़िगरेशन मापदंडों का अनुरोध किया जाता है।

इसलिए, अगर दूसरे डीएचसीपी सर्वर ने एक लंबा आईपी पता आरक्षण की पेशकश की, या एक समय-सर्वर की पेशकश की जहां दूसरे ने नहीं किया, या शायद एक कस्टम फ़ील्ड था जिसे क्लाइंट को पसंद करने के लिए प्रोग्राम किया गया था, यह दूसरा प्रस्ताव स्वीकार कर सकता है।

आमतौर पर, एक "पहले आओ, पहले पाओ" दृष्टिकोण आपको वह ऑफ़र प्राप्त करने जा रहा है जो कि डिवाइसों (BOOTP rebroadcasts) में कई हॉप्स के माध्यम से नहीं हुआ है, इसलिए यह पालन करने के लिए एक अच्छा प्रोटोकॉल है यदि आपके पास देखभाल करने का कोई कारण नहीं है।

मैं एक परियोजना पर था, जहां एक कस्टम डिवाइस एक डीएचसीपीऑफ़र को प्राथमिकता देता है जिसमें एक टीएफटीपी सर्वर शामिल होता है जहां अपडेट फ़र्मवेयर पाया जा सकता है।

Comments

... या यदि एक सर्वर ने एक पता दिया जो क्लाइंट ने पहले ही इस्तेमाल कर लिया था और रखना चाहता था

— ilkkachu

@ilkachachu: हाँ, सिद्धांत रूप में, लेकिन इसके लिए बेहतर तंत्र हैं (दोनों पुराने डीएचसीपी सर्वर के साथ समाप्त होने से पहले आरक्षण को नवीनीकृत करते हैं, या पुराने आईपी पते का अनुरोध करने वाले डीएचसीपीडिस्कवरी को भेजते हैं) इसलिए यह व्यवहार में उपयोगी होने की संभावना नहीं है।

— Od