没事干千万别手贱去改(๐•ᴗ•๐)U，可能会导致奇奇怪怪的问题

铅笔

因为爱快拨号的时候(๐•ᴗ•๐)U最大设置只能1492，我也设置的1492（爱快默认1480，最大1492，一般光(๐•ᴗ•๐)都是1500），
于是手贱把UNRAID那里的(๐•ᴗ•๐)U从默认的1500也改成了1492
改的原因是以前不知道从哪看到说所有的(๐•ᴗ•๐)U最好保持一致，
结果就出了大问题，就是家里无法访问任何UNRAID虚拟机的WEBUI（虚拟机正常运行，就是WEBUI打不开，都能PING通!!!都能PING通!!!都能PING通!!!都能PING通!!!都能PING通!!!都能PING通!!!）

然后出问题那时候我又刚好给PC换了硬盘重装了系统，大概那时候手贱改的(๐•ᴗ•๐)U，我还给忘了，一直觉得问题出的诡异，为什么我PC重装系统，NAS出问题了？？？？？
前前后后折腾了我一个多(๐•ᴗ•๐)，
每天都在各种查为什么会这样
直到昨天一位折腾unraid的大佬被我问烦了叫我让他远程
他上来看见我改过的都给改回默认了（实际上我都忘记我改过(๐•ᴗ•๐)U）
以及打开了一些东西，关闭了一些（反正我是看不懂），然后就好了，都能访问了
然后我一看，(๐•ᴗ•๐)U咋是1500了，我得改回1492和爱快一致啊
一改，好的，又特么不能访问了，于是问题锁定，就是动了默认(๐•ᴗ•๐)U数值的锅

论坛里有位(๐•ᴗ•๐)以前加了我微信的，这几天他也在折腾UNRAID，就我和一起扯淡
他好像也是改成了1492，他是的问题是UNRAID里面的WIN10虚拟机，无法访问UNRAID里的任何docker，虚拟机的WEBUI，但是他的PC访问UNRAID的虚拟机又都是正常的,也是都能ping通
后来我和他说，我改回1500就好了，他就改回去试了试，居然也正常了

整体起因如下，还画了拓扑图，保种我接线是没问题的，也没环(๐•ᴗ•๐)
是我的PC无法访问UNRAID的虚拟机WEBUI（虚拟机都在运行的好好的，就是无法访问）
前前后后折腾了好久，重装爱快，试着把虚拟网桥分配给爱快作为LAN
昨天甚至把UNRAID整个系统都重装了，就是无法访问

以下这样接，是因为UNRAID有1个2.5G网口，PC也有2.5G网口，这样可以达到PC和NAS的2.5G直连，又能上网
结果是无法访问任何虚拟机WEBUI，包括爱快的
现在盲猜是因为访问所有的虚拟机都要通过unraid
和其他虚拟机是通过虚拟网桥链接，忘记画了

如果把PC直接连交换机，那么可以访问爱快，但是仍然无法访问其他虚拟机
盲猜是因为访问爱快是直接通过交换机访问爱快直通的网口，而其他虚拟机访问仍然要通过UNRAID的原因
和其他虚拟机是通过虚拟网桥链接，忘记画了

userfifun

不正确的设置设置 (๐•ᴗ•๐)U 可能会导致 P(๐•ᴗ•๐)U 黑洞,家用(๐•ᴗ•๐)由器默认是对 IPv4 下的 TCP 开启了 MSS (maximum segment size) Clamping 的,有时候一些光(๐•ᴗ•๐)、(๐•ᴗ•๐)由对 IPv6 的优化差，不支持对 IPv6 下的 TCP 包进行 MSS Clamping 就会导致某些网站打不开，表现为网站能解析出地址提示 302 代码并且能 ping 通但是打不开。

iKuai 不知道是否支持 clamp to p(๐•ᴗ•๐)u，支持的话在防火墙设置分别给 ipv4，ipv6 加两条 mangle 规则，只需要修改(๐•ᴗ•๐)由的就行了，本地网络上的其他设备都保持默认的 1500 就行。
如果不支持自动 MSS Clamping，可以手动更改 (๐•ᴗ•๐)U ，具体可以参照此处，依据自己网络环境调整。

贴一下 Router OS 下启用 MSS Clamping 的命令

/ip firewall mangle
add action=change-mss chain=forward comment="defconf: fix IPv4 mss for WAN" new-mss=clamp-to-p(๐•ᴗ•๐)u passthrough=yes protocol=tcp tcp-flags=syn
                    if(window.hljsLoader && !document.currentScr(๐•ᴗ•๐).parentNode.hasAttribute('data-s9e-livepreview-onupdate')) {
                        window.hljsLoader.highlightBlocks(document.currentScr(๐•ᴗ•๐).parentNode);
                    }

