☰

192.168.0.146에서 icmp_seq=1 대상 호스트에 연결할 수 없습니다.

tag-icon • tag-icon ubuntu networking ping cisco
192.168.0.146에서 icmp_seq=1 대상 호스트에 연결할 수 없습니다. 
root@prateek-desktop:~# ping 192.168.0.1 
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.146 icmp_seq=1 Destination Host Unreachable
From 192.168.0.146 icmp_seq=2 Destination Host Unreachable
From 192.168.0.146 icmp_seq=3 Destination Host Unreachable

root@prateek-desktop:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1

ping이 불가능한 이유는 무엇입니까?

방화벽이 비활성화되었습니다...

192.168.0.1은 DHCP 지원 무선 라우터의 IP 주소입니다. 라우터의 이더넷 포트에는 DHCP가 할당한 IP 주소가 있습니다. 내 컴퓨터의 IP 주소는 192.168.0.146입니다. 라우터와 PC는 동일한 네트워크를 가지고 있습니다. 내 컴퓨터에는 네트워크 설정에서 192.168.0.146으로 지정된 기본 게이트웨이가 있습니다. 내 다른 장치는 내 컴퓨터에 ping을 수행할 수 있지만 내 컴퓨터는 내 컴퓨터가 직접 연결된 라우터를 포함하여 다른 장치에 ping을 수행할 수 없습니다.

답변1

[편집] 내 다른 장치는 내 컴퓨터를 핑할 수 있지만 내 컴퓨터는 내 컴퓨터가 직접 연결된 라우터를 포함하여 다른 장치를 핑할 수 없습니다.

다른 장치에 충돌하는 IP 주소가 있는지 확인하겠습니다.

(귀하의 결과가 이것과 일치하는지 확실하지 않지만 pingARP에 대한 내 직관과 잘 맞지 않으며 불행히도 Google 검색 결과에서 유사한 조합을 찾지 못했습니다. 다른 질문이나 다른 문제가 있을 수 있습니다. 하지만 확인해 보는 것이 좋습니다. 단서를 찾는 데 도움이 될 수 있습니다.

PC에서 MAC 주소("하드웨어 주소")를 찾습니다. 실행 중인 경우 ip link show dev eth1MAC 주소는 나중에 표시되는 값입니다 link/ether.

다른 장치 중 하나에서 IP에 대해 캐시된 MAC 주소(192.168.0.146)를 다시 확인하세요. 다른 장치에서 Linux를 실행 중인 경우 를 사용하여 ARP 캐시를 확인할 수 있습니다 ip -4 neigh. 다른 장치에서 Windows를 실행 중인 경우 다음을 사용할 수 있습니다 arp -a(Windows 명령줄). IP 192.168.0.146에 대해 다른 MAC 주소가 표시되면 실제로는 PC가 아닌 다른 장치에 핑을 보내는 것입니다 :-).

이전 버전:

ping이 불가능한 이유는 무엇입니까?

AfroJoe: 이유는 많습니다

기술적으로 말하면 ping"대상 호스트에 연결할 수 없습니다"라고 말하는 것은 매우 구체적인 오류 메시지입니다! 귀하의 출력은 거의 확실하게 ARP 확인이 실패했음을 의미합니다. 존재하다 192.168.0.146. 이 컴퓨터는 귀하가 실행 중인 것과 동일한 컴퓨터인 것으로 보이며 ping이후 편집에서 이를 확인하셨습니다. 이 경우 ARP 문제를 확인하는 방법은 다음과 같습니다.

$ ping 172.16.8.2
PING 172.16.8.2 (172.16.8.2) 56(84) bytes of data.
From 172.16.8.205 icmp_seq=1 Destination Host Unreachable
From 172.16.8.205 icmp_seq=2 Destination Host Unreachable
From 172.16.8.205 icmp_seq=3 Destination Host Unreachable
^C
--- 172.16.8.2 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms
pipe 4

$ ip -4 neigh
172.16.8.1 dev wlp2s0 lladdr 74:44:01:86:42:d6 REACHABLE
172.16.8.2 dev wlp2s0  INCOMPLETE

성공적인 ARP 해결에는 다음 교환이 포함됩니다.

$ sudo tcpdump -n -i wlp2s0 arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
...
13:43:49.469349 ARP, Request who-has 172.16.8.1 tell 172.16.8.205, length 28
13:43:49.470046 ARP, Reply 172.16.8.1 is-at 74:44:01:86:42:d6, length 28
13:43:49.852608 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 21, length 64
13:43:49.854600 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 21, length 64
13:43:50.853879 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 22, length 64
13:43:50.855867 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 22, length 64
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel

