服务器 Gind.cn
  1. 服务器 Gind.cn
  3. PacketLoss通过互联网“Linux-Linux”，但不是“Windows-Linux”（tl; dr：它是MTU）
Intereting Posts
如何看看什么PHP脚本运行顶部或ps aux rsyslog – 模板 – 正则expression式数据插入到数据库 使用SuSEfirewall2或iptables规则redirect本地请求，而不是内部请求 主题文件的Nginx位置别名 是同时使用Nginx和Varnish redudant吗？ Cloudflare如何知道我的子域名？ 蝙蝠文件在另一个帐户 无法将静态路由添加到Linux Nginx的“默认”服务器？ 从raid-1硬件控制器读取磁盘 ASA 5505阻止用户 如果DNS超时导致永久电子邮件失败？ KVM是types1还是types2pipe理程序？ 虚拟化：在Integrity（ia64）服务器（使用x86_64 guest虚拟机）上运行KVM，XEN或… 在重新启动时保留多宿主设置

PacketLoss通过互联网“Linux-Linux”，但不是“Windows-Linux”（tl; dr：它是MTU）

我现在正在争取在互联网上的机器之间造成数据包丢失的现象。

检查下图。 请注意，每当我使用“SSH”，我可以使用“HTTPS”; 该协议发生相同的现象。

运行Fedora 22的SSH服务器位于“站点A”（酒红色）。 直到“最近”才有连接问题。

从运行Fedora 22或Fedora 23的Amazon EC2计算机到“站点A”的SSH连接工作良好（在“Amazon EC2”框中显示为绿色的主机）

从同一AS上的“站点B”到“站点A”的SSH连接不能在我testing的任何Fedora系统上运行（橙色框）。 但是，他们使用Putty从Windows 7系统上工作。 两种情况都涉及相同的（双引导）硬件。 “站点B”也有一个防火墙，但似乎没有任何作用：我试图直接从FritzBox路由器build立连接，它仍然不适用于Fedora，但为Windows工作。

问题如何performance出来：

使用SSH进行连接时，会有一个初始数据包交换（如tcpdump所示）。 然而，在20个数据包左右之后，传出的数据包似乎已经不在任何地方了， 没有确认从站点A回来。您永远不会到达密码提示。 一个CTRL-C正确地重置连接，之后Linux仍然尝试发送一些从未被确认过的数据包。

设置

我怀疑在我的ISP有一些问题，特别是我怀疑ISP执行可疑的魔术，以便实施站点B的“固定IP地址”，这是唯一改变“最近”的东西。

然而，我不明白什么可以说明一个SSH连接在Windows上工作，而不是在相同的条件下，在networking上工作。 我该找什么？

  • 这里（Amazon S3）是失败的SSH连接的tcpdump

您的数据包追踪显示： 

 22:29:22.180852 IP (tos 0x0, ttl 64, id 52989, offset 0, flags [DF], proto TCP (6), length 1900) SITE_B_LAN_ADDR.54358 > SITE_A.SSH_PORT: Flags [P.], cksum 0x05c4 (incorrect -> 0xadce), seq 22:1870, ack 22, win 229, options [nop,nop,TS val 4294917498 ecr 71539420], length 1848

请注意它的一个1900个字节的长度，在数据包上设置了一个不可分割的选项。 典型的MTU往往在1400-1500字节之间。

您可能会收到数据包太大的ICMP消息，但您丢弃站点上的所有ICMPstream量入站防火墙。

为了testing这个，你必须在防火墙上为icmp和tcp 22做数据包跟踪。

确保在站点A允许ICMP数据包太大的入站消息

或者，您可以尝试在站点A的Linux机器上将MTU设置为低于networkingMTU大小的值。 我冒着猜测，在Fedora上，你有巨大的数据包启用，但在Windows上，你不这样做。

在亲爱的评论者的build议之后，我想看看MTU问题是否可能是原因。

尝试从Fedora系统的“站点A”连接到“站点B”时发现以下情况。 在Windows系统上，一切工作正常 – wireshark表明传出数据包的长度永远不会超过1158字节，所以问题不会在那里触发。

  • 这里（Amazon S3）是带有分段问题的带注释的tcpdump

简而言之，如果我正确地阅读这个：

  1. 有一个最初的成功的小包交换。
  2. 发送长度为1900的数据包。 我想网卡会打破这个，因为本地networking的MTU是1500。
  3. ISPnetworking中地址为10.10.80.7的路由器告诉我们“请将数据包分段到MTU 1492”。
  4. Wilco的！ 一个长度为1492的数据包被发送。
  5. ISPnetworking中地址为10.10.80.7的路由器告诉我们“请将数据包分段到MTU 1492”。
  6. 事情从这里走下坡路。

它看起来像我将不得不打开一个门票与ISP（这是邮政电信卢森堡顺便说一句，万一有人Google类似的问题）。

