Dhcp लीज नवीनीकरण के बाद कोई इंटरनेट नहीं


10

आज हमारे पास इंटरनेट पहुँच प्राप्त करने वाली कई मशीनें हैं। बहुत समस्या निवारण के बाद, सामान्य धागा यह है कि वे सभी आज अपने dhcp पट्टे को नवीनीकृत कर चुके हैं (हम यहां 8 दिनों के पट्टों पर हैं)।

लीज नवीनीकरण के बाद आपको जो कुछ भी अच्छा लगेगा, वह सब कुछ होगा: उनके पास एक वैध आईपी पता, डीएनएस सर्वर और गेटवे है। उनके पास आंतरिक संसाधनों (फ़ाइल शेयर, इंट्रानेट, प्रिंटर, आदि) तक पहुंच है। थोड़ी अधिक समस्या निवारण से पता चलता है कि वे हमारे प्रवेश द्वार के लिए पिंग या ट्रैस करने में असमर्थ हैं, लेकिन वे गेटवे के ठीक सामने हमारे कोर लेयर 3 स्विच पर जा सकते हैं। मशीन को एक स्थिर आईपी सौंपना एक अस्थायी समाधान के रूप में काम करता है।

एक अंतिम शिकन यह है कि अभी तक केवल गेटवे के रूप में एक ही वलान पर ग्राहकों के लिए रिपोर्टें आई हैं। हमारे प्रशासनिक कर्मचारी और संकाय सर्वर और प्रिंटर के रूप में एक ही vlan पर हैं, लेकिन फोन, कुंजी fob / कैमरे, छात्रों / वाईफाई, और प्रयोगशालाओं में से प्रत्येक का अपना vlans है और जहाँ तक मैंने किसी अन्य vlans पर कुछ भी नहीं देखा है अभी तक एक समस्या थी।

गेटवे विक्रेता के साथ मेरे पास एक अलग टिकट है, लेकिन मुझे संदेह है कि वे आसानी से निकाल लेंगे और मुझे बताएंगे कि समस्या नेटवर्क पर कहीं और है, इसलिए मैं यहां भी पूछ रहा हूं। मैंने गेटवे और कोर स्विच पर आरपी कैश साफ़ किया है। किसी भी विचार का स्वागत करते हैं।

अद्यतन:
मैंने कुछ प्रभावित मेजबानों के प्रवेश द्वार से पिंगिंग की कोशिश की, और अजीब बात यह है कि मुझे एक प्रतिक्रिया मिली: पूरी तरह से अलग आईपी पते से। मैं यादृच्छिक पर कुछ और की कोशिश की और अंततः यह मिल गया:

शुक्र सितंबर 02, 13:08:51 GMT-0500 (केंद्रीय डेलाइट समय)
पिंग 10.1.1.97 (10.1.1.97) 56 (84) डेटा का बाइट्स।
10.1.1.105 से 64 बाइट्स: icmp_seq = 1 ttl = 255 समय = 1.35 एमएस
10.1.1.97 से 64 बाइट्स: icmp_seq = 1 ttl = 255 समय = 39.9 एमएस (DUP)!

10.1.1.97 पिंग का वास्तविक इच्छित लक्ष्य है। 10.1.1.105 को दूसरे भवन में एक प्रिंटर माना जाता है। मैंने पहले कभी पिंग प्रतिक्रिया में एक डीयूपी नहीं देखा है।

इस समय मेरा सबसे अच्छा अनुमान एक बुरा गेटवे के साथ 10.1.1.0/24 सबनेट पर हमारे डॉर्म रूम में एक दुष्ट वाईफाई राउटर है।

... जारी रखा। मैंने अब अपमानजनक प्रिंटर को संचालित कर दिया है, और गेटवे से प्रभावित मेजबान को पिंग करता है, बस पूरी तरह से विफल हो जाता है।

अद्यतन 2:
मैं एक प्रभावी मशीन, प्रवेश द्वार, और उनके बीच हर स्विच पर arp टेबल की जाँच करता हूँ। प्रत्येक बिंदु पर, उन उपकरणों के लिए प्रविष्टियां सभी सही थीं। मैंने तालिका में प्रत्येक प्रविष्टि को सत्यापित नहीं किया, लेकिन प्रत्येक प्रविष्टि जो संभवतः मेजबान और प्रवेश द्वार के बीच यातायात को प्रभावित कर सकती थी, ठीक था। एआरपी समस्या नहीं है।

अपडेट 3:
इस समय चीजें काम कर रही हैं, लेकिन मैं उन्हें ठीक करने के लिए कुछ भी नहीं देख सकता और इसलिए मुझे नहीं पता कि क्या यह सिर्फ एक अस्थायी खामियाजा हो सकता है। वैसे भी, अब मैं निदान या समस्या निवारण के लिए बहुत कुछ नहीं कर सकता, लेकिन अगर यह फिर से टूटता है तो मैं इसे और अपडेट करूंगा।


