☰

ncat 命令的“连接超时”与“没有到主机的路由”之间有什么区别？

tag-icon • tag-icon linux networking tcp arp icmp
ncat 命令的“连接超时”与“没有到主机的路由”之间有什么区别？

我尝试使用 ncat 命令从 CENTOS 7 (linux) 终端区分 2 个未知 IP。

[abc@localhost ~]$ ncat -zv 10.11.78.5 22
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: No route to host.
[abc@localhost ~]$ ncat -zv 10.11.215.243 22
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection timed out.

对于情况1，我们使用tcpdump来查看

10.11.77.147.22 > 10.11.236.41.55722: Flags [P.], cksum 0x4ef1 (incorrect -> 0xcc2c), seq 2565:2601, ack 1124, win 318, options [nop,nop,TS val 523166642 ecr 4195774342], length 36
13:57:39.271990 [SOURCE_MAC] > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.78.5 tell 10.11.77.147, length 28
13:57:39.272428 [SOURCE_MAC] > [DEST_MAC], ethertype IPv4 (0x0800), length 150: (tos 0x12,ECT(0), ttl 64, id 2262, offset 0, flags [DF], proto TCP (6), length 136)
    10.11.77.147.22 > 10.11.236.41.55722: Flags [P.], cksum 0x4f21 (incorrect -> 0x12b6), seq 2601:2685, ack 1124, win 318, options [nop,nop,TS val 523166656 ecr 4195774342], length 84