这也意味着一个补救措施。 强制MTU到SITE_A到1000： 

 ip route add $SITE_A_IP via $GATEWAY_IP dev $ETHDEV mtu lock 1000

事实上，这解决了这个问题。

参考信息

使用pingtestingMTU行为： 

 ping -c $COUNT -M $MTUDS -s $PPLSZ $HOST

哪里

  • COUNT=1 ： “仅限一次”
  • MTUDS=do ：MTU发现策略是“禁止分片，甚至是本地分片”，即设置'DF'（ MTUDS=do片）位（为什么这个'do​​'？dunno）。 用这个。
  • MTUDS=want ：MTU发现策略是“做PMTU发现，当分组大小很大时本地分片”，即设置'DF'位和分片在本地
  • MTUDS=dont ：MTU发现策略是“不要设置''DF'位，即根据需要片段
  • PPLSZ=1464 ：ICMP ping数据包有效负载大小（以字节为单位）。

使用tcpdump来监视来自“站点A”的所有ICMP数据包和数据包： 

 tcpdump -vvv -n -nn icmp or '(' host $SITE_A_IP ')'

虽然这有点难读。

观察内核对MTU“站点A”的看法。 

 watch ip route get to $SITE_A_IP

请注意，比默认值低的MTU将在第一次失败的ping之后以600秒的TTL进行caching。

脚本

假设以字节为单位的最大IP包大小（即以太网有效载荷的大小）是1492（这是在Amazon EC2上的情况），那么有趣的ping有效载荷大小将是1465，因为用于IP和ICMP首部的28字节信息会给1493，最多一个字节。

然后， ping -c 1 -M want -s 1465 $HOST_IP执行以下操作：

在第一次ping你得到“碎片需要和DF设置（mtu = 1492）100％的数据包丢失”。 tcpdump显示echo request part 1（length 1493）out，目标networking的路由器发送一个“ICMP unreachable”，请求将其分解为MTU 1492.MUU = 1492的高速caching条目出现在内核路由caching中。

在后续的ping中，你会得到“1个数据包发送，1个收到”。 tcpdump显示回声请求部分1（长度1492）和回声请求部分2（长度21，偏移1472）和相应的回声回复（长度1493）。

或者你可以使用traceroute 

 # traceroute --mtu SITE_A 1500

数据包大小1500. Traceroute告诉我们，10.10.80.7路由有MTU 1492 

 traceroute to SITE_A (SITE_A_IP), 30 hops max, 1500 byte packets 1 gateway (192.168.10.1) 0.550 ms 0.536 ms 0.393 ms 2 192.168.178.1 (192.168.178.1) 1.458 ms 1.485 ms 1.344 ms 3 10.10.80.7 (10.10.80.7) 4.889 ms F=1492 2.968 ms 4.854 ms 4 10.10.80.7 (10.10.80.7) 4.955 ms !F-1492 3.559 ms !F-1492 5.022 ms !F-1492

尝试1492：同样的问题！ 

 traceroute to SITE_A (SITE_A_IP), 30 hops max, 1492 byte packets 1 gateway (192.168.10.1) 0.635 ms 0.554 ms 0.483 ms 2 192.168.178.1 (192.168.178.1) 1.510 ms 1.504 ms 1.311 ms 3 10.10.80.7 (10.10.80.7) 48.305 ms 17.436 ms 5.496 ms 4 10.10.80.7 (10.10.80.7) 5.963 ms !F-1492 6.865 ms !F-1492 4.887 ms !F-1492

试试1491：同样的问题！ 

 traceroute to SITE_A (SITE_A_IP), 30 hops max, 1491 byte packets 1 gateway (192.168.10.1) 0.594 ms 0.650 ms 0.492 ms 2 192.168.178.1 (192.168.178.1) 1.716 ms 1.782 ms 1.580 ms 3 10.10.80.7 (10.10.80.7) 7.327 ms 7.385 ms 4.775 ms 4 10.10.80.7 (10.10.80.7) 5.210 ms !F-1492 5.624 ms !F-1492 4.841 ms !F-1492

尝试1490：我们通过。 那里肯定会有一些错误的错误。 

 traceroute to SITE_A (SITE_A_IP), 30 hops max, 1490 byte packets 1 gateway (192.168.10.1) 0.616 ms 0.688 ms 0.484 ms 2 192.168.178.1 (192.168.178.1) 1.712 ms 1.853 ms 1.611 ms 3 10.10.80.7 (10.10.80.7) 6.248 ms 7.008 ms 4.995 ms 4 SITE_A_IP.dyn.luxdsl.pt.lu (SITE_A_IP) 12.441 ms !X 9.641 ms !X 9.576 ms !X

感兴趣的其他信息：

  • 如何分辨正在使用什么MTU
  • 如何查看caching的PMTU