กระบวนการ Linux ใดรับผิดชอบการตอบสนองต่อการปิง

ฉันมีตัวควบคุมกระบวนการที่ใช้ Linux ซึ่งล็อคบางครั้งถึงจุดที่คุณไม่สามารถ ping ได้ (เช่นฉันสามารถ ping ได้จากนั้นมันจะไม่สามารถ ping ได้อีกต่อไปหากไม่มีการแก้ไขการตั้งค่าเครือข่าย)

ฉันอยากรู้อยากเห็นว่ากระบวนการ / ระบบใดรับผิดชอบต่อการตอบสนองต่อการส่ง Ping จริง ๆ ? ดูเหมือนว่ากระบวนการนี้จะล้มเหลว

network-interface ping icmp

— Izzo
แหล่งที่มา

คุณยังสามารถ ssh เข้าไปได้ในขณะที่มันไม่ตอบสนองต่อการปิงหรือไม่? หรือเซสชัน SSH ที่มีอยู่ล็อคไว้หรือไม่?

— Peter Cordes

@PeterCordes ระบบทั้งหมดล็อคและเป็นหลักเป็นอิฐจนกว่าจะบังคับให้รีบูต

— Izzo

ตกลงปกติแล้ววิธีเดียวที่เครื่องจะหยุดตอบสนองต่อการปิง มันจะแปลกถ้า ping หยุดทำงาน แต่สิ่งอื่น ๆ ยังคงทำงานอยู่เนื่องจากการจัดการ ping ทำงานแม้ว่าผู้ใช้จะถูก hosed พื้นที่และทุกอย่างถูกบล็อกบนดิสก์ I / O ไปยังดิสก์ที่ตายแล้วหรือ NFS mount หรืออะไรก็ตาม ลองเชื่อมต่อจอภาพกับระบบของคุณและดูว่ามีข้อความคอนโซลขณะล็อกหรือไม่ (และถ้าคุณสามารถใช้ลำดับแป้นพิมพ์ SysRQ เวทมนต์เพื่อถ่ายโอนข้อมูลหรือนับใหม่แบบอ่านอย่างเดียวให้บังคับให้ซิงค์ดิสก์ + บูตใหม่

— Peter Cordes

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

— Pedro Lobito

@PedroLobito บันทึกอะไรเป็นพิเศษ?

— Izzo

คำตอบ:

สแต็กเครือข่ายเคอร์เนลกำลังจัดการข้อความ ICMP ซึ่งเป็นข้อความที่ส่งโดยpingคำสั่ง

หากคุณไม่ได้รับคำตอบนอกเหนือจากปัญหาเครือข่ายหรือการกรองและการกรองตามโฮสต์ / การ จำกัด อัตรา / black-holing / etc มันหมายถึงเครื่องอาจมีบางสิ่งบางอย่างมากเกินไปซึ่งอาจเป็นแบบชั่วคราวหรือเคอร์เนลขัดข้องซึ่งหายาก แต่สามารถเกิดขึ้นได้ (ฮาร์ดแวร์ผิดพลาด ฯลฯ ) ไม่จำเป็นเนื่องจากการรับส่งข้อมูล ICMP (แต่พยายามโหลดด้วยการรับส่งข้อมูลเช่นนั้น) อาจเป็นการทดสอบที่ดีเมื่อเริ่มต้นชีวิตของเซิร์ฟเวอร์เพื่อดูว่าเซิร์ฟเวอร์สามารถสนับสนุนสิ่งต่าง ๆ ได้อย่างไร) ในกรณีที่เกิดข้อผิดพลาดของเคอร์เนลคุณควรมีข้อมูลเพียงพอในล็อกไฟล์หรือบนคอนโซล

