TCP/IP-ICMP-Ping-Traceroute

TCP/IP-ICMP

作者：Danbo 2015-8-22

I C M P经常被认为是I P层的一个组成部分。它传递差错报文以及其他需要注意的信息。I C M P报文通常被I P层或更高层协议（ T C P或U D P）使用。一些I C M P报文把差错报文返回给用户进程。I C M P报文是在I P数据报内部被传输的。类型字段可以有1 5个不同的值，以描述特定类型的I C M P报文。某些I C M P报文还使用代码字段的值来进一步描述不同的条件。检验和字段覆盖整个I C M P报文。

ICMP报文

常见的类型和代码：
0 0 回显应答
3 3 端口不可达
8 0 请求回显
11 0 TTL超时（Traceroute会用到）
全部如下图所示：

注意：端口不可达只能针对UDP，如果是TCP的话就会回应TCP的RST包清理掉该连接请求。
不过基于安全和稳定方面的考虑，在开发应用程序的时候都会忽略ICMP不可达信息，但是会提供足够的信息让程序意识到这个问题的存在。

当发送一份I C M P差错报文时，报文始终包含I P的首部和产生I C M P差错报文的I P数据报的前8个字节。这样，接收I C M P差错报文的模块就会把它与某个特定的协议（根据I P数据报首部中的协议字段来判断）和用户进程（根据包含在I P数据报前8个字节中的T C P或U D P报文首部中的T C P或U D P端口号来判断）联系起来。

下面各种情况都不会导致产生I C M P差错报文：
1) ICMP差错报文（但是，I C M P查询报文可能会产生I C M P差错报文）。
2) 目的地址是广播地址或多播地址的I P数据报。
3) 作为链路层广播的数据报。
4) 不是I P分片的第一片。(只有第一片才有端口号信息)
5) 源地址不是单个主机的数据报。这就是说，源地址不能为零地址、环回地址、广播地址或多播地址。
这些规则是为了防止过去允许I C M P差错报文对广播分组响应所带来的广播风暴。

UDP端口不可达中返回ICMP报文的实例

PING

我们称发送回显请求的p i n g程序为客户，而称被p i n g的主机为服务器。

几年前我们还可以作出这样没有限定的断言，如果不能P i n g到某台主机，那么就不能Te l n e t或F T P到那台主机。随着I n t e r n e t安全意识的增强，出现了提供访问控制清单的路由器和防火墙（比如禁用了ping），那么像这样没有限定的断言就不再成立了。一台主机的可达性可能不只取决于I P层是否可达，还取决于使用何种协议以及端口号。

Ping的路径记录 选项：-R
p i n g程序为我们提供了查看I P记录路由（ R R）选项的机会。大多数不同版本的p i n g程第7章Ping程序使用65 下载序都提供-R选项，以提供记录路由的功能。它使得p i n g程序在发送出去的I P数据报中设置I PR R选项（该I P数据报包含I C M P回显请求报文）。这样，每个处理该数据报的路由器都把它的I P地址放入选项字段中。当数据报到达目的端时， I P地址清单应该复制到I C M P回显应答中，这样返回途中所经过的路由器地址也被加入清单中。当p i n g程序收到回显应答时，它就打印出这份I P地址清单。源端主机生成RR选项，中间路由器对RR选项的处理，以及把ICMP回显请求中的RR清单复制到ICMP回显应答中。即来去都要记录。

IP首部中的首部长度字段只有4 bit，因此整个I P首部最长只能包括1 5个32 bit长的字（即6 0个字节）。由于I P首部固定长度为2 0字节， R R选项用去3个字节（下面我们再讨论），这样只剩下3 7个字节（ 6 0-2 0-3）来存放I P地址清单，也就是说只能存放9个I P地址。

IP记录路由选项结构：

Ping的IP记录会把出接口IP放入到清单中，最后一条会把入接口放入到清单中。后面讲的Traceroute记录的是入接口IP。

通过下面我们可以对比一下Ping和Traceroute记录IP的区别。

R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
  1 12.1.1.2 40 msec 24 msec 32 msec
  2 23.1.1.3 40 msec 40 msec 40 msec

R1#ping ip
Target IP address: 3.3.3.3
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: R         
Number of hops [ 9 ]: 9
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet has IP options:  Total option bytes= 39, padded length=40
 Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)

