☰

Linux(4.15.0-130)와 Windows(10)는 ICMP를 다르게 처리합니까?

tag-icon • tag-icon windows-10 traceroute icmp
Linux(4.15.0-130)와 Windows(10)는 ICMP를 다르게 처리합니까?

불규칙한 네트워크 문제가 있는 Windows 10 시스템의 문제를 해결하려고 시도하는 동안 호스트에 대한 경로 추적을 수행했으며 커널 4.15.0-130이 있는 Ubuntu 18.04 시스템에서 본 것과 다소 다른 결과를 얻었습니다. 하드웨어 요소, 불안정한 프로토콜 스택, 드라이버 문제 등을 제거하기 위해 Linux를 실행하는 VirtualBox VM의 Windows 10과 호스트 시스템이 제공하는 기능을 비교했습니다. VirtualBox는 NAT로 설정되었습니다. 즉, Windows 10은 호스트에 연결한 다음 실제 네트워크 I/O를 처리합니다. 따라서 두 세션 모두 동일한 네트워크 어댑터를 사용하고 모든 것이 호스트의 동일한 프로토콜 스택을 통과합니다. VPN이 관련되어 있지 않습니다. 클라이언트 시스템은 단순히 WiFi/3G 인터넷 라우터에 연결되어 있습니다.

내가 추적하고 있는 호스트는 Linux(Firefox 웹 브라우저 사용)에서는 연결할 수 있지만 Windows 10(Firefox를 사용하는 다른 Windows 10 컴퓨터 또는 Chrome을 사용하는 VirtualBox)에서는 연결할 수 없습니다.

Windows(Linux의 Virtual Box에서 실행)는 다음을 제공합니다.

>tracert -d www.brewforafrica.co.za

Tracing route to www.brewforafrica.co.za [41.203.18.81]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  10.0.2.2
  2     3 ms     3 ms     3 ms  192.168.0.1
  3    56 ms    23 ms    36 ms  10.113.42.52
  4    83 ms    31 ms    22 ms  10.251.60.253
  5     *        *        *     Request timed out.
  6    74 ms    34 ms    29 ms  10.251.60.233
  7    88 ms    39 ms    20 ms  10.251.60.234
  8     *      103 ms    39 ms  10.113.145.33
  9    25 ms    33 ms    24 ms  196.207.35.36
 10    82 ms    32 ms    43 ms  192.168.133.110
 11    54 ms    25 ms    42 ms  41.21.235.25
 12    69 ms    80 ms    62 ms  10.118.24.61
 13   103 ms    35 ms    35 ms  196.60.9.24
 14    46 ms    45 ms    53 ms  197.189.193.1
 15    95 ms    53 ms    35 ms  41.203.18.81

Trace complete.

(참고: 10.0.2.2는 VitualBox에서 제공하는 기본 게이트웨이 주소입니다. Linux는 여기에서 모든 네트워킹을 처리하므로 이 홉은 아래 추적 경로에 존재하지 않습니다.) Linux를 사용하여 동일한 추적 경로 반복(Virtual Box를 실행하는 동일한 시스템에서) 위의 Windows 10과의 세션)은 나에게 다음을 제공합니다.

$ traceroute -n www.brewforafrica.co.za

traceroute to www.brewforafrica.co.za (41.203.18.81), 30 hops max, 60 byte packets
 1  192.168.0.1  1.416 ms  1.580 ms  1.668 ms
 2  10.113.42.52  24.311 ms  25.119 ms  38.804 ms
 3  10.251.60.253  39.793 ms  39.875 ms  39.922 ms
 4  * * *
 5  10.251.60.233  40.122 ms  41.365 ms  51.445 ms
 6  10.251.60.234  51.910 ms  50.416 ms  50.508 ms
 7  10.113.145.33  50.836 ms  27.691 ms  27.251 ms
 8  196.207.35.36  31.254 ms  73.984 ms  63.871 ms
 9  192.168.133.110  73.479 ms  73.528 ms  62.612 ms
10  41.21.235.25  52.088 ms  61.699 ms  61.572 ms
11  10.118.24.61  62.102 ms  62.275 ms  61.833 ms
12  196.60.9.24  61.680 ms  51.679 ms  39.123 ms
13  197.189.193.1  40.032 ms  40.073 ms  43.791 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
$

이러한 차이의 원인은 무엇이며 어떤 방식으로든 중요합니까?

답변1

동일한 추적 경로가 아닙니다. Linux는 traceroute실제로 Windows처럼 ICMP Echo 대신 기본적으로 UDP 프로브를 보냅니다. sudo traceroute --icmpWindows에 더 가까운 것을 얻으려면 사용하십시오 . ( mtr있는 동안 시험해 보세요 .)

최종 시스템에 알 수 없는 포트 1 의 UDP 패킷을 조용히 삭제하는 방화벽이 있는 경우 응답이 없다는 것은 Traceroute 프로그램이 패킷이 어디로 갔는지 알 수 없으며 실제로 프로브가 최종 목적지에 도달했음을 인식할 수 없음을 의미합니다. 점점 더 큰 TTL을 계속 탐색할 필요가 없습니다.

1 모든 종류의 경로 추적 프로브에서도 동일한 일이 발생합니다 . 2 UDP를 삭제하는 것은 ICMP Echo를 삭제하는 것보다 훨씬 더 일반적입니다. (고의적인 차단일 필요도 없습니다. 일부 운영 체제는 기본적으로 UDP와 TCP를 무시하고 표준에서 ICMP 포트 도달 불가를 요구할 때 조용하게 유지합니다. 그들은 종종 이것을 "스텔스 모드"라고 부르며 보안 기능이라고 주장합니다.)

2 Traceroute에 대한 전용 패킷 유형이 없습니다. 도구는 실제 서비스를 혼동하지 않고 최종 호스트에서 응답을 생성할 가능성이 있는 모든 것을 보냅니다. 여기에는 ICMP Echo뿐만 아니라 높은 포트의 UDP 패킷, 심지어 TCP SYN도 포함됩니다.

관련 정보