핑에 응답하는 Linux 프로세스는 무엇입니까?

Linux 기반 프로세스 컨트롤러를 사용하여 가끔 핑할 수없는 지점까지 잠급니다 (즉, 핑할 수 있으면 네트워크 설정을 수정하지 않고는 더 이상 핑할 수 없음).

궁금합니다. 실제로 핑에 응답하는 프로세스 / 시스템은 무엇입니까? 이 프로세스가 중단 된 것 같습니다.

network-interface ping icmp

— 이조
소스

핑에 응답하지 않는 동안 여전히 ssh 할 수 있습니까? 아니면 기존 SSH 세션이 잠깁니까?

— Peter Cordes

@PeterCordes 전체 시스템이 잠기고 다시 부팅 할 때까지 기본적으로 브릭입니다.

— Izzo

일반적으로 머신이 핑에 응답하지 않는 유일한 방법입니다. 핑 처리가 중지되었지만 다른 작업은 계속 작동하면 이상 할 것입니다. 사용자 공간이 호스로 연결되어 있고 디스크 I / O의 모든 디스크가 죽은 디스크 나 NFS 마운트 등으로 차단 된 경우에도 핑 처리가 작동하기 때문입니다. 모니터를 시스템에 연결하고 잠길 때 콘솔 메시지가 있는지 확인하십시오. (매직 SysRQ 키보드 시퀀스를 사용하여 정보를 덤프하거나 읽기 전용을 다시 마운트 할 경우 디스크를 강제 동기화하고 재부팅하십시오.

— Peter Cordes

질문이 흥미롭지 만 핑은 시스템 문제의 원인이 아니라 불안정한 시스템의 결과입니다. 문제를 이해하려면 로그를 확인하십시오.

— Pedro Lobito

@PedroLobito 구체적으로 기록하는 것은 무엇입니까?

— Izzo

답변:

커널 네트워크 스택은 ping명령에 의해 전송 된 ICMP 메시지를 처리하고 있습니다.

네트워크 문제 나 필터링 외에도 호스트 기반 필터링 / 속도 제한 / 블랙홀 링 등의 응답을받지 못한 경우. 이는 시스템에 일시적으로 과부하가 걸리거나 커널이 충돌하여 드물지만 발생할 수있는 (하드웨어 결함 등) ICMP 트래픽으로 인해 시스템에 과부하가 걸렸을 수 있음을 의미합니다. 서버 수명이 시작될 때 서버가 어떻게 지속되는지 확인하는 좋은 테스트가 될 수 있습니다). 나중에 커널 충돌이 발생하면 로그 파일이나 콘솔에 충분한 정보가 있어야합니다.

또한 ping서비스가 온라인인지 아닌지를 확인하는 것은 항상 잘못된 도구입니다. 여러 가지 이유가 있지만 정의상 실제 애플리케이션 트래픽을 모방하지 않기 때문입니다. 예를 들어 웹 서버가 여전히 활성 상태인지 확인해야하는 경우 대신 HTTP 서버 (TCP 포트 80 또는 443)를 수행해야합니다. 메일 서버를 확인해야하는 경우 SMTP 쿼리 (TCP 포트 25)를 수행해야합니다. 포트 53에 대한 DNS 서버, UDP 및 TCP 쿼리 등

— 패트릭 메 체크
소스

@ 다른 응용 프로그램 서비스 테스트가 실패하거나 시간이 초과되어 관찰 된 최종 결과는 동일합니다. 나는 ping이것이 문제 해결에 너무 많은 오탐을 만들어 내기 때문에 사용에 대해 강의 할 기회를 결코 놓치지 않는다. 그래서 사용자는 핑이 무엇을하는지, 그것이 오도 된 결과를 줄 수있는 방법을 정확히 알지 못한다고 생각합니다.

— Patrick Mevzek

대부분의 과부하 상황에서 여전히 응답하는 것은 커널이 수행하는 것입니다. 즉, 시스템은 과부하 상태에 관계없이 일반적으로 핑에 응답합니다. 닫힌 포트에 도달하면 TCP의 경우 RST로 응답하고 UDP의 경우 ICMP 오류로 응답합니다. 그리고 열린 TCP 포트에 도달하려는 처음 몇 번의 시도는 핸드 셰이크를 완료합니다. 디스크 오류는 거의 동일한 증상을 유발할 수 있습니다.

— kasperd

