Quá trình Linux nào chịu trách nhiệm trả lời ping?

Tôi có một bộ điều khiển quy trình dựa trên Linux đôi khi khóa đến mức bạn không thể ping nó (tức là tôi có thể ping nó, sau đó nó không còn có thể ping được nữa mà không cần sửa đổi cài đặt mạng).

Tôi tò mò, quá trình / hệ thống nào chịu trách nhiệm thực sự phản ứng với ping? Có vẻ như quá trình này là sụp đổ.

network-interface ping icmp

— Izzo
nguồn

Bạn vẫn có thể ssh vào nó trong khi nó không phản ứng với ping? Hoặc các phiên SSH hiện có bị khóa?

— Peter Cordes

@PeterCordes Toàn bộ hệ thống khóa và về cơ bản là một cục gạch cho đến khi buộc phải khởi động lại.

— Izzo

Ok, đó thường là cách duy nhất để máy ngừng phản ứng với ping. Sẽ thật kỳ lạ nếu ping ngừng hoạt động nhưng các công cụ khác vẫn hoạt động, bởi vì xử lý ping hoạt động ngay cả khi không gian người dùng bị hoen rỉ và mọi thứ bị chặn trên đĩa I / O vào đĩa chết hoặc ngàm NFS hoặc bất cứ điều gì. Hãy thử kết nối màn hình với hệ thống của bạn và xem liệu có thông báo bàn điều khiển không khi nó bị khóa. (Và nếu bạn có thể sử dụng các chuỗi bàn phím SysRQ kỳ diệu để kết xuất thông tin hoặc truy cập lại chỉ đọc, buộc đồng bộ hóa các đĩa + khởi động lại.

— Peter Cordes

Mặc dù câu hỏi của bạn rất thú vị, ping không phải là nguồn gốc của các vấn đề trong hệ thống của bạn, mà là hậu quả của một hệ thống không ổn định. Kiểm tra nhật ký để hiểu những gì sai.

— Pedro lobito

@PedroLobito Nhật ký cụ thể là gì?

— Izzo

Câu trả lời:

Ngăn xếp mạng kernel đang xử lý các thông điệp ICMP, đó là những thông điệp được gửi bởi pinglệnh.

Nếu bạn không nhận được trả lời, bên cạnh các sự cố mạng hoặc lọc, và lọc dựa trên máy chủ / giới hạn tỷ lệ / holing / v.v. điều đó có nghĩa là máy có thể bị quá tải bởi một thứ gì đó, có thể là tạm thời hoặc hạt nhân bị hỏng, điều này rất hiếm nhưng có thể xảy ra (phần cứng bị lỗi, v.v.), không nhất thiết là do lưu lượng ICMP (nhưng cố gắng quá tải nó với lưu lượng như vậy có thể là một thử nghiệm tốt khi bắt đầu cuộc sống của một máy chủ để xem nó duy trì mọi thứ như thế nào). Trong trường hợp sau sự cố kernel, bạn nên có nhiều thông tin trong tệp nhật ký hoặc trên bàn điều khiển.

Cũng lưu ý rằng pinghầu như luôn luôn là công cụ sai để kiểm tra xem một dịch vụ có trực tuyến hay không. Vì nhiều lý do, nhưng chủ yếu là vì nó không bắt chước lưu lượng ứng dụng thực, theo định nghĩa. Ví dụ: nếu bạn cần kiểm tra xem máy chủ web có còn hoạt động hay không, thay vào đó bạn nên thực hiện truy vấn HTTP tới nó (cổng TCP 80 hoặc 443), nếu bạn cần kiểm tra máy chủ thư bạn thực hiện truy vấn SMTP (cổng TCP 25), nếu máy chủ DNS, UDP và truy vấn TCP tới cổng 53, v.v.

— Patrick Mevzek
nguồn

@ Khởi động bất kỳ thử nghiệm dịch vụ ứng dụng nào khác sẽ không thành công hoặc hết thời gian chờ nên kết quả cuối cùng được quan sát sẽ giống nhau. Tôi không bao giờ bỏ lỡ cơ hội giảng bài chống lại việc sử dụng pingvì điều này tạo ra quá nhiều sai sót tích cực trong việc khắc phục sự cố vì vậy tôi nghĩ rằng người dùng không biết chính xác ping là gì và làm thế nào nó có thể mang lại kết quả sai lệch.

— Patrick Mevzek

Trong hầu hết các tình huống quá tải, những thứ duy nhất vẫn đáp ứng là những thứ được thực hiện bởi kernel. Điều đó có nghĩa là một máy thường sẽ phản hồi ping bất kể nó bị quá tải như thế nào. Nỗ lực tiếp cận cổng đóng sẽ phản hồi với RST cho TCP và lỗi ICMP trong trường hợp UDP. Và một vài lần thử đầu tiên để tiếp cận cổng TCP mở sẽ hoàn thành một cái bắt tay. Một lỗi đĩa có thể dẫn đến khá nhiều triệu chứng tương tự.

— kasperd

@kasperd Tôi đã thấy (rất) các máy chủ bị quá tải (cụ thể là trao đổi) không trả lời các yêu cầu của ICMP. Và tất nhiên không có gì khác. Nhân không bị sập, nó chỉ bận trong công cụ I / O trên đĩa.

— Patrick Mevzek

@ Du thuyền Yup. Giao diện mạng là một thiết bị CTNH; như vậy có một trình điều khiển hạt nhân để giao diện với nó. Một lớp thứ hai sau đó cung cấp các API quản lý / truyền thông chung. . ), bắt tay, lắp ráp gói, truyền lại, v.v ... đều là trong kernel. Vì ICMP là một giao thức tự nó, không có tải trọng và không xử lý ngoài "phản hồi hoặc không", hạt nhân xử lý các phản hồi ICMP trực tiếp cho chi phí tối thiểu.

