ไม่มีอินเทอร์เน็ตขณะดาวน์โหลดเพลง - ดูเหมือนว่าเกี่ยวข้องกับ DNS

ฉันมีปัญหาที่แปลกมากเกี่ยวกับการเชื่อมต่ออินเทอร์เน็ตขณะดาวน์โหลดเพลง ก่อนที่คุณจะสรุปว่าฉันควร "ลด # ของการเชื่อมต่อแบบครึ่งเปิด & amp; ผู้ใช้" ให้ฉันบอกว่าฉันได้ทำแล้ว (10 การเชื่อมต่อที่เปิดครึ่ง, 20 ผู้ใช้ก็ยังไม่ทำงานและฉันไม่ได้รับ การดาวน์โหลดใด ๆ ที่เกิดขึ้นอีก)

ฉันควรจะพูดด้วยว่า QoS ไม่จำเป็น โดยปกติแล้วในประสบการณ์ของฉันกับการดาวน์โหลดเพลง (ใน linux / windows nad mac) การเชื่อมต่ออินเทอร์เน็ตนั้นถูกแชร์ในทุกกระบวนการ ดูเหมือนว่า torrents กำลังเคี้ยวแบนด์วิดท์ที่มีอยู่ทั้งหมด (เคอร์เนลไม่ควรแบ่งเวลาระหว่างกระบวนการที่ขอให้ส่ง / รับแพ็คเกจหรือไม่)

ในที่สุดฉันควรจะบอกว่าปัญหานี้เริ่มปรากฏขึ้นหลังจากฉันอัปเดตเป็นหย่อน 64 บิต v14 (จาก v13.37)

ดังนั้นปัญหาที่เกิดขึ้นจริงดูเหมือนว่าจะเกี่ยวข้องกับเซิร์ฟเวอร์ DNS ไม่ตอบสนองเมื่อฉันเริ่มดาวน์โหลดด้วย ktorrent หรือ rtorrent และไม่มีหน้าเว็บโหลดอีกต่อไป ทอร์เรนต์จะทำการดาวน์โหลดที่ความเร็วที่เหมาะสม แต่จะไม่มีการโหลดเว็บไซต์ ดังนั้น "nslookup" และ "dig" จะบอกฉันว่าเซิร์ฟเวอร์ dns (ซึ่ง btw ตั้งอยู่บนพีซีเครื่องเดียวกัน) ไม่พบ:

nslookup facebook.com
;; connection timed out; no servers could be reached

และ

nass@stargaze:~$ dig !$
dig facebook.com
; <<>> DiG 9.9.1-P3 <<>> facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26154
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;facebook.com.                  IN      A

;; Query time: 1125 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug  2 01:14:46 2013
;; MSG SIZE  rcvd: 41

รีสตาร์ทเซิร์ฟเวอร์ dns (ผูก) ในขณะที่ฝนตกหนักกำลังทำงานโดยทั่วไปจะไม่แก้ไขสิ่งต่าง ๆ แม้ว่าบางครั้งฉันก็เห็นสิ่งนี้เกิดขึ้น การหยุด dns ลบไฟล์ * .jnl ใด ๆ ที่ถูกสร้างขึ้นและการรีสตาร์ทดูเหมือนจะใช้งานได้ แต่อาจไม่ได้อีกครั้ง (ฉันไม่มีรูปแบบซ้ำสำหรับกรณีนี้) ฉันไม่สามารถพูดได้ว่าฉันพบ "วิธี" ในการรับอินเทอร์เน็ตกลับมา

• มักจะปิด ktorrent และรอสักครู่ก็สามารถแก้ไขอินเทอร์เน็ตได้ด้วยตัวเอง
• ในบางครั้งการปิดไคลเอนต์ ktorrent และการรีสตาร์ทเซิร์ฟเวอร์ DNS จะทำงานได้เร็วกว่ากรณีก่อนหน้า
• บางครั้งการรีสตาร์ทซ้ำจะไม่ทำให้ DNS ทำงานได้อีก (ให้รอสักครู่จะแก้ไขปัญหา)
• เมื่อเร็ว ๆ นี้ฉันเริ่มหยุดตั้งชื่อลบไฟล์ * .jnl แล้วเริ่มใหม่ สิ่งนี้มีความสำเร็จ 100% ในการทดลองของฉัน (เพียง 2)