@kasperd ICMP 요청에 응답하지 않는 (매우) 과부하 된 서버 (특히 스왑 서버)를 보았습니다. 물론 다른 것도 없습니다. 커널은 충돌하지 않았으며 디스크 I / O 관련 작업으로 바빴습니다.

— Patrick Mevzek

@Nacht Yup. 네트워크 인터페이스는 하드웨어 장치입니다. 따라서 인터페이스 할 커널 드라이버가 있습니다. 그런 다음 두 번째 계층은 일반 관리 / 통신 API를 제공합니다. (이것은 네트워킹에 고유하지 않습니다 : 오디오 개발자를위한 ALSA가 있고, 비디오 출력이 KMS API를 사용하고, USB에 {U, E, X} HCI가 있고 usb_storage, usbhid 등이 있습니다.) 네트워크 라우팅 테이블, 방화벽 규칙 (iptables를 통한) ), 핸드 쉐이킹, 패킷 어셈블리, 재전송 등은 모두 커널 내에 있습니다. ICMP는 페이로드가없고 "응답 또는하지 않음"이상의 처리가없는 자체 프로토콜이므로 커널은 최소한의 오버 헤드를 위해 ICMP 응답을 직접 처리합니다.

— FeRD

@Nacht : 그것은 근본적인 컴퓨터 아키텍처에 관한 것이 아닙니다. 구현 선택입니다. 마이크로 커널은 OS 프로세스에서 ICMP를 처리합니다.

— MSalters

핑에 응답하는 사용자 프로세스는 없습니다. Ping은 ICMP 에코 패킷을 보내는 유틸리티입니다. 이것들은 커널의 네트워킹 스택에 의해 수신되고 처리됩니다

— 외곽
소스

커널 자체 (없는 사용자 프로세스)는 전송을 담당하는 ICMP 에코 회신 에 대한 응답 메시지를 ICMP 에코 요청 메시지. 따라서 호스트가 핑에 응답하지 않으면 대개 다음과 같은 이유 때문입니다.

Ping중인 호스트와 호스트 간의 네트워크 연결이 끊어졌을 수 있습니다. 케이블 자체의 물리적 손상, 무선의 경우 소음, 라우팅 테이블 고장, DDoS 공격을 받고있는 사용자, 문제가있는 라우터 / 스위치 등 여러 가지 이유 때문일 수 있습니다.이 경우 문제 해결을 시작하게됩니다. 사용하여 ethtool(8), iwconfig(8), route(8), ping(8)그 라우터, tcpdump(8)대상 호스트 등.
대상 호스트 (또는 사용자와 대상 호스트 사이의 라우터 / 방화벽)의 방화벽 설정으로 인해 핑 (또는 트래픽 트래픽)이 제한 될 수 있습니다. fail2ban(8)방화벽은 주문형 방화벽 과 같은 도구로 인한 것일 수도 있습니다 . 확인 iptables(8)을 참조 하십시오.
대상 호스트에서 소프트웨어 / 하드웨어 오작동이 발생했습니다. 대상 호스트의 네트워크 커널 모듈이 OOPS되거나 혼동되거나 전체 커널이 PANICk되었을 수 있습니다. dmesg(8)대상 호스트에서 또는 물리적 콘솔에서 화면 출력으로 메시지가 표시됩니다 (물리적 액세스가 실용적이지 않은 경우 직렬 콘솔이 있는 다른 시스템이 도움이 될 수 있습니다.) 커널 OOPS / PANIC가 문제인 경우 더 나은 드라이버가있는 최신 커널 도움말 또는 watchdog(8)도우미 드라이버가 있는 시스템 잠금 문제를 해결할 수 있습니다. 또는 하드웨어 부품을 변경할 수 있습니다.

— 마티 야 날리스
소스

관심 들어, 여기에 관련 커널 코드의 ICMP 에코 요청을 처리합니다.

— Ruslan

또한 매우 높은 부하 (특히 CPU)를 언급해야합니다

— Guilherme Bernal

@GuilhermeBernal 아니오, 심지어 엄청나게 높은 CPU 사용자로드 (천 단위)도 ICMP 손실로 이어지지 않습니다 (사용자 프로세스가 실행되기 전에 커널에서 제공되기 때문에). 저가형 하드웨어와 결합하여 네트워크 PPS 속도가 매우 높으면 패킷 손실이 발생할 수 있지만 이러한 DDoS는 "네트워크 연결"범주에 속합니다.

— Matija Nalis