ไม่มีอินเทอร์เน็ตหลังจากการต่ออายุ DHCP


10

วันนี้เรามีหลายเครื่องหยุดการเข้าถึงอินเทอร์เน็ต หลังจากการแก้ไขปัญหาจำนวนมากเธรดทั่วไปก็คือพวกเขาทั้งหมดมีการต่ออายุ dhcp ของพวกเขาในวันนี้ (เรามีสัญญาเช่า 8 วันที่นี่)

ทุกสิ่งที่คุณคาดหวังจะดูดีหลังจากการต่ออายุสัญญาเช่า: พวกเขามีที่อยู่ IP ที่ถูกต้องเซิร์ฟเวอร์ DNS และเกตเวย์ พวกเขาสามารถเข้าถึงทรัพยากรภายใน (แชร์ไฟล์อินทราเน็ตเครื่องพิมพ์ ฯลฯ ) การแก้ไขปัญหาเล็กน้อยเพิ่มเติมพบว่าพวกเขาไม่สามารถ ping หรือ tracert ไปยังเกตเวย์ของเรา แต่พวกเขาสามารถไปที่ core layer3 switch ของเราที่ด้านหน้าของเกตเวย์ การกำหนด IP แบบคงที่ให้กับเครื่องทำงานเป็นวิธีการแก้ปัญหาชั่วคราว

หนึ่งรอยย่นขั้นสุดท้ายคือรายงานที่มาถึงแล้วสำหรับลูกค้าใน vlan เดียวกับเกตเวย์ เจ้าหน้าที่ธุรการและคณาจารย์ของเราอยู่บน vlan เช่นเดียวกับเซิร์ฟเวอร์และเครื่องพิมพ์ แต่โทรศัพท์, fob / กล้อง, นักเรียน / wifi และห้องปฏิบัติการแต่ละคนมี vlans ของตัวเองและเท่าที่ฉันไม่เห็น vlans อื่น ๆ มีปัญหา

ฉันมีตั๋วแยกต่างหากกับผู้จำหน่ายเกตเวย์ แต่ฉันคิดว่าพวกเขาจะนำเรื่องง่ายและบอกฉันว่าปัญหาอยู่ที่อื่นในเครือข่ายดังนั้นฉันจึงถามที่นี่เช่นกัน ฉันได้ทำการแคช arp บนเกตเวย์และสวิตช์หลักแล้ว ความคิดใด ๆ ยินดีต้อนรับ

อัปเดต:
ฉันลองกระตุกจากเกตเวย์กลับไปยังโฮสต์ที่ได้รับผลกระทบและสิ่งที่แปลกคือฉันได้รับการตอบกลับ: จากที่อยู่ IP ที่แตกต่างอย่างสิ้นเชิง ฉันลองสุ่มอีกสองสามครั้งและในที่สุดก็ได้สิ่งนี้:

ศ. 02 ก.ย. 2011 13:08:51 GMT-0500 (เวลาออมแสงตอนกลาง)
PING 10.1.1.97 (10.1.1.97) 56 (84) ไบต์ของข้อมูล
64 ไบต์จาก 10.1.1.105: icmp_seq = 1 ttl = 255 เวลา = 1.35 ms
64 ไบต์จาก 10.1.1.97: icmp_seq = 1 ttl = 255 เวลา = 39.9 ms (DUP!)

10.1.1.97 เป็นเป้าหมายที่ตั้งใจจริงของ ping 10.1.1.105 ควรจะเป็นเครื่องพิมพ์ในอาคารอื่น ฉันไม่เคยเห็น DUP ในคำตอบ ping มาก่อน

ฉันเดาได้ดีที่สุดในขณะนี้คือเราเตอร์ไร้สายปลอมในหนึ่งในห้องพักหอพักของเราบน 10.1.1.0/24 เครือข่ายย่อยที่มีเกตเวย์ไม่ดี