ไฟล์บันทึกไฟร์วอลล์, / var / log / messages / และบันทึกของชื่อไม่ได้ลงทะเบียนอะไรแปลก ๆ

ฉันไม่ได้ใช้ tcpdump, wireshark, netstat ดังนั้นฉันไม่รู้ว่าฉันสามารถใช้เครื่องมือนี้เพื่อระบุ ... บางอย่าง! ใครช่วยได้บ้าง

เนื่องจากปัญหานี้ดูเหมือนว่าจะเกี่ยวข้องกับเซิร์ฟเวอร์ DNS ในทันทีฉันจึงผนวกไฟล์ dns ของฉันและอธิบายการกำหนดค่าพีซีของฉัน:

ดังนั้นอินเทอร์เน็ต ADSL จึงมาถึงโมเด็ม (ให้บริการโดย ISP ตลอดเวลาแม้เมื่อฉันไม่มีอินเทอร์เน็ต) โมเด็มเชื่อมต่อกับพีซีนี้บน eth1 ซึ่งฉันกำลังดาวน์โหลดเพลง พีซีเครื่องนี้เป็นเครือข่ายในบ้านและไฟล์เซิร์ฟเวอร์ของฉัน (และเดสก์ท็อปเมื่อฉันไม่อยู่ - ฉันเชื่อมต่อโดยใช้ nx) มันกำลังเรียกใช้ iptables, dns, & amp; เซิร์ฟเวอร์ squid (ในหมู่อื่น ๆ ) จากนั้นจาก eth0 ของพีซีนี้สวิตช์ wifi และอินทราเน็ตจะถูกป้อน Squid กำลังทำงานบนการกำหนดค่าแบบโปร่งใส แต่ไม่ควรยุ่งเกี่ยวกับปริมาณการใช้งาน torrent เนื่องจากจะทำบนพอร์ตอื่น (แทนที่จะเป็นพอร์ต 80)

ดังนั้นเริ่มแรกฉันแนบ named.conf ของฉันในความพยายามที่จะได้รับข้อเสนอแนะ (อาจมีบางอย่างผิดพลาดการตั้งค่าทางตรรกะที่ไม่ถูกตรวจจับจาก webmin ชื่อไฟล์ตรวจสอบการกำหนดค่า - ที่ฉันตรวจสอบซ้ำแล้วว่าไฟล์ named.conf นั้น ถูกต้องทางไวยากรณ์)

named.conf คือ ที่นี่

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

ขอบคุณมากสำหรับความช่วยเหลือของคุณ :)

แก้ไข: /etc/resolv.conf ของฉันดูเหมือนว่า:

domain skails.home
nameserver 127.0.0.1

(เคอร์เนลไม่ควรแบ่งเวลาระหว่างกระบวนการที่ขอให้ส่ง / รับแพ็คเกจหรือไม่)

สถานการณ์ทั่วไปที่มีการเชื่อมต่ออินเทอร์เน็ตช้าหรือไม่มีเลยอย่าง Bittorrent ทำให้การเชื่อมต่อของคุณแย่ลง ขาเข้า ปริมาณการใช้งานบนต้นน้ำของคุณ (ซึ่งมักจะต่ำกว่าดาวน์สตรีมของคุณในการเชื่อมต่อที่อยู่อาศัยส่วนใหญ่) มีผู้คนหนาแน่น ดังนั้น TCP ACK ที่เข้ามาจะไม่ได้รับทันเวลาและหมดเวลาเชื่อมต่อที่จุดสิ้นสุดแล้วในที่สุดก็จะสิ้นสุด

สิ่งหนึ่งที่ฉันได้เรียนรู้จากการศึกษา QoS คือไม่มีสิ่งใดที่เหมือนกับ QoS ในการรับส่งข้อมูลเนื่องจากคุณไม่สามารถควบคุมสิ่งที่ถูกส่งถึงคุณได้ คุณสามารถ QoS / หาร / แชร์ปริมาณการใช้ขาออกจริงๆเท่านั้น คุณสามารถดูการกำหนดค่า Linux QoS ปัจจุบันได้ tc - แต่ถูกเตือน tc มีความซับซ้อนมาก