— FeRD

@Nacht: Nó không thực sự về kiến trúc máy tính cơ bản; đó là một lựa chọn thực hiện. Microkernels sẽ xử lý ICMP trong một quy trình HĐH.

— MSalters

Không có quy trình người dùng chịu trách nhiệm trả lời ping. Ping chỉ là một tiện ích để gửi các gói ICMP echo. Chúng được nhận và xử lý bởi ngăn xếp mạng của kernel

— Hướng ngoại
nguồn

Bản thân hạt nhân (không phải bất kỳ quá trình người dùng nào) có trách nhiệm gửi các tin nhắn trả lời tiếng vang ICMP để đáp lại các tin nhắn yêu cầu tiếng vang ICMP . Vì vậy, nếu một máy chủ ngừng phản ứng với ping, thường là do một số lý do sau:

kết nối mạng giữa bạn và máy chủ được ping có thể đã bị cắt đứt. Đó có thể là do hàng tấn lý do: hư hỏng vật lý đối với dây cáp, tiếng ồn trong trường hợp không dây, bảng tuyến bị hỏng, bạn đang bị tấn công DDoS, bộ định tuyến / chuyển mạch có vấn đề ở giữa, v.v. Bạn sẽ bắt đầu khắc phục sự cố trong trường hợp này bằng cách sử dụng ethtool(8), iwconfig(8), route(8), ping(8)bộ định tuyến của nó, tcpdump(8)vv trên host mục tiêu.
cài đặt tường lửa trên máy chủ đích (hoặc bất kỳ bộ định tuyến / tường lửa nào ở giữa bạn và máy chủ đích) có thể bị giới hạn số lượng ping (hoặc lượng lưu lượng truy cập). Nó cũng có thể là do các công cụ như công cụ fail2ban(8)tường lửa theo yêu cầu. Xem iptables(8)để kiểm tra.
đã có sự cố phần mềm / phần cứng tại máy chủ đích. Mô-đun hạt nhân mạng trên máy chủ đích có thể bị OOPSed và / hoặc bị lẫn lộn, hoặc thậm chí toàn bộ hạt nhân có thể có PANICked. Bạn sẽ thấy các thông báo về ở dmesg(8)trên máy chủ đích hoặc như đầu ra màn hình trên bảng điều khiển vật lý (nếu truy cập vật lý là không thực tế, một máy khác có bàn điều khiển nối tiếp có thể trợ giúp.) Nếu kernel OOPS / PANIC là vấn đề, kernel mới hơn có trình điều khiển tốt hơn có thể giúp đỡ, hoặc bạn có thể loại bỏ xung quanh việc khóa hệ thống watchdog(8)và trình điều khiển trợ giúp. Hoặc bạn có thể thay đổi các bộ phận phần cứng.

— Matija Nalis
nguồn

Đối với người quan tâm, đây là mã hạt nhân có liên quan để xử lý các yêu cầu tiếng vang ICMP.

— Ruslan

bạn cũng nên đề cập đến tải rất cao (đặc biệt là cpu)

— Guilherme Bernal

@GuilhermeBernal không, thậm chí tải người dùng CPU cực cao (tính bằng nghìn) sẽ không dẫn đến mất ICMP (vì nó được phục vụ trong kernel, trước khi các tiến trình của người dùng có cơ hội chạy). Tốc độ PPS mạng cực cao kết hợp với phần cứng cấp thấp có thể gây mất gói, nhưng DDoS như vậy thuộc danh mục "kết nối mạng"

— Matija Nalis