อย่างต่อเนื่อง ... ตอนนี้ฉันได้ปิดเครื่องพิมพ์ที่ละเมิดและส่ง Ping ไปยังโฮสต์ที่ได้รับผลกระทบจากเกตเวย์ก็ล้มเหลวอย่างสมบูรณ์

อัปเดต 2:
ฉันตรวจสอบตาราง arp ที่เครื่องที่ได้รับผลกระทบเกตเวย์และสวิตช์ทุกอัน ในแต่ละจุดรายการสำหรับอุปกรณ์เหล่านั้นถูกต้องทั้งหมด ฉันไม่ได้ตรวจสอบทุกรายการในตาราง แต่ทุกรายการที่อาจส่งผลกระทบต่อการรับส่งข้อมูลระหว่างโฮสต์และเกตเวย์ไม่เป็นไร ARP ไม่ใช่ปัญหา

อัปเดต 3: ขณะนี้
สิ่งต่าง ๆ กำลังทำงาน แต่ฉันไม่เห็นสิ่งที่ฉันทำเพื่อแก้ไขพวกเขาและดังนั้นฉันจึงไม่รู้ว่านี่อาจเป็นเพียงกล่อมชั่วคราว อย่างไรก็ตามมีไม่มากที่ฉันสามารถทำได้เพื่อวินิจฉัยหรือแก้ไขปัญหาในตอนนี้ แต่ฉันจะอัปเดตมากกว่านี้หากหยุดอีกครั้ง


Ping ทำงานกับเกตเวย์ของพวกเขาหรือไม่ เซิร์ฟเวอร์ DNS ที่กำหนดค่าบนซับเน็ตเดียวกันหรือที่อื่น ๆ การแก้ไข DNS ใช้งานได้หรือไม่
เชนหัวเสีย

@Shane ทุกอย่างทำงานได้ดีและได้รับคำตอบในข้อความ
Joel Coel

คุณบอกว่า "ไม่สามารถ ping หรือ tracert ไปที่เกตเวย์ของเรา" - นั่นคือเกตเวย์แรกของอุปกรณ์หรือเราเตอร์อินเทอร์เน็ตที่ปริมาณการใช้งานของพวกเขาถูกกำหนดเส้นทางไปหลังจากถูกกำหนดเส้นทางโดยอุปกรณ์กระโดดแรกอื่นหรือไม่
Shane Madden

2
ฉันจะเรียกใช้การดักจับแพ็กเก็ตบนไคลเอ็นต์ตัวใดตัวหนึ่งจากนั้น ping และติดตามเส้นทางไปยังเกตเวย์ ดูว่าที่อยู่ MAC ใดที่แสดงในการจับภาพที่อยู่ IP และค้นหาการเปลี่ยนเส้นทาง ICMP ฉันจะดูตาราง ARP อย่างใกล้ชิดกับลูกค้าสวิตช์และเกตเวย์และตรวจสอบให้แน่ใจว่าพวกเขาดูถูกต้อง
joeqwerty

1
ในการชี้แจง: คุณกำลังบอกว่าเกตเวย์มี ARP ที่ถูกต้องสำหรับโฮสต์ที่ได้รับผลกระทบและโฮสต์นั้นมี ARP ที่ถูกต้องกลับไปที่เกตเวย์ แต่เกตเวย์ไม่ได้รับคำตอบเมื่อพยายามปิงโฮสต์หรือไม่ แพ็กเก็ต ping กำลังเข้าสู่อุปกรณ์หรือไม่ได้รับการสลับอย่างถูกต้องหรือไม่?
Shane Madden

คำตอบ:


3

"การคาดเดาที่ดีที่สุดของฉันในตอนนี้คือเราเตอร์ไร้สายปลอมในหนึ่งในห้องพักในหอพักของเราบน 10.1.1.0/24 เครือข่ายย่อยที่มีเกตเวย์ไม่ดี"

สิ่งนี้เกิดขึ้นในสำนักงานของฉัน อุปกรณ์ที่ละเมิดกลายเป็นอุปกรณ์ android อันธพาล:

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

