By

文章目录

今天领导布置了一个在CCTV-1上看节目的任务，我急忙在电脑上搜CCTV，结果央视的网站居然打不开了。赶快上搜一下，结果有的指向了知乎，结果发现知乎也打不开了。

ping了一下，发现打不开的网站ping到的都是ipv6的地址。

1
2
3
4
5
6
7
8
9
10
11
12
PS C:\WINDOWS\system32> ping tv.cctv.com

正在 Ping g2.ctc.cctvcdn.net.lxdns.com [240e:918:1a00:201::15] 具有 32 字节的数据:
来自 240e:918:1a00:201::15 的回复: 时间=13ms
来自 240e:918:1a00:201::15 的回复: 时间=13ms
来自 240e:918:1a00:201::15 的回复: 时间=13ms
来自 240e:918:1a00:201::15 的回复: 时间=13ms

240e:918:1a00:201::15 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 13ms，最长 = 13ms，平均 = 13ms
1
2
3
4
5
6
7
8
9
10
11
12
PS C:\WINDOWS\system32> ping www.zhihu.com

正在 Ping 1595096.sched.d0-dk.tdnsdp1.cn [240e:925:2:730::40] 具有 32 字节的数据:
来自 240e:925:2:730::40 的回复: 时间=2ms
来自 240e:925:2:730::40 的回复: 时间=2ms
来自 240e:925:2:730::40 的回复: 时间=2ms
来自 240e:925:2:730::40 的回复: 时间=2ms

240e:925:2:730::40 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 2ms，最长 = 2ms，平均 = 2ms

而能打开的网址ping到的都是ipv4地址

1
2
3
4
5
6
7
8
9
10
11
12
PS C:\WINDOWS\system32> ping www.baidu.com

正在 Ping www.a.shifen.com [180.101.49.11] 具有 32 字节的数据:
来自 180.101.49.11 的回复: 字节=32 时间=34ms TTL=52
来自 180.101.49.11 的回复: 字节=32 时间=34ms TTL=52
来自 180.101.49.11 的回复: 字节=32 时间=34ms TTL=52
来自 180.101.49.11 的回复: 字节=32 时间=34ms TTL=52

180.101.49.11 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 34ms，最长 = 34ms，平均 = 34ms

尝试根据以前的方法清除DNS缓存，通过管理员权限打开CMD

1
2
3
4
5
# 清除DNS缓存信息
ipconfig /flushdns

# 重置winsock 目录设置
netsh winsock reset

重启之后，没有解决问题

后来我在搜索时找到这篇文章使用IPv6后一些网站无法访问，有时能访问有时无法访问问题解决-次世代BUG池 (neucrack.com)

文章中说：

由于 IPv6 对 MTU 的长度和 IPv4 不同，导致使用 IPv6 时会出现某些网站偶尔无法访问，其实就是 MTU 设置太大，有时候需要分包的时候被网络中一些不支持分包的设备给丢弃了，导致网站无法访问

版权声明：本文为 neucrack 的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://neucrack.com/p/400

公司网络支持 IPv6 后就一直访问一些网站有时候无法访问或者特别慢， 经过 @vowstar 的排查解决了问题:

由于 IPv6 对 MTU 的长度和 IPv4 不同，导致使用 IPv6 时会出现某些网站偶尔无法访问，其实就是 MTU 设置太大，有时候需要分包的时候被网络中一些不支持分包并且不会相应请求设备需要分包的设备给丢弃了，导致网站无法访问。 解决方法就是将(路由器的) MTU 设置小一点（比 IPV4 小 20 字节，比如 1432 字节）

这里记录下，以下为其原话：

之前ipv6环境下简书时而可以访问时而不能访问的root cause找到了，原因是PMTU黑洞，其细节如下：
终端设备在发包时，也可以设置 DF （ Don’t Fragment ）标记来告诉路由器不要分片。这时中间路由器会丢掉超过 MTU 的包，回复一条 ICMP Fragmentation Needed 消息。发送者收到这个包后，下次就会发小一点的包，这个过程叫做 PMTU Discovery 。现实中可以看到 HTTPS （ TLS ）的流量大都是带 DF 标记的。
然而，互联网上有大量的中间设备为了所谓的“安全”或者没有正确配置，不回应 ICMP Fragmentation Needed 包，这使得访问某些网站时如果某个包的大小超过了 PMTU，会被无声地丢弃，直到 TCP 协议发现超时丢包进行重传，这非常缓慢。遇到这种情况，我们可以说你和目标服务器的路径上存在 PMTU 黑洞。
由于我们到简书之间的目标链路一直在变化，在链路节点中如果遇到了这种被错误配置的设备，就会导致我们无法访问简书。
现在国内 ISP 一般都是通过 PPPoE 虚拟拨号建立 WAN 口连接的。Ethernet 的默认 MTU 是 1500，但是 PPPoE 隧道有 8 个 bytes 的开销，所以 PPPoE 虚连接的 MTU 就是 1500-8=1492，减掉 IPv4 包头（ 20 字节）和 TCP 包头（ 20 字节），可以得知 IPv4 下需要把 MSS 设为 1452 以下。IPv6 的包头是 40 字节，所以 IPv6 下需要把 MSS 设为 1432 以下。
解决方法：

1
2
3
> > #set security flow tcp-mss all-tcp mss 1452
> > set security flow tcp-mss all-tcp mss 1432
> >

原先的设置值是1452, 改成1432后，强制丢包现象消失，原先无法访问的简书可以被访问了。

路由器后台一般都可以直接更改，电脑 linux 可以临时：

1
2
> sudo ifconfig enp7s0 mtu 1432 up
>

我的路由器是TP-LINK的TL-R473GP-AC，在后台找到基本设置 WAN设置 IPv6 将MTU 设置为1432，重启路由器，问题解决。

但是CCTV-1上的节目也结束了。-_-||

文章目录