路由器做了何种限制会导致ping可以正常工作，但是traceroute不能

 这种情况一般是路由器针对 **Traceroute 所用的报文类型** 做了限制，而对 Ping 所用的 ICMP Echo 请求/应答没做限制。常见原因有：

1. **丢弃或禁止返回 ICMP Time Exceeded 报文**

   * Traceroute 的核心机制是逐步增加 TTL，让中间路由器返回 *ICMP Time Exceeded*，从而推测路径。

   * 如果路由器防火墙/ACL 丢弃了这些 ICMP Time Exceeded（或相关 UDP/TCP 不可达报文），路径就显示不到。

   * 这种情况下，Ping 仍可正常，因为 Ping 用的是 ICMP Echo Request/Reply，不依赖 TTL 超时报文。

2. **阻止 Traceroute 初始探测数据包**

   * 传统 UNIX/Linux `traceroute` 用 UDP 高端口（>33434）探测，中间路由器必须允许这些 UDP 报文通过。

   * 如果路由器丢弃了这些高端口 UDP（或 TCP traceroute 的探测 SYN 包），Traceroute 就卡住。

   * Windows `tracert` 则直接发 ICMP Echo 请求，依赖 Time Exceeded，所以同样会受限。

3. **限速或限量 ICMP 响应**

   * 有些运营商设备对 ICMP 超时返回做限速（rate limiting），低 TTL 的包得不到响应，就看起来像 traceroute 被阻断。

   * 但直接 Ping 目标（TTL 正常）时，响应率正常。

4. **NAT 或防火墙只放行会话相关流量**

   * 某些出口 NAT/防火墙只允许已建立连接的返回包，而 traceroute 的每跳包在 NAT 表中没有匹配项，导致 ICMP 超时无法返回。

   * Ping 是一对一会话，更容易被允许。

如何阻止traceroute的UDP

如果其他 UDP 都能正常通信，但就是 traceroute 的 UDP 不行，那基本可以肯定是路由器/防火墙在 **针对 traceroute 的典型 UDP 探测特征做精确匹配阻断**。

Traceroute 的 UDP 探测流量有几个很显著的特征，容易被“精准拦截”而不影响其他 UDP 应用：

---

### 1. **端口特征过滤**

* **传统 UNIX/Linux traceroute** 默认发送到目标 **UDP 端口 33434 起**，并且每跳端口号递增。

* 如果路由器/防火墙直接在 ACL 或规则中写：

  ```

  deny udp any any range 33434 33534

  ```

  或等效匹配规则，就能阻止 traceroute，但不会影响常见应用（因为很少应用用到这些高端口）。

* 有些运营商就是用这种方式来“屏蔽”路由探测。

---

### 2. **TTL 阈值检测**

* Traceroute 依赖 **小 TTL**（从 1 开始递增）触发中间路由器返回 `ICMP Time Exceeded`。

* 防火墙可以检测到 **UDP 包的 TTL 非常小**（比如 ≤2 或 ≤5），并阻止这种包进入或离开网络。

* 这样正常 UDP 应用（TTL 通常是 64/128/255）不受影响。

---

### 3. **组合匹配：小 TTL + 高端口**

* 更精确的做法是匹配：

  * 目的端口在 33434–33534

  * TTL < 10

* 这样几乎只会命中 traceroute 的探测包，而不会误杀其他流量。

---

### 4. **阻断返回的 ICMP “端口不可达”**

* UDP traceroute 在探测到目标主机最后一跳时，需要收到目标返回的 `ICMP Port Unreachable`。

* 如果路由器丢弃这种 ICMP 类型 3/代码 3（UDP 端口不可达），那么 traceroute 即使包发出去也得不到最终一跳信息，看起来就像卡住。

* 对普通 UDP 会话没影响，因为它们不依赖这种 ICMP 报文。