(ping을 실행하고 강제 ARP 플러시를 사용할 때 관찰됨 ip neigh flush dev wlp2s0).

참고: 이 설명은 기본적으로 ping"정상" TCP/IP 응용 프로그램에서 ssh"호스트 연결 불가" 메시지를 전체 ICMP 응답이 수신되고 디코딩됩니다. 따라서 이 오류는 명시적으로 "관리적으로 금지"된 오류라고 알려줍니다.curlpingping오직"호스트에 연결할 수 없습니다."

또한 이번 Q&A는 IPv4에 관한 것입니다. IPv6에 어떻게 적응하는지 확인하지 않았습니다.

ARP 확인이 실패하는 이유는 무엇입니까?

AfroJoe: 이유는 많습니다

나에겐 또 다른 비밀 지식이 있다. Ubuntu 클라이언트 시스템이 누군가 의도적으로 구성하지 않은 한 주소는 192.168.0.146DHCP 패킷 교환을 통해 할당됩니다. 일반적으로 이 교환에는 라우터가 포함되지만 다른 경우에는 Windows Server 또는 다른 유형의 서버만 포함될 수 있습니다. 이 경우 라우터는 DHCP 서버 또는 릴레이이고 시스템은 이미 전환할 수 있습니다.일부라우터가 있는 패킷.

연결을 끊었다가 다시 설정하여 DHCP 교환 다시 트리거를 테스트할 수 있습니다. [*] 물론, 문제가 "무작위로" 계속 반복되는 경우 이렇게 해도 근본적인 문제가 해결되지는 않으며 연결이 여전히 끊어져 있는지 조사할 수 있습니다.

([*] Apple은 DHCP 교환을 수행하는 최적화를 작성했습니다.뒤쪽에특정 ARP 패킷 교환. 어쩌면 이것에 대한 새로운 단점이 있을 수도 있지만 Linux에서는 사용되는 것을 본 적이 없습니다. )

이 오류는 특정 지점에서 무선 신호가 끊어졌을 때 DHCP 및 WiFi 연결을 사용할 때 자주 나타납니다. (그리고 무선 계층이 완전히 포기하기 전에 이를 포착할 수 있습니다... 왜 이런 일이 그렇게 자주 발생하는지 잘 모르겠습니다. 아마도 버그가 있거나 잘못 작성된 시스템을 보고 있는 것일 수도 있습니다.) 그러나 eth1은 WiFi 연결이 아닙니다.

저는 IPv4용 DHCP가 ARP 없이 작동한다고 생각합니다. 적어도 초기 DHCP 교환에서는 그렇습니다.

남은 가능성

귀하의 질문에 대한 원래 버전의 사실을 토대로 볼 때 특히 일반적인 개별 사례를 생각하기가 어렵습니다. (내 암묵적인 가정도 포함합니다. 도움 없이는 누구도 이 질문을 하지 않을 것입니다.노력하다컴퓨터를 작동 중인 라우터에 연결합니다.

  • 연결된 네트워크에 주소가 있는 장치가 없습니다 192.168.0.1. 이것이 DHCP 주소를 제공한 것이라면 네트워크에서 제거된 것입니다. 플러그를 뽑거나 그냥 죽으세요.
  • eth1을 수동으로 구성했으며 다음 중 하나를 구성했습니다.
    • Ubuntu 데스크탑에서 NetworkManager를 사용하고 있지 않으며
      • 실제로 이더넷 링크를 감지하지 못했습니다(확인 ethtool).
      • 또는 이더넷 링크를 감지했지만 스위치에서 비밀번호를 제공하거나 다른 인증을 사용하도록 요구합니다.802.1X.
      • 또는 이더넷 링크가 감지되었지만 네트워크 관리자에게 컴퓨터의 MAC 주소를 등록해야 합니다.
    • 케이블의 성능은 링크를 감지할 만큼 좋지만 패킷을 안정적으로 전송하기에는 충분하지 않습니다.

답변2

150억 가지 이유 중 하나가 있을 수 있습니다. 그 중 일부는 다음과 같습니다.

  • 데스크탑의 네트워크 구성 문제. (올바른 게이트웨이를 설정하셨나요?)
  • 대상 시스템 방화벽이 핑에 응답하지 않도록 구성되었습니다.
  • 네트워크에 연결하는 케이블이 손상되었습니다
  • 시스템에 다른 호스트의 ICMP 응답을 차단하는 방화벽 규칙이 있습니다.
  • 네트워크 전체 방화벽 구성은 ICMP를 필터링합니다(스위치 구성 포함).

문제는오직제공된 정보로는 추가 진단을 할 수 있는 방법이 전혀 없으므로 이 질문이 "너무 광범위"합니다(그렇게 표시됨).

관련 정보