用爱快路由器碰到的一个网络问题

发表于 更新于

环境

我厂大内网都是通过 wireguard 联通的，具体可以参见文章：用 wireguard 在两个网络之间打洞 能了解以前的“洞”是怎么打的，还可以参见文章：Linux 下 wireguard 出问题的解决 了解 wireguard 打洞曾经踩过的坑。

我厂办公室的上网环境大致如下图所示（IP 地址啥的都做了相应替换处理）：

我厂办公网上网环境示意图

  • 10.0.0.0/24 段是我厂办公室私网
    • 10.0.0.1 为缺省网关，是一个爱快路由器，主机名也叫 ikuai
    • 10.0.0.254 是 Server 这台机器的私网地址
    • ikuai 上有设置静态路由，将 10.0.1.0/24 的下一跳指向了 Server(10.0.0.254)
  • 10.0.1.0/24 段是套路云 VPC 的私网地址
    • 缺省网关是 10.0.1.254
    • 10.0.1.1 是套路云的一台云主机，有公网地址，机器名是 EC2（貌似 ECS 更合适）
    • 路由表里将 10.0.0.0/24 的下一跳指向了 EC2 这个云主机了
  • Server 通过 wireguard 协议跟 EC2 链接，打通了 10.0.0.0/24 和 10.0.1.0/24 两个网段
  • ikuai 上把 wireguard 所用的 udp 端口流量转发给了 Server
  • EC2 上 wireguard 认的对端地址是 ikuai 的公网地址和那个转发的 udp 端口

问题表现

从 10.0.0.0/24 段的机器，比如 PC，去 ssh 10.0.1.0/24 段的服务器的时候，一般会很慢，而且很大概率会出错：

kex_exchange_identification: read: Connection reset by peer

在 PC 上和 Server 上听包，结果发现：

  • 三次握手的前几个包都正常
  • 但是 PC 回给 EC2 的最后一个 ack 包被 ikuai “吃”掉了
    • PC 上听包发现这个包的确是发给了 ikuai（目标 mac 是 ikuai 的）
    • Server 又没有及时收到，正常 ikuai 应该把这个包转发到 Server 上的
      • 最后好一点的结果就是几次重传之后，Server 收到了这个包，发给了 EC2，链接建立了，只是从表现上来看比较慢
      • 坏的结果就直接是：Connection reset by peer。服务器直接断开链接了

结论

由于 ikuai 是个黑核，我无从得知里面发上了什么，而且也曾联系了 ikuai 的客服，甚至还通过关系联系了 ikuai 的技术人员，回答也是：“不知道”，那没办法，这个锅目前来看只能是 ikuai 来背了。

解决方案

其实问题并没有完全搞明白，更谈不上解决。我只能说是“绕过”了问题，办法是通过在需要连接 10.0.1.0/24 段的机器（这里如 PC） 本地添加路由，将 10.0.1.0/24 的下一跳强制指到 Server(10.0.0.254) 。这样做以后，问题没再发生，算是“绕过”问题了。

其实还有个方法：就是在 PC 上打开 accept_redircts，这样 PC 会接受 ikuai 发过来的 “icmp redirect” 消息，将 Server 设置为新的路由网关（效果其实等于我们直接手工添加）。但这个不太安全，所以一般都不建议打开。

其他

对这个问题有经验的大佬，请不吝赐教。如需进一步的测试检测，请务必通知我配合。谢谢！