때때로 핑을 할 수 없는 지점까지 잠기는 Linux 기반 프로세스 컨트롤러가 있습니다. 즉, 핑을 할 수 있지만 네트워크 설정을 변경하지 않으면 더 이상 핑을 할 수 없습니다.
어떤 프로세스/시스템이 실제로 핑에 응답하는지 궁금합니다. 프로세스가 중단된 것 같습니다.
답변1
커널 네트워크 스택은 ping
명령으로 전송되는 ICMP 메시지를 처리하고 있습니다.
답변이 없다면 네트워크 문제나 필터링, 호스트 기반 필터링/속도 제한/블랙홀 등이 아닌 다른 문제입니다. 이는 일시적일 수 있는 어떤 이유로든 시스템이 과부하될 수 있거나 드물지만 발생할 수 있는 커널 충돌(하드웨어 오류 등)이 발생할 수 있음을 의미하며 반드시 ICMP 트래픽 때문은 아니지만(그러나 이 클래스 트래픽을 사용하려고 시도함) 오버로드)는 서버 수명 초기에 서버가 어떻게 유지하는지 확인하는 좋은 테스트가 될 수 있습니다. 커널 패닉이 발생한 후자의 경우 로그 파일이나 콘솔에 충분한 정보가 있어야 합니다.
또한 ping
서비스가 온라인인지 확인하는 도구는 거의 항상 잘못되었습니다. 여러 가지 이유가 있지만 주로 정의에 따라 실제 애플리케이션 트래픽을 시뮬레이션하지 않기 때문입니다. 예를 들어, 웹 서버가 아직 활성 상태인지 확인해야 한다면 HTTP 쿼리(TCP 포트 80 또는 443)를 수행해야 하고, 메일 서버를 확인해야 하면 SMTP 쿼리(TCP 포트 25)를 수행해야 합니다. , DNS 서버인 경우 UDP그리고포트 53 등에 대한 TCP 쿼리
답변2
핑에 응답하는 사용자 공간 프로세스는 없습니다. Ping은 ICMP 에코 패킷을 보내는 유틸리티일 뿐입니다. 이는 커널의 네트워크 스택에 의해 수신되고 처리됩니다.
답변3
커널 자체(사용자 프로세스가 아님)가 전송을 담당합니다.ICMP 에코 응답답장 메시지ICMP 에코 요청정보. 따라서 호스트가 핑에 응답하지 않는 경우 일반적으로 다음과 같은 이유 때문입니다.
귀하와 ping 대상 호스트 사이의 네트워크 연결이 끊어졌을 수 있습니다. 이는 케이블의 물리적 손상, 무선 케이스의 소음, 손상된 라우팅 테이블, DDoS 공격을 받고 있는 경우, 중간에 있는 라우터/스위치에 문제가 있는 경우 등 여러 가지 이유 때문일 수 있습니다. 이 경우 대상 호스트 ,
ethtool(8)
해당 라우터 등 을 사용하여 문제 해결을 시작할 수 있습니다.iwconfig(8)
route(8)
ping(8)
tcpdump(8)
대상 호스트(또는 사용자와 대상 호스트 사이의 라우터/방화벽)의 방화벽 설정은 핑(또는 트래픽 흐름) 수를 제한할 수 있습니다. 이는
fail2ban(8)
주문형 방화벽과 같은 도구로 인해 발생할 수도 있습니다 . 한 번 보시고iptables(8)
확인해 보세요.대상 호스트에 소프트웨어/하드웨어 오류가 있습니다. 대상 호스트의 네트워크 커널 모듈이 OOPS 상태가 되거나 패닉 상태가 될 수 있으며, 심지어 전체 커널도 패닉 상태가 될 수 있습니다. 대상 호스트의 at in에 대한 메시지가 표시되거나
dmesg(8)
물리적 콘솔의 화면 출력이 표시됩니다(물리적 액세스가 불가능할 경우 다음과 같이 다른 콘솔을 사용할 수 있습니다).직렬 콘솔도울 수있다. ) 커널 OOPS/PANIC이 문제인 경우 더 나은 드라이버가 포함된 최신 커널이 도움이 될 수 있습니다. 또는watchdog(8)
보조 드라이버를 사용하여 시스템 잠금 문제를 해결할 수 있습니다. 아니면 하드웨어 부품을 교체할 수도 있습니다.
답변4
Linux 커널이 이를 직접 처리한다는 것을 확신하는 흥미로운 방법은 커널 설정을 관찰하는 것입니다.
tail /proc/sys/net/ipv4/icmp*
출력은 다음과 유사할 수 있습니다.
==> /proc/sys/net/ipv4/icmp_echo_enable_probe <==
0
==> /proc/sys/net/ipv4/icmp_echo_ignore_all <==
0
==> /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts <==
1
==> /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr <==
0
==> /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses <==
1
==> /proc/sys/net/ipv4/icmp_msgs_burst <==
50
==> /proc/sys/net/ipv4/icmp_msgs_per_sec <==
1000
==> /proc/sys/net/ipv4/icmp_ratelimit <==
1000
==> /proc/sys/net/ipv4/icmp_ratemask <==
6168
/proc/sys
이는 커널 상태를 구성하고 확인하는 데 사용되는 특수 파일 시스템 과 마찬가지로 ICMP가 커널에 의해 처리된다는 것을 이미 보여줍니다 ./dev, /proc, /sys에는 무엇이 있나요?
다음으로, 일반적인 가정용 모뎀 라우터 뒤의 동일한 LAN에 있는 두 대의 컴퓨터를 연결하면 다음을 ping
통해 컴퓨터 A에서 컴퓨터 B로 이동할 수 있습니다.
ping 192.168.1.102
그런 다음 컴퓨터 B에서 다음 명령을 사용하여 ping 응답을 끌 수 있습니다.
echo 1 | sudo tee /proc/sys/net/ipv4/icmp_echo_ignore_all
이렇게 하면 ping
컴퓨터 A가 오작동하기 시작합니다. 다시 활성화하십시오.
echo 0 | sudo tee /proc/sys/net/ipv4/icmp_echo_ignore_all
따라서 커널과 대화하여 ICMP를 직접 제어할 수 있습니다.
icmp_echo_ignore_all
다음에 대한 참조https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/icmp.c?id=24cac7009cb1b211f1c793ecb6a462c03dc35818#n935
static bool icmp_echo(struct sk_buff *skb)
{
struct net *net;
net = dev_net(skb_dst(skb)->dev);
if (!net->ipv4.sysctl_icmp_echo_ignore_all) {
struct icmp_bxm icmp_param;
icmp_param.data.icmph = *icmp_hdr(skb);
icmp_param.data.icmph.type = ICMP_ECHOREPLY;
icmp_param.skb = skb;
icmp_param.offset = 0;
icmp_param.data_len = skb->len;
icmp_param.head_len = sizeof(struct icmphdr);
icmp_reply(&icmp_param, skb);
}
/* should there be an ICMP stat for ignored echos? */
return true;
}
테스트는 가정용 무선 LAN에 연결된 Linux 6.5.0을 실행하는 Ubuntu 23.10 컴퓨터 두 대를 사용하여 수행되었습니다.