TTL | 当 TCP 连接被重置 (RST)，如何判断 RST 报文是否来自 server

lient 1.1.1.1 — network — server 2.2.2.2, 当 client 收到 ip.src == 2.2.2.2 的 TCP RST，是否证明是 server 主动发起了 RST ?

有可能，但 TCP RST 不是 100% 来自 server。

中间的 network 暂时是黑盒子，可能有 :

• 用户侧上网行为管理
• 运营商防火墙
• 服务端的 WAF 等

以上任何一个设备，都可能会代理/冒用 server 来回复 TCP RST。

TTL 的作用

数据包的 TTL（Time To Live，生存时间）主要作用 :

1. 限制数据包在网络中的传播范围 : TTL 字段指定了 IP 数据包在网络中可以经过的最大路由器跳数。当数据包从源头发送出时，其 TTL 值被设置为一个初始值。每当数据包通过一个路由器时，路由器会将 TTL 值减 1。如果 TTL 值减到 0，则该数据包会被丢弃，从而避免了数据包在网络中的无限循环。
2. 防止网络中的环路问题：在没有 TTL 的情况下，如果网络配置错误或出现路由循环，数据包可能会在网络中不断循环，这不仅会导致网络拥塞，还会降低网络资源的利用效率和网络性能。TTL 的存在有效地防止了这种情况的发生。
3. 帮助诊断网络问题：当发现数据包因为 TTL 过期而被丢弃时，这通常意味着数据包在网络中循环了太多次。这可以作为检测网络中存在问题的一个指标，如路由错误或网络配置问题。
4. 节省网络资源：通过限制数据包在网络中的存活时间，TTL 有助于减少不必要的数据包重传和处理，从而节省网络资源。
5. 提供发送方关于数据包路径的信息：虽然不是直接的功能，但 TTL 的变化可以让发送方通过接收到的 ICMP 响应（如超时消息）了解数据包在网络中的流向和遇到的问题。

不同设备的初始 TTL 值

一般情况下，不同 OS 的设备的初始 TTL 值，通常 :

• Windows, 128 or 255
• Unix/Linux, 64 or 255
• Security, 128

实际应用

以 client 访问 AWS NLB 为例，客户反馈的问题如下 :

1. client 直接访问 NLB IP 161.2.3.4，可以正常访问托管的业务
2. client 通过 DNS 访问 NLB，比如 http://ec2-161-2-3-4.cn-northwest-1.compute.amazonaws.com.cn:8080/abc/console-ui/public/img/favicon.ico，访问失败，并且从 client 抓包可以看到来自 NLB 161.2.3.4 的 TCP RST

数据包交互过程 :

luke:packets-capture$ tshark -r abc-client-TTL.pcapng -Y “frame.number”... -T fileds -e ip.ttl...

可以在公众号后台回复 ttl 来查看完整 tshark 过滤条件

3701    10.1.2.3       161.2.3.4 128     57300 → 8080 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
3717    161.2.3.4 10.1.2.3       235     8080 → 57300 [SYN, ACK] Seq=0 Ack=1 Win=62727 Len=0 MSS=1380 SACK_PERM=1 WS=128
3718    10.1.2.3       161.2.3.4 128     57300 → 8080 [ACK] Seq=1 Ack=1 Win=131072 Len=0
3739    10.1.2.3       161.2.3.4 128     GET /abc/console-ui/public/css/console1412.css HTTP/1.1
4681    161.2.3.4 10.1.2.3       235     HTTP/1.1 200   (application/javascript)
4684    10.1.2.3       161.2.3.4 128     GET /abc/console-ui/public/js/diff_match_patch.js HTTP/1.1
4910    161.2.3.4 10.1.2.3       235     HTTP/1.1 200   (application/javascript)
9641    10.1.2.3       161.2.3.4 128     GET /abc/console-ui/public/img/favicon.ico HTTP/1.1
9652    161.2.3.4 10.1.2.3       235     HTTP/1.1 200   (image/x-icon)
12163   161.2.3.4 10.1.2.3       124     HTTP/1.0 302 Moved Temporarily  (text/html)
12164   161.2.3.4 10.1.2.3       124     8080 → 57300 [RST, ACK] Seq=3606189 Ack=7375 Win=1052672 Len=0
12192   10.1.2.3       161.2.3.4 128     57300 → 8080 [FIN, ACK] Seq=43548 Ack=3606510 Win=1051136 Len=0

首先从 NLB 的功能来说，提供 Layer4 透传，并不会去解析 Layer7/HTTP，所以数据包当中看到了 HTTP/1.0 302 Moved Temporarily，初步怀疑这个报文不是 NLB 产生的。

之后对比第四列 TTL 数值，可以发现 :

1. client 初始 TTL 128
2. server 初始 TTL 255，到达 client 有 255- 235 = 20 hops 路由设备
3. frame.number 12163 的 ip.src == 161.2.3.4，期望 TTL = 235. 但是这个数据包 TTL 显示 124
4. 证明 frame.number 12163 的 302 重定向，以及 frame.number 12164 的 TCP RST，都来自距离 client 大概 4 hops 的设备

之后就可以在 client trace 161.2.3.4，找到了第四跳设备是客户自己的上网行为管理，伪造了 TCP RST 报文。

再后来，据说是上网行为管理忘记添加一条 rule，影响了 client 直接通过 DNS 访问服务 :

> match dns amazonaws.com.cn permit