นอกจากนี้โปรดทราบว่าpingเกือบจะเป็นเครื่องมือที่ผิดเสมอในการตรวจสอบว่าบริการออนไลน์หรือไม่ ด้วยเหตุผลต่าง ๆ แต่ส่วนใหญ่เป็นเพราะมันไม่ได้เลียนแบบปริมาณการใช้งานจริงตามคำจำกัดความ ตัวอย่างเช่นถ้าคุณต้องการตรวจสอบว่าเว็บเซิร์ฟเวอร์ยังคงทำงานอยู่คุณควรทำแบบสอบถาม HTTP แทน (TCP พอร์ต 80 หรือ 443) หากคุณต้องการตรวจสอบเซิร์ฟเวอร์อีเมลที่คุณทำแบบสอบถาม SMTP (พอร์ต TCP 25) ถ้า เซิร์ฟเวอร์ DNS, UDP และแบบสอบถาม TCP ไปยังพอร์ต 53 เป็นต้น

— Patrick Mevzek
แหล่งที่มา

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

— Patrick Mevzek

ในสถานการณ์โอเวอร์โหลดส่วนใหญ่สิ่งเดียวที่ยังคงตอบสนองนั้นเป็นสิ่งที่ทำโดยเคอร์เนล นั่นหมายความว่าเครื่องจะตอบสนองต่อการ ping โดยไม่คำนึงว่ามันทำงานหนักเกินไป ความพยายามในการเข้าถึงพอร์ตที่ปิดจะตอบสนองกับ RST สำหรับ TCP และข้อผิดพลาด ICMP ในกรณีของ UDP และความพยายามสองสามครั้งแรกในการเข้าถึงพอร์ต TCP แบบเปิดจะเป็นการจับมือให้เสร็จสมบูรณ์ ความล้มเหลวของดิสก์สามารถนำไปสู่อาการเดียวกันมาก

— kasperd

@kasperd ฉันได้เห็นเซิร์ฟเวอร์มากเกินไป (มากโดยเฉพาะการแลกเปลี่ยน) โดยไม่ตอบกลับคำขอ ICMP เช่นกัน และแน่นอนยังไม่มีอะไรอื่นอีกด้วย เคอร์เนลไม่ได้ผิดพลาดมันไม่ว่างในดิสก์ I / O

— Patrick Mevzek

@Nacht Yup อินเทอร์เฟซเครือข่ายเป็นอุปกรณ์ HW เช่นนั้นมีเคอร์เนลไดรเวอร์เพื่อเชื่อมต่อกับมัน เลเยอร์ที่สองจะให้ API การจัดการ / การสื่อสารทั่วไป (สิ่งนี้ไม่ซ้ำกับระบบเครือข่าย: มี ALSA สำหรับผู้พัฒนาระบบเสียง, วิดีโอใช้ KMS API, USB มี {U, E, X} HCI, จากนั้น usb_storage, usbhid, ฯลฯ ) ตารางเส้นทางเครือข่าย, กฎไฟร์วอลล์ (ผ่าน iptables ), การจับมือกัน, การประกอบแพ็กเก็ต, retransmits ฯลฯ ทั้งหมดอยู่ในเคอร์เนล เนื่องจาก ICMP เป็นโปรโตคอลแก่ตัวเองโดยไม่มีส่วนของข้อมูลและไม่มีการประมวลผลเกินกว่า "ตอบสนองหรือไม่" เคอร์เนลจัดการการตอบสนองของ ICMP โดยตรงสำหรับค่าใช้จ่ายน้อยที่สุด

— FeRD

@Nacht: มันไม่เกี่ยวกับสถาปัตยกรรมคอมพิวเตอร์พื้นฐานจริงๆ มันเป็นตัวเลือกการใช้งาน Microkernels จะจัดการ ICMP ในกระบวนการของระบบปฏิบัติการ

— MSalters

ไม่มีกระบวนการ userland ที่รับผิดชอบในการตอบสนองต่อการปิง Ping เป็นเพียงเครื่องมือในการส่งแพ็คเก็ตก้อง ICMP สิ่งเหล่านี้ได้รับและดำเนินการโดยเครือข่ายสแต็คของเคอร์เนล