पिंग उनके प्रवेश द्वार के लिए काम करते हैं? कॉन्फ़िगर किए गए DNS सर्वर (ओं) को एक ही सबनेट पर, या कहीं और किया जाता है? DNS रिज़ॉल्यूशन काम कर रहा है?
शेन मैडेन

@ शेन, वह सब काम करता है, और पाठ में उत्तर दिया गया है
जोएल कोल

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

2
मैं ग्राहकों में से एक पर एक पैकेट कैप्चर चलाऊंगा और फिर गेटवे के लिए पिंग और ट्रेस मार्ग। देखें कि कौन से मैक पते कैप्चर करते हैं, जिसके लिए आईपी पते और आईसीएमपी रीडायरेक्ट भी दिखते हैं। मैं क्लाइंट, स्विच और गेटवे में से किसी एक पर ARP तालिका का भी पूरा अवलोकन करूंगा और सुनिश्चित करूंगा कि वे सही दिखें।
जोकेवेटी

1
यह स्पष्ट करने के लिए: आप कह रहे हैं कि गेटवे के पास एक प्रभावित मेजबान के लिए वैध ARP है, और मेजबान के पास ARP वापस गेटवे के लिए मान्य है, लेकिन होस्ट को पिंग करने की कोशिश करने पर गेटवे को कोई जवाब नहीं मिल रहा है? डिवाइस को पिंग पैकेट मिल रहे हैं, या वे ठीक से स्विच नहीं हो रहे हैं?
शेन मैडेन

जवाबों:


3

"इस समय मेरा सबसे अच्छा अनुमान एक बुरे गेटवे के साथ 10.1.1.0/24 सबनेट पर हमारे डॉर्म रूम में एक दुष्ट वाईफाई राउटर है।"

यह मेरे कार्यालय में हुआ। अपमानजनक डिवाइस एक बदमाश Android डिवाइस निकला:

http://code.google.com/p/android/issues/detail?id=11236

यदि एंड्रॉइड डिवाइस को डीएचसीपी के माध्यम से दूसरे नेटवर्क से गेटवे का आईपी मिलता है, तो यह आपके नेटवर्क में शामिल हो सकता है और गेटवे आईपी के लिए एआरपी अनुरोधों का जवाब देना शुरू कर सकता है। सामान्य 10.1.1.0/24 नेटवर्क के आपके उपयोग से इस दुष्ट परिदृश्य की संभावना बढ़ जाती है।

मैं नेटवर्क पर एक प्रभावित कार्य केंद्र पर एआरपी कैश की जांच करने में सक्षम था। वहां, मैंने एक ARP फ्लक्स समस्या देखी, जहां वर्कस्टेशन कुछ मैक डिवाइस से सही मैक और मैक पते के बीच फ्लिप-फ्लॉप होगा। जब मैंने संदिग्ध मैक को देखा तो गेटवे के लिए वर्कस्टेशन था, यह सैमसंग उपसर्ग के साथ वापस आया। परेशान कार्य केंद्र वाले आश्चर्यजनक उपयोगकर्ता ने उत्तर दिया कि वह जानता था कि हमारे नेटवर्क पर सैमसंग डिवाइस किसके पास है। सीईओ बने।


2

जैसा कि पहले ही टिप्पणी अनुभाग में चर्चा की जा रही है कि एक पैकेट पर कब्जा वास्तव में महत्वपूर्ण है। हालांकि वहाँ भी एक महान उपकरण बुलाया arpwatch:

http://ee.lbl.gov/

(या http://sid.rstack.org/arp-sk/ खिड़कियों के लिए)

यह टूल आपको ईमेल करेगा या नेटवर्क पर देखे गए सभी नए मैक एड्रेस का एक लॉग रखेगा और साथ ही किसी दिए गए सबनेट (फ्लिप-फ्लॉप) पर आईपी के लिए मैक एड्रेस के लिए कोई बदलाव नहीं करेगा। इस समस्या के लिए आपने यह पाया होगा कि दोनों वर्तमान सिद्धांतों को या तो यह रिपोर्ट करके कि आईपी बदलने वाले एमएसीएस के लिए फ्लिप-फ्लॉप चल रहे थे, या आप दुष्ट डीएचसीपी राउटर के लिए एक नया मैक देखेंगे जब यह पहली बार मेजबानों के साथ संचार करना शुरू कर देता है। उपकरण के साथ एक नीचे की ओर यह है कि आपको उन सभी नेटवर्क से मेजबान को कनेक्ट करने की आवश्यकता है जिन्हें आप मॉनिटर करते हैं, लेकिन यह महान जानकारी के लिए एक छोटी सी कीमत है जो इन प्रकार के मुद्दों का निदान करने में मदद कर सकता है।


1

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

DHCP स्नूपिंग का उपयोग स्विच पर जो इसे समर्थन करता है, यह एक प्रभावी विकल्प के रूप में अच्छी तरह से दुष्ट डीएचसीपी सर्वर से नेटवर्क को बचाने में भी हो सकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.