openwrt 第1页 - 独孤影的博客

用软路由有一段时间的，最近家人经常跟我吐槽，家里网络差。后来我发现确实存在网络差的问题，有时候刷抖音视频加载不出来，刷微博图片加载不出来。一开始以为是天威宽带运营商的问题，后面发现同一时间直接链接运营商的光猫路由无线网络不会有问题。这么说来，问题是出在软路由上了。一开始我以为富强网的问题，因为访问国外没问题，访问国内有问题，各种找解决方案，有人说需要设置这条防火墙规则就可以了

iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

但是，我测试了没有效果。而且还比较符合别人的描述，重启防火墙就恢复正常了，然后在不确定长度的一段时间后，又会出现这个问题。这里肯定是防火墙的问题了。但是想尽一切办法都没法解决，于是我关闭了富强网。

第二天，我发现访问csdn的资源链接依然会有问题，通常会卡个1分钟以上，才有响应。这很不正常。看样子跟富强网没关系。我先后确认了DNS解析正常，关闭了“Turbo ACC网络加速”，设置调小了lan口MTU，但是都没有结果。头发都要薅光了。

先dig一下域名

➜  ttt dig csdnimg.cn

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> csdnimg.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63181
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;csdnimg.cn.                    IN      A

;; ANSWER SECTION:
csdnimg.cn.             57      IN      CNAME   csdnimg.cn.trpcdn.net.
csdnimg.cn.trpcdn.net.  1717    IN      CNAME   uz95.v.trpcdn.net.
uz95.v.trpcdn.net.      95      IN      A       116.77.73.215
uz95.v.trpcdn.net.      95      IN      A       116.77.73.214
uz95.v.trpcdn.net.      95      IN      A       116.77.73.211
uz95.v.trpcdn.net.      95      IN      A       116.77.73.213
uz95.v.trpcdn.net.      95      IN      A       116.77.73.218
uz95.v.trpcdn.net.      95      IN      A       116.77.73.217
uz95.v.trpcdn.net.      95      IN      A       116.77.73.212

;; Query time: 20 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: 一 9月 05 13:45:27 CST 2022
;; MSG SIZE  rcvd: 217

解析出来的是cname到网宿CDN，A记录为天威宽带的节点。从openwrt的ptty终端访问正常，说明ip是通的没问题，但是在路由下我的电脑上访问，也是偶现超时卡顿。

然后想办法稳定重现，写个shell脚本，用curl循环访问问题链接

#!/bin/bash

for ((i=1;i<=100;i++)); do
  curl --no-tcp-nodelay 'https://csdnimg.cn/release/blogv2/dist/pc/img/pay-time-out.png'$i -w "@fmt" -o /dev/null -s;
done

其中fmt耗时输出格式文件

time_namelookup:  %{time_namelookup}\n
       time_connect:  %{time_connect}\n
    time_appconnect:  %{time_appconnect}\n
      time_redirect:  %{time_redirect}\n
   time_pretransfer:  %{time_pretransfer}\n
 time_starttransfer:  %{time_starttransfer}\n
                    ----------\n
         time_total:  %{time_total}\n

调用shell文件，结果中间卡了很久

vjgy55fs

可以看到中间有个异常耗时

time_namelookup:  0.031654
       time_connect:  129.203610
    time_appconnect:  129.222947
      time_redirect:  0.000000
   time_pretransfer:  129.223397
 time_starttransfer:  129.359648
                    ----------
         time_total:  129.359827

可以看到，dns解析耗时0.031654，没问题，问题主要在time_connect，说明是到该ip的链接超时。众所周知，tcp连接需要握手，其中会传输ACK,SYN这些数据包，用于确认握手状态。会不会是这些包存在被路由器防火墙丢弃的情况？打开openwrt“状态->防火墙”，搜索DROP，有这么一条规则被我看到了

75ura4is

查了一下223.252.199.10，是网易云的，这让我突然想起来，openwrt上有个“解锁网易云灰色歌曲”的功能，曾经被我打开了。

91tw7d76

关闭。网络恢复正常了

最终结论：这次网络故障是由“解锁网易云灰色歌曲”这个功能导致的故障，其原理是劫持所有到网易云的流量到腾讯云，从而实现网易云音乐被封禁的音乐从腾讯云下载。中间的规则应该是出了什么问题，影响到正常链路了。关闭之后就正常了，openwrt上各种功能的确丰富，但是坑也多，很多功能都需要基于防火墙实现流量劫持与转发，一旦出现问题，就可能影响正常上网。