อาจเป็นไปได้ว่าการเชื่อมต่อเดียวสามารถทำให้แบนด์วิดท์ที่เข้ามาของคุณเต็มไปหมดและส่งผลให้ TCP ACKs ขาเข้าส่งผลให้เกิดการชะลอตัวลดลง ฯลฯ จำนวนการเชื่อมต่อพร้อมกันนั้นไม่สำคัญ

คุณอาจต้องตั้งค่าแบนด์วิดธ์ทั้งหมดของโปรแกรม Bittorrent ที่อัปโหลดไปยังอัพสตรีมสูงสุดเช่น 8Kbit / วินาทีด้านล่างสิ่งที่คุณรู้คือความเร็วของอัพสตรีมของคุณ คุณอาจต้องการตรวจสอบ Wondershaper ถ้าคุณรู้สึกอยากลงหลุมกระต่ายนั่นคือ QoS บน Linux

เบาะแสของคุณคือบรรทัดนี้:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26154

สมมติว่า resolv.conf มีเพียง 127.0.0.1สิ่งนี้จะบอกคุณว่าคุณแคชเซิร์ฟเวอร์ได้ตัดสินใจแล้วว่าไม่สามารถติดต่อกับเซิร์ฟเวอร์ชื่อต้นน้ำหรือกำหนดค่าผิดพลาดได้ ณ จุดนั้นเซิร์ฟเวอร์กำลังจะไป ยอมแพ้ ในการสื่อสารกับโดเมนนั้น ซึ่งหมายความว่าเซิร์ฟเวอร์จะถูกเพิ่มในรายการเซิร์ฟเวอร์ชื่อง่อย ซึ่งแตกต่างจาก แคชลบ ซึ่งใช้กับ NXDOMAIN การตอบสนอง

มันยืนด้วยเหตุผลว่าครั้งเดียว facebook.com ได้รับการพิจารณาแล้วว่าจะตายแคชเนมเซิร์ฟเวอร์จะไม่รำคาญที่จะพยายามแก้ไขมันชั่วขณะ ตอนนี้คุณต้องเข้าใจสาเหตุที่เกิดขึ้น

สมมติว่าคุณกำลังประสบกับความแออัดของเครือข่ายและ facebook.com ไม่ได้อยู่ในแคช

• named จะพยายามวนรอบรายชื่อผู้ส่งต่อของคุณจนกว่าจะพบชื่อเซิร์ฟเวอร์ที่จะตอบสนองกับสิ่งอื่นที่ไม่ใช่ REFUSED สำหรับบันทึกนั้น NXDOMAIN และ SERVFAIL คำตอบที่จะยอมรับ แม้ว่าเซิร์ฟเวอร์อื่นจะตอบแตกต่างกันเซิร์ฟเวอร์ของคุณทั้งหมดใส่ใจว่าบันทึกอยู่ในแคชหรือไม่และเป็นครั้งแรก ถูกต้อง การตอบสนองที่ได้รับ
• เมื่อพบคำตอบที่จะถูกแคช ให้ดีขึ้นหรือแย่ลง
• หากไม่ได้รับคำตอบจากคำถามใด ๆ จะถือว่าเป็น SERVFAIL เช่นกัน

สำหรับการทดสอบของคุณโดยเฉพาะแบบสอบถามและการตอบสนองจะมีขนาดเล็ก UDP ไม่มีเซสชันค่าใช้จ่ายที่เกี่ยวข้องกับ TCP เพื่อรับการตอบกลับจาก SERVFAIL...

• การตอบกลับที่ถูกต้องครั้งแรกที่คุณได้รับคือ SERVFAIL สำหรับโดเมนนั้น
• ผู้ส่งทั้งหมดไม่สามารถเข้าถึงได้ คุณไม่ได้รับคำตอบจากพวกเขาทั้งหมด

วิธีเดียวที่จะรู้ว่ามีอะไรเกิดขึ้นอย่างแน่นอนคือการเริ่มต้นการดักจับแพ็กเก็ตจากนั้นรีสตาร์ทเซิร์ฟเวอร์ของคุณและวิเคราะห์แพ็กเก็ต หนึ่งในผู้ส่งของคุณอาจไม่ดีและกลับมา SERVFAIL บ่อยครั้งหรือความแออัดของคุณมีศักยภาพมากที่การค้นหา DNS เล็ก ๆ แปดรายการต่อรายการส่งต่อทั้งหมดของคุณล้มเหลว