หากอุปกรณ์ android รับ IP ของเกตเวย์จากเครือข่ายอื่นผ่าน DHCP อุปกรณ์นั้นอาจเข้าร่วมเครือข่ายของคุณและเริ่มตอบสนองต่อคำขอ ARP สำหรับ IP ของเกตเวย์ด้วย MAC การใช้เครือข่าย 10.1.1.0/24 ทั่วไปของคุณเพิ่มความน่าจะเป็นของสถานการณ์โกงนี้

ฉันสามารถตรวจสอบแคช ARP บนเวิร์กสเตชันที่ได้รับผลกระทบบนเครือข่าย ที่นั่นฉันสังเกตเห็นปัญหาฟลักซ์ ARP ซึ่งเวิร์คสเตชั่นจะพลิก - ฟล็อประหว่าง MAC ที่ถูกต้องและที่อยู่ MAC จากอุปกรณ์โกงบางอย่าง เมื่อฉันค้นหา MAC ที่น่าสงสัยที่เวิร์กสเตชันใช้หาเกตเวย์มันกลับมาพร้อมกับคำนำหน้า Samsung ผู้ใช้ที่ชาญฉลาดพร้อมเวิร์กสเตชันที่มีปัญหาตอบว่าเขารู้ว่าใครมีอุปกรณ์ Samsung ในเครือข่ายของเรา กลายเป็นซีอีโอ


2

ดังที่ได้กล่าวไปแล้วในส่วนความคิดเห็นการจับแพ็คเก็ตเป็นสิ่งสำคัญมาก อย่างไรก็ตามยังมีเครื่องมือที่ยอดเยี่ยมที่เรียกว่า arpwatch:

http://ee.lbl.gov/

(หรือhttp://sid.rstack.org/arp-sk/สำหรับ windows)

เครื่องมือนี้จะส่งอีเมลถึงคุณหรือเพียงแค่เก็บบันทึกที่อยู่ MAC ใหม่ทั้งหมดที่เห็นในเครือข่ายรวมถึงการเปลี่ยนแปลงใด ๆ สำหรับที่อยู่ MAC สำหรับ IP บนเครือข่ายย่อยที่กำหนด (flip-flops) สำหรับปัญหานี้คุณจะตรวจพบทั้งทฤษฎีปัจจุบันโดยการรายงานว่ามี flip-flop เกิดขึ้นสำหรับ IP ที่เปลี่ยน MACs หรือคุณจะเห็น MAC ใหม่สำหรับเราเตอร์ rogue DHCP เมื่อเริ่มสื่อสารกับโฮสต์ ข้อเสียอย่างหนึ่งของเครื่องมือก็คือคุณต้องมีโฮสต์ที่เชื่อมต่อกับเครือข่ายทั้งหมดที่คุณตรวจสอบ แต่มีราคาเล็กน้อยสำหรับข้อมูลที่ยอดเยี่ยมที่สามารถให้เพื่อช่วยในการวินิจฉัยปัญหาเหล่านี้


1

วิธีที่รวดเร็วในการตรวจจับเซิร์ฟเวอร์โกง DHCP ทั่วไปคือการ ping เกตเวย์ที่ให้บริการแล้วตรวจสอบ MAC ของมันในตาราง ARP ที่เกี่ยวข้อง หากโครงสร้างการสลับเป็นแบบที่จัดการดังนั้น MAC สามารถติดตามลงไปที่พอร์ตที่โฮสต์และพอร์ตสามารถปิดหรือติดตามกลับไปยังตำแหน่งของอุปกรณ์ที่ละเมิดเพื่อแก้ไขเพิ่มเติม

การใช้ DHCP Snooping บนสวิตช์ที่รองรับสามารถเป็นตัวเลือกที่มีประสิทธิภาพในการปกป้องเครือข่ายจากเซิร์ฟเวอร์ DHCP อันธพาลเช่นกัน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.