嘻嘻哈哈的部落格(blog)

前面碰到的问题
其实大概原因是这样的
Linux1–>vpn1<-->vpn2–>Linux2
vpn1和vpn2之间是走公网搭的一个vpn连接
这样
当从Linux1上ssh连接到Linux2上的时候
登录正常
当某个命令需要从Linux2返回大量的数据回Linux1的时候
由于某些ip包大小大于mtu值
而且被置DF位(不允许分片)或者是ip包允许分片但是vpn1或vpn2不允许分片的ip包通过
所以导致Linux1收不到其他的大ip包
导致看起来是ssh session挂掉
其实
tcp层有路径最小mtu值发现功能
为什么没生效呢？
其实不是这样的
比如当Linux2回来的大包分成1500一片到达vpn2
vpn2上还要给其打上4个字节的GRE头(如果vpn用的GRE通道的话)
再加上外层的20字节的ip头
这一下就超过vpn1公网(vpn是通过公网连起来的)以太网口的mtu值1500!!
于是返回“MTU of next hop: 1500”的错误
这样的话Linux2还会以1500来分片发送大包
这样循环下去，Linux1永远也不会收到来自Linux2的大的ip包
ssh session自然就“挂”了

原因明白了
那么解决起来就容易了
无非是改小mtu值嘛
那改成多少合适呢
很简单
改成1500-4-20=1476就行(其实小于这个数也行，不过mtu自然是要最大的)
于是ifconfig eth0 mtu 1476
再ssh登录
dmesg
都没问题了，搞定