13:57:39.641351 [SRC_MAC] > [DEST_MAC], ethertype IPv4 (0x0800), length 66: (tos 0x48, ttl 58, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    10.11.236.41.55722 > 10.11.77.147.22: Flags [.], cksum 0x580f (correct), ack 2601, win 2047, options [nop,nop,TS val 4195774724 ecr 523166642], length 0
13:57:39.641351 [SRC_MAC] > [DEST_MAC], ethertype IPv4 (0x0800), length 66: (tos 0x48, ttl 58, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    10.11.236.41.55722 > 10.11.77.147.22: Flags [.], cksum 0x57ae (correct), ack 2685, win 2046, options [nop,nop,TS val 4195774724 ecr 523166656], length 0
13:57:40.272221 [SOURCE_MAC] > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.78.5 tell 10.11.77.147, length 28

在情况 2 中，我们使用 tcpdump 然后我看到：

15:27:20.847566 SRC_MAC > DEST_MAC, ethertype IPv4 (0x0800), length 102: (tos 0x4a,ECT(0), ttl 58, id 0, offset 0, flags [DF], proto TCP (6), length 88)
    10.11.236.41.56347 > 10.11.77.147.22: Flags [P.], cksum 0x3679 (correct), seq 3046:3082, ack 2950, win 2048, options [nop,nop,TS val 3721004625 ecr 528532842], length 36
15:27:20.860097 DEST_MAC > SRC_MAC, ethertype IPv4 (0x0800), length 102: (tos 0x12,ECT(0), ttl 64, id 35536, offset 0, flags [DF], proto TCP (6), length 88)
    10.11.77.147.22 > 10.11.236.41.56347: Flags [P.], cksum 0x0cb5 (correct), seq 2950:2986, ack 3082, win 318, options [nop,nop,TS val 528548224 ecr 3721004625], length 36
15:27:20.860124 DEST_MAC > SRC_MAC, ethertype IPv4 (0x0800), length 150: (tos 0x12,ECT(0), ttl 64, id 35537, offset 0, flags [DF], proto TCP (6), length 136)
    10.11.77.147.22 > 10.11.236.41.56347: Flags [P.], cksum 0xfd88 (correct), seq 2986:3070, ack 3082, win 318, options [nop,nop,TS val 528548231 ecr 3721004625], length 84
15:27:20.865395 DEST_MAC > SRC_MAC, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 15451, offset 0, flags [DF], proto TCP (6), length 60)
    10.11.77.147.58106 > 10.11.215.243.22: Flags [S], cksum 0xcab1 (correct), seq 2395880917, win 29200, options [mss 1460,sackOK,TS val 528548238 ecr 0,nop,wscale 7], length 0
15:27:21.178240 SRC_MAC > DEST_MAC, ethertype IPv4 (0x0800), length 66: (tos 0x48, ttl 58, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    10.11.236.41.56347 > 10.11.77.147.22: Flags [.], cksum 0x990d (correct), ack 2986, win 2047, options [nop,nop,TS val 3721004956 ecr 528548224], length 0
15:27:21.178240 SRC_MAC > DEST_MAC, ethertype IPv4 (0x0800), length 66: (tos 0x48, ttl 58, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    10.11.236.41.56347 > 10.11.77.147.22: Flags [.], cksum 0x98b3 (correct), ack 3070, win 2046, options [nop,nop,TS val 3721004956 ecr 528548231], length 0
15:27:21.867037 DEST_MAC > SRC_MAC, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 15452, offset 0, flags [DF], proto TCP (6), length 60)
    10.11.77.147.58106 > 10.11.215.243.22: Flags [S], cksum 0xc6c7 (correct), seq 2395880917, win 29200, options [mss 1460,sackOK,TS val 528549240 ecr 0,nop,wscale 7], length 0
15:27:23.870566 DEST_MAC > SRC_MAC, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 15453, offset 0, flags [DF], proto TCP (6), length 60)
    10.11.77.147.58106 > 10.11.215.243.22: Flags [S], cksum 0x3aa9 (incorrect -> 0xbef3), seq 2395880917, win 29200, options [mss 1460,sackOK,TS val 528551244 ecr 0,nop,wscale 7], length 0
15:27:23.996114 SRC_MAC > DEST_MAC, ethertype IPv4 (0x0800), length 102: (tos 0xc0, ttl 58, id 50466, offset 0, flags [none], proto ICMP (1), length 88)
    10.11.26.4 > 10.11.77.147: ICMP host 10.11.215.243 unreachable, length 68
    (tos 0x0, ttl 57, id 15451, offset 0, flags [DF], proto TCP (6), length 60)
    10.11.77.147.58106 > 10.11.215.243.22: Flags [S], cksum 0xcaf6 (correct), seq 2395880917, win 29200, options [mss 1391,sackOK,TS val 528548238 ecr 0,nop,wscale 7], length 0
15:27:23.996114 SRC_MAC > DEST_MAC, ethertype IPv4 (0x0800), length 102: (tos 0xc0, ttl 58, id 50467, offset 0, flags [none], proto ICMP (1), length 88)
    10.11.26.4 > 10.11.77.147: ICMP host 10.11.215.243 unreachable, length 68
    (tos 0x0, ttl 57, id 15452, offset 0, flags [DF], proto TCP (6), length 60)
    10.11.77.147.58106 > 10.11.215.243.22: Flags [S], cksum 0xc70c (correct), seq 2395880917, win 29200, options [mss 1391,sackOK,TS val 528549240 ecr 0,nop,wscale 7], length 0
15:27:26.999948 SRC_MAC > DEST_MAC, ethertype IPv4 (0x0800), length 102: (tos 0xc0, ttl 58, id 50468, offset 0, flags [none], proto ICMP (1), length 88)
    10.11.26.4 > 10.11.77.147: ICMP host 10.11.215.243 unreachable, length 68

它从 10.xx 开始，所以是私有 IP。此外，出于显而易见的原因，我还对 mac 地址进行了清理。

  1. 两个 IP 似乎都无法访问，但我们的输出有差异？
  2. 在一种情况下我们收到 ICMP 数据包，而在另一种情况下却没有？
  3. “连接超时”v/s“没有到主机的路由”
  4. 还需要寻找什么真正的原因吗？

本地主机：10.11.77.147

答案1

第一个中，有针对 10.11.78.5 的 ARP 请求，但没有相应的回复。如果系统不知道第 2 层地址，则无法将数据包发送到该目的地。请注意，没有 TCP SYN 数据包发往 10.11.78.5，只是没有到达那么远。 ARP 条目是一种主机路由，因此至少有可能出现“没有到主机的路由”错误的情况。 （我没有检查任何官方来源，但它似乎确实符合我在 Linux 上得到的行为。）

13:57:39.271990 ... ARP (0x0806), ... Request who-has 10.11.78.5 tell 10.11.77.147, length 28

在第二个中，没有 ARP 请求，但发送了 TCP SYN。因此，10.11.215.243 很可能已经在系统的 ARP 缓存中。

在这里，您将收到 ICMP 错误（至少就 tcpdump 看到的而言），我会预计这会导致其他错误而不仅仅是超时。话又说回来，可能值得检查一下您是否没有使用 iptables 主动丢弃传入的 ICMP 数据包？

15:27:23.996114 ... IPv4 (0x0800), ... proto ICMP (1), length 88)
    10.11.26.4 > 10.11.77.147: ICMP host 10.11.215.243 unreachable, length 68

无论如何，往返 10.11.236.41 的 TCP 数据包似乎与您正在测试的连接无关。它们似乎连接到另一端的 10.11.77.147/tcp22，这可能是您的 shell 会话正在运行的 SSH 连接吗？您可能想要过滤掉这样的数据包以使转储更易于阅读。

相关内容