Reply to request 0 (68 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (12.1.1.1)
   (23.1.1.2)
   (3.3.3.3)
   (23.1.1.3)
   (12.1.1.2)
   (12.1.1.1) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Traceroute

Tr a c e r o u t e程序可以让我们看到I P数据报从一台主机传到另一台主机所经过的路由。

Traceroute操作的过程：
它发送一份T T L字段为1的I P数据报给目的主机。处理这份数据报的第一个路由器将T T L值减1，丢弃该数据报，并发回一份超时I C M P报文。这样就得到了该路径中的第一个路由器的地址。然后Tr a c e r o u t e程序发送一份T T L值为2的数据报，这样我们就可以得到第二个路由器的地址。继续这个过程直至该数据报到达目的主机。但是目的主机哪怕接收到T T L值为1的I P数据报，也不会丢弃该数据报并产生一份超时I C M P报文，这是因为数据报已经到达其最终目的地。那么我们该如何判断是否已经到达目的主机了呢？
Tr a c e r o u t e程序发送一份U D P数据报给目的主机，但它选择一个不可能的值作为U D P端口号（大于30 000），使目的主机的任何一个应用程序都不可能使用该端口。因为，当该数据报到达时，将使目的主机的U D P模块产生一份“端口不可达”错误的I C M P报文。这样，Tr a c e r o u t e程序所要做的就是区分接收到的I C M P报文是超时还是端口不可达，以判断什么时候结束。

下图是Traceroute的一个抓包过程实例：

我们发现源端口（49175）也很大。Traceroute程序将其发送的UDP数据报的源端口设置为Unix进程号与32768之间的逻辑或值。对于在同一台主机上多次运行Traceroute程序的情况，每个进程都查看ICMP返回的UDP首部的源端口号，并且只处理那些对自己发送应答的报文。1）、我们并不能保证现在的路由也是将来的所要采用的路由，甚至两份连续的IP数据报都可能采用不同的路由。
2）、不能保证ICMP报文的路由与Traceroute程序发送的UDP数据报采用同一路由。这表明打印出来的往返的时间可能并不能真正体现数据报发出和返回的时间差（如UDP数据报从源到路由器的时间是1s，而ICMP报文用另一条路由返回信源用了3s时间，则打印出来的往返时间是4s）
3）、返回的ICMP报文中的源IP是UDP数据报达到的路由器接口的IP地址。这与IP记录路由选项不同，IP记录的记录的是发送接口的IP地址。

源站路由所指的每一个IP地址是如接口IP。分为严格和宽松，严格则必须每一条都是直连的；而宽松则没必要，只要经过的路由IP是在记录内即可。

一个Traceroute应用的实例：
有时候我们ping不通，此时有可能是ping包没有到达目的地，也有可能ping包无法返回。此时我们就用到Traceroute，目的IP写自己的IP地址，宽松源站路由写目的IP：Traceroute过去到了目的，然后再Traceroute回来。只要中间任何地方出现了不通就会报错，然后就知道问题出现在哪儿了。

默认情况下XP是不转发数据包的，交换机也是不转发包的。

ICMP重定向

当I P数据报应该被发送到另一个路由器时，收到数据报的路由器就要发送I C M P重定向差错报文给I P数据报的发送端。只有当主机可以选择路由器发送分组的情况下，我们才可能看到I C M P重定向报文。
1) 我们假定主机发送一份I P数据报给R 1。这种选路决策经常发生，因为R 1是该主机的默认路由。
2) R1收到数据报并且检查它的路由表，发现R 2是发送该数据报的下一站。当它把数据报发送给R 2时，R 1检测到它正在发送的接口与数据报到达接口是相同的（即主机和两个路由器所在的L A N）。这样就给路由器发送重定向报文给原始发送端提供了线索。
3) R1 发送一份I C M P重定向报文给主机，告诉它以后把数据报发送给R 2而不是R 1。

我们做一下实验：

此时我们在Host上配置默认网关：default gataway 123.1.1.2，然后关闭Host的F0/0接口的路由功能：no ip routing。R2与R3运行OSPF，然后我们在Host上Traceroute 3.3.3.3发生了重定向：
R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
  1 123.1.1.3 28 msec 20 msec 16 msec

然后启动Host上的路由功能，配置指向R2的默认路由 ip route 0.0.0.0 0.0.0.0 123.1.1.2，此时我们抓包发现Host还是能收到R2发送的重定向消息，不过Host并不会理睬这个消息，因为自己有路由功能。
R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
  1 123.1.1.2 40 msec 12 msec 8 msec
  2 123.1.1.3 16 msec 20 msec 20 msec

在生成I C M P重定向报文之前这些条件都要满足。
1) 出接口必须等于入接口。
2) 用于向外传送数据报的路由不能被I C M P重定向报文创建或修改过，而且不能是路由器的默认路由。
3) 数据报不能用源站选路来转发。
4) 内核必须配置成可以发送重定向报文。

主机在收到ICMP重定向消息后要做以下检查：
1) 新的路由器必须直接与网络相连接。
2) 重定向报文必须来自当前到目的地所选择的路由器。
3) 重定向报文不能让主机本身作为路由器。
4) 被修改的路由必须是一个间接路由。