— Outurnate
แหล่งที่มา

เคอร์เนลตัวเอง (ไม่ดำเนินการใด ๆ ของผู้ใช้) เป็นผู้รับผิดชอบในการส่งICMP Echo ตอบข้อความในการตอบสนองต่อICMP ก้องคำขอข้อความ ดังนั้นหากโฮสต์หยุดตอบสนองต่อการปิงมักจะเกิดจากสาเหตุบางประการดังต่อไปนี้:

การเชื่อมต่อเครือข่ายระหว่างคุณกับโฮสต์ที่ถูก ping อาจไม่ได้ผล อาจเป็นเพราะสาเหตุหลายประการ: ความเสียหายทางกายภาพต่อสายเคเบิล, เสียงรบกวนในกรณีของตารางไร้สาย, เส้นทางที่แตก, คุณอยู่ภายใต้การโจมตี DDoS, เราเตอร์ / สวิตช์ที่มีปัญหาในระหว่าง ฯลฯ คุณจะเริ่มแก้ไขปัญหาในกรณีนี้ โดยใช้ethtool(8), iwconfig(8), route(8), ping(8)เราเตอร์ของตนtcpdump(8)ฯลฯ ในพื้นที่เป้าหมาย
การตั้งค่าไฟร์วอลล์ในโฮสต์เป้าหมาย (หรือเราเตอร์ / ไฟร์วอลล์ใด ๆ ระหว่างคุณและโฮสต์เป้าหมาย) อาจ จำกัด จำนวนปิง (หรือปริมาณการรับส่งข้อมูล) อาจเป็นเพราะเครื่องมือเช่นfail2ban(8)ไฟร์วอลล์ที่ต้องการ iptables(8)ตรวจสอบดู
ซอฟต์แวร์ / ฮาร์ดแวร์ทำงานผิดปกติที่โฮสต์เป้าหมาย โมดูลเคอร์เนลเครือข่ายบนโฮสต์เป้าหมายอาจมี OOPSed และ / หรือสับสนหรือแม้แต่เคอร์เนลทั้งหมดอาจมี PANICked คุณจะเห็นข้อความเกี่ยวกับที่อยู่dmesg(8)บนโฮสต์เป้าหมายหรือเป็นหน้าจอเอาต์พุตบนฟิสิคัลคอนโซล (หากการเข้าถึงแบบฟิสิคัลไม่สามารถทำได้เครื่องที่มีคอนโซลแบบอนุกรมสามารถช่วยได้) หากเคอร์เนล OOPS / PANIC เป็นปัญหาเคอร์เนลใหม่ที่มีไดรเวอร์ที่ดีกว่า ความช่วยเหลือหรือคุณสามารถตัดรอบการล็อกระบบด้วยwatchdog(8)และไดรเวอร์ตัวช่วย หรือคุณสามารถเปลี่ยนชิ้นส่วนฮาร์ดแวร์

— Matija Nalis
แหล่งที่มา

สำหรับผู้สนใจนี่คือรหัสเคอร์เนลที่เกี่ยวข้องสำหรับการจัดการคำขอ ICMP echo

— Ruslan

คุณควรพูดถึงโหลดที่สูงมาก (cpu พิเศษ)

— Guilherme Bernal

@GuilhermeBernal ไม่แม้แต่ผู้ใช้ CPU ที่โหลดสูงมาก (เป็นพัน) จะไม่นำไปสู่การสูญเสีย ICMP (เพราะให้บริการในเคอร์เนลก่อนที่ผู้ใช้จะได้รับโอกาสให้ประมวลผล) อัตรา PPS ของเครือข่ายที่สูงมากเมื่อใช้ร่วมกับฮาร์ดแวร์ระดับต่ำสุดอาจทำให้แพ็กเก็ตสูญหาย แต่ DDoS ดังกล่าวอยู่ในหมวดหมู่ "การเชื่อมต่อเครือข่าย"

— Matija Nalis