/ipv6 firewall mangle
add action=change-mss chain=forward comment="defconf: fix IPv6 mss for WAN" new-mss=clamp-to-p(๐•ᴗ•๐)u passthrough=yes protocol=tcp tcp-flags=syn
                    if(window.hljsLoader && !document.currentScr(๐•ᴗ•๐).parentNode.hasAttribute('data-s9e-livepreview-onupdate')) {
                        window.hljsLoader.highlightBlocks(document.currentScr(๐•ᴗ•๐).parentNode);
                    }

铅笔

userfifun 谢谢大佬
不过爱快压根就没有SSH可以敲代码，
我也已经准备老老实实啥都不折腾他了

777

玩软件的时间越长，就越能理解一句话：只要能用就别动

游走网络间

玩软(๐•ᴗ•๐)由，NAS，讲究的就是一个折腾，不然不会成长的😂

xuanqing

u1s1，不改完了发现奇奇怪怪的问题，你是不会知道这东西不能乱动啊。当年我把8139网卡里能调都调了，怼着楼里的主交换和上一级(๐•ᴗ•๐)由抓包，不折腾是不会知道哪些能整哪些不能动的

baiiylu

关于 P(๐•ᴗ•๐)U 黑洞

(๐•ᴗ•๐)U (Maximum transmission unit) 是一条链(๐•ᴗ•๐)上可以通过的三层数据包的最大尺寸（包含 IP 包头）。以太网上默认的 (๐•ᴗ•๐)U 是 1500 字节，但是你和目标服务器之间的(๐•ᴗ•๐)径上可能存在小于 (๐•ᴗ•๐)U 1500 的链(๐•ᴗ•๐)。这条(๐•ᴗ•๐)径上最小的 (๐•ᴗ•๐)U 值就是整条(๐•ᴗ•๐)径的 P(๐•ᴗ•๐)U 值。(๐•ᴗ•๐)由器在转发包时，超过 (๐•ᴗ•๐)U 大小的包会被分片（ Fragmentation ），也就是一个大包会被分切为多个不超过 (๐•ᴗ•๐)U 的小包进行传输，传输效率会下降。

终端设备在发包时，也可以设置 DF （ Don't Fragment ）标记来告诉(๐•ᴗ•๐)由器不要分片。这时中间(๐•ᴗ•๐)由器会丢掉超过 (๐•ᴗ•๐)U 的包，回复一条 ICMP Fragmentation Needed 消息。发送者收到这个包后，下次就会发小一点的包，这个过程叫做 P(๐•ᴗ•๐)U Discovery 。现实中可以看到 HTTPS （ (๐•ᴗ•๐)S ）的流量大都是带 DF 标记的。

然而，互联网上有大量的中间设备为了所谓的“安全”或者没有正确配置，不回应 ICMP Fragmentation Needed 包，这使得访问某些网站时如果某个包的大小超过了 P(๐•ᴗ•๐)U，会被无声地丢弃，直到 TCP 协议发现超时丢包进行重传，这非常缓慢。遇到这种情况，我们可以说你和目标服务器的(๐•ᴗ•๐)径上存在 P(๐•ᴗ•๐)U 黑洞。

此外，IPv6 不支持分片，换句话说可以理解为 IPv6 下所有的包都是带 DF 标记的。中间(๐•ᴗ•๐)由器在遇到包尺寸大于 (๐•ᴗ•๐)U 的情况时，应该回应 ICMPv6 Packet Too Big 消息。同样的，由于种种原因，某些中间设备可能会直接丢包而不回应 ICMPv6 Packet Too Big 消息，直到 TCP 协议发现超时丢包进行重传。。。
为什么 IPv4 没有这个问题

其实 IPv4 也有这个问题，我不只一次见网友说自己搭的软(๐•ᴗ•๐)由访问某些网站非常慢，而换回硬(๐•ᴗ•๐)由就正常。这是因为多数家用(๐•ᴗ•๐)由器默认对 IPv4 下的 TCP 开启了 MSS (maximum segment size) Clamping （使用 OpenWRT 软(๐•ᴗ•๐)由的(๐•ᴗ•๐)们可以在防火墙设置中找到 MSS Clamping 开关）。MSS Clamping 是针对 P(๐•ᴗ•๐)U 黑洞的 Workaround，简单来说就是 TCP 握手时有个 MSS 字段决定单个 TCP 包的最大尺寸。(๐•ᴗ•๐)由器可以通过嗅探 TCP 握手包，把 MSS 值改小，使最终的三层 IP 包的尺寸（ MSS+TCP 头大小+IP 头大小）不超过某个特定的值。

转自：https://v2ex.com/t/800024

小飞

是的，我qb就是这么炸的

CwPlace

我突出一个不折腾