เรามีปัญหาแปลก ๆ ที่ฉันหวังว่าจะมีคนช่วยได้ เรามีอาคารที่มีวงจรไฟเบอร์และวงจรสำรอง Comcast (coax)
ระบบตั้งค่าดังนี้:
Fiber NID (สาย cat6 เพื่อสลับ) Comcast (สาย cat6 เพื่อสลับ) | สวิตช์ที่ไม่มีการจัดการ | Unbuntu Linux Box เป็นเราเตอร์ (สาย cat6 จากพอร์ต WAN ไปยัง Switch) | พอร์ต LAN เป็นไฟเบอร์ OLT | พอร์ต GPON ไฟเบอร์ 4 พอร์ตไปยัง ONT จำนวนมาก
เราเขียนสคริปต์ทุบตีที่จะตรวจสอบทุกนาทีเพื่อดูว่าเกตเวย์หลัก (วงจรไฟเบอร์) เปิดอยู่หรือไม่ ถ้าไม่ มันจะเปลี่ยนเกตเวย์เริ่มต้นเป็นเราเตอร์ Comcast 10.1.10.1 เมื่อเกตเวย์หลักกลับมาทำงานอีกครั้ง เกตเวย์จะเปลี่ยนกลับเป็นเกตเวย์โดยอัตโนมัติ
เรามีการตั้งค่าแบบเดียวกันนี้ในหลายอาคารและทำงานได้อย่างสมบูรณ์ แต่เรามีอาคารไม่กี่หลังที่เมื่อเกตเวย์เริ่มต้นเปลี่ยนไปใช้วงจร Comcast สำรอง DNS จะไม่แก้ไขตลอดเวลาและบางครั้งจะแก้ไขในภายหลัง 4 วินาทีที่เบราว์เซอร์ส่วนใหญ่หมดเวลา
สิ่งที่แปลกคือถ้าเราถอดสายเคเบิลจาก OLT ที่ไปที่พอร์ต LAN บนเราเตอร์กล่องลินุกซ์ DNS จะแก้ไขได้ดีจากบรรทัดคำสั่งในกล่องลินุกซ์และจากแล็ปท็อปที่เสียบเข้ากับพอร์ต LAN ของเราเตอร์กล่องลินุกซ์
หากเราเสียบแล็ปท็อปเข้ากับพอร์ต rj45 บน OLT จะได้รับที่อยู่ IPV6 อย่างแปลกประหลาด (Comcast แม้ว่าเราจะถอดปลั๊กเราเตอร์ Comcast ก่อนก็ตาม) จากจุดนี้ หากเราตัดการเชื่อมต่อพอร์ต GPON ไฟเบอร์ซึ่งลบผู้อยู่อาศัยออกจากสมการ การสำรองข้อมูล Comcast จะแก้ไขอย่างถูกต้องและทุกอย่างทำงานได้ดี และเราจะไม่ได้รับที่อยู่ ipv6 (เราใช้ ipv4 บนฝั่ง LAN เท่านั้น) เสียบกลับเข้าไปในพอร์ต GPON แบบไฟเบอร์สำหรับผู้อยู่อาศัยและทันที DNS จะไม่ได้รับการแก้ไขอีกต่อไป
OLT ถูกตั้งค่าด้วยการแยกพอร์ตเพื่อให้ผู้อยู่อาศัยไม่สามารถ "เห็น" ซึ่งกันและกันได้ เราพยายามตั้งค่า ACL เพื่อบล็อกทราฟฟิก IPv6 ทั้งหมด รวมถึง ipv4 ส่วนตัวทั้งหมดที่ไม่ได้อยู่ในซับเน็ต 172.16.0.0/16 แต่ไม่ได้ผล
/etc/resolv.conf
เนมเซิร์ฟเวอร์ 8.8.8.8
เนมเซิร์ฟเวอร์ 8.8.4.4
เนมเซิร์ฟเวอร์ 1.1.1.1
/etc/resolv.conf จะเหมือนกันไม่ว่าจะในวงจรสำรองหรือวงจรหลัก
/etc/network/interfaces
# ไฟล์นี้อธิบายอินเทอร์เฟซเครือข่ายที่มีอยู่ในระบบของคุณ
#และวิธีเปิดใช้งาน สำหรับข้อมูลเพิ่มเติม โปรดดูอินเทอร์เฟซ(5)
# อินเทอร์เฟซเครือข่ายย้อนกลับ
อัตโนมัติ
iface lo inet ย้อนกลับ
#อินเทอร์เฟซเครือข่าย LAN (พอร์ตขวา)
อนุญาต hotplug enp2s0
iface enp2s0 inet แบบคงที่
ที่อยู่ 172.16.1.1
เน็ตมาสก์ 255.255.0.0
######## สิ้นสุดการตั้งค่า LAN ####################################### #############
############ การตั้งค่า WAN หลัก ##################################### #############
#วัน
อนุญาต hotplug enp3s0
iface enp3s0 inet แบบคงที่
ที่อยู่ xxx.xxx.xxx.xxx
เน็ตมาสก์ 255.255.255.252
เกตเวย์ xxx.xxx.xxx.xxx
DNS-เนมเซิร์ฟเวอร์ 8.8.8.8 8.8.4.4 1.1.1.1
########### สิ้นสุดการตั้งค่า WAN หลัก
#วงจรสำรองWAN
อนุญาต hotplug enp3s0
ไอเฟซ enp3s0 inet dhcp
DNS-เนมเซิร์ฟเวอร์ 8.8.8.8 8.8.4.4 1.1.1.1
####### สิ้นสุดการตั้งค่า WAN สำรองล้มเหลว ###################################
เราทำ tcpdump เราเห็นโมเด็ม/เราเตอร์ "Comcast" หลายตัวที่ฝั่ง LAN (เราค้นหาที่อยู่ mac) ดูเหมือนว่าผู้อาศัยบางคนมี Comcast Internet และเสียบ ONT ของเรากับเราเตอร์ Comcast และมีการรั่วไหลเข้าสู่ระบบ ถ้าฉันตั้งค่า IP แบบคงที่เป็น 10.0.0.xx และเสียบเข้ากับพอร์ต ONT rj45 ฉันสามารถ ping และเรียกดู Comcast modem/router ของใครบางคนได้ เมื่อเราตั้งค่า ACL แล้ว ตอนนี้จะถูกบล็อก แต่เรายังคงมีปัญหาเดิม
โดยสรุป ดูเหมือนว่ามีบางอย่าง (อาจเป็นโมเด็ม/เราเตอร์ของ Comcast) ที่มาจาก ONT ของผู้อยู่อาศัยอย่างน้อยหนึ่งรายที่รบกวนการแก้ไข DNS แต่เมื่อระบบของเราเปลี่ยนเกตเวย์เริ่มต้นเป็นเราเตอร์สำรอง Comcast ของเราเท่านั้น ขอย้ำอีกครั้งว่าสิ่งนี้เกิดขึ้นเพียงสองอาคารจากหลายอาคารที่มีการตั้งค่าเดียวกัน ที่อาคารอื่นๆ ดูเหมือนว่าเราจะไม่เห็น "โมเด็ม/เราเตอร์ Comcast" ใดๆ ที่มาจากผู้อยู่อาศัยที่เชื่อมต่อกับระบบของเราโดยไม่ได้ตั้งใจ
ความคิดใด ๆ ?
เป็นเวลานานแล้วที่ฉันทำงานใน Telecoms แต่ฉันจะผ่านไปแล้ว
ฟังดูราวกับว่าคุณมีวงจรเครือข่าย หรืออย่างที่คุณพูด ผู้อยู่อาศัยได้สร้างรอยรั่ว เมื่อถอดสาย OLT ไปยังเราเตอร์ออก เครือข่ายจะค้นหาเส้นทางไปยังอินเทอร์เน็ตก่อนที่การสำรองข้อมูลของคุณจะเริ่มทำงาน ในกรณีนี้ เครือข่ายจะพบเส้นทางผ่านการเชื่อมต่อระหว่างผู้อยู่อาศัยกับเราเตอร์ comcast เมื่อมีการสร้างเส้นทางเช่นนี้ อาจเป็นไปได้ว่าแม้ว่าเส้นทางที่เหมาะสมกว่าจะพร้อมใช้งานเมื่อการสำรองข้อมูลปรากฏขึ้น แต่ก็ไม่ได้รีเซ็ตตารางเราเตอร์ (อาจเป็นเพราะไม่จำเป็นต้องทำ)
นั่นอาจเป็นเพราะลำดับความสำคัญของการกำหนดเส้นทาง
ปัญหาของ DNS ที่ล้มเหลวอาจเป็นเพราะพอร์ตนี้ไม่สามารถใช้งานได้ผ่านเส้นทางหลอกนี้ หรือพอร์ตนี้มีความสำคัญต่ำจนทำให้แพ็กเก็ตสูญหาย หากการค้นหา DNS เริ่มต้น (และที่นี่ความรู้ของฉันได้รับบิตที่ไม่สม่ำเสมอ) ผ่านทาง UDP อาจเป็นไปได้ว่าเมื่อย้อนกลับไปที่ TCOP เท่านั้นจึงจะผ่านได้ แต่ฉันไม่แน่ใจจริงๆที่นี่
ฉันเคยประสบปัญหาเดียวกันเมื่อหลายสิบปีที่แล้ว เมื่อเราพบว่าในลิงก์ที่ล้มเหลว มีบางคนติดตั้งลิงก์การเรียกเลขหมายที่เชื่อมต่อกับโลกภายนอกโดยอัตโนมัติ ปัญหาเดียวคือเมื่อลิงก์หลักกลับมา ลิงก์นั้นไม่ได้ปิดการเรียกเลขหมาย จากนั้นทั้งบริษัทก็กำหนดเส้นทางผ่านโมเด็ม 9.6K นี้ ใช้เวลานานในการค้นหาเพราะไม่มีใครยอมรับสิ่งที่พวกเขาทำ ดูเหมือนว่าคุณมีอะไรที่คล้ายกัน
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
