启用 Windows 防火墙后 LAN 上的 SSH 客户端连接延迟

启用 Windows 防火墙后 LAN 上的 SSH 客户端连接延迟

当我将开发计算机升级到 Win11(之前运行的是 Win10)后,问题就出现了。

  • 我的本地服务器正在运行 Ubuntu 22.04。
  • Win11 ssh 客户端:putty、WSL2 ssh,在连接局域网上的服务器时均会经历 20 秒的延迟。
  • 但是,相同的客户端连接到 WAN 服务器时没有任何延迟。
  • 密码或密钥文件连接的延迟是相同的。
  • 来自两个不同设备的两个不同的 Android 客户端连接到同一个服务器/端口,没有任何问题或延迟。

到目前为止我已经尝试过:

  • SSH 端口号无关紧要,22 或任何其他端口上都存在同样的问题。
  • 在服务器/win11 客户端上启用/禁用 VPN 没有效果,延迟相同,而 Android 可以在服务器/客户端上或不使用 VPN 的情况下很好地连接 VPN。

最初,我怀疑是服务器配置问题,尝试了所有常见的解决方案,将 UseDNS 设置为否,总而言之,这里列出的所有解决方案都无济于事 -https://jrs-s.net/2017/07/01/slow-ssh-logins/

  • 在 Windows 防火墙中为 Putty 添加一条新的防火墙规则,但没有帮助,因为连接没有被阻止,只是延迟。

  • 另外,为了测试并找出有问题的规则,我简单地禁用了所有活动的防火墙规则,没有任何变化,同样是 20 秒的延迟。禁用防火墙确实可以解决问题。

  • 尝试使用 GPE(组策略编辑器)编辑组策略。我不确定为什么当 Windows 设置中的防火墙设置显示大量规则时,本地计算机策略/计算机配置/Windows 设置/安全设置/Windows Defender 防火墙/WDF 本地组下的入站规则为空,但无论如何,在其中添加 Putty 的入站/出站规则也无法解决问题。

  • 绕过网络交换机,一些帖子提到 quos 是一个潜在问题,直接将两个计算机连接到路由器,结果相同。

  • 创建 Win10 VM 并从管理终端使用 ssh,延迟相同。

至此,我已经没有什么可以研究的想法了。

如果我只是禁用 Windows Defender 防火墙,问题就会消失。这实际上不是一个选择。

服务器和客户端均未记录任何错误。发生延迟时的日志输出:在客户端,延迟之前的最后一行:

debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5

以及服务器身份验证日志中的相应行(syslog 没有任何内容):

GatorNas sshd[1655346]: debug1: inetd sockets after dupping: 4, 4

20 秒后,一切正常,我收到密码提示,建立连接,速度正常等等。

我真的很困惑,为什么 LAN 连接会延迟,而连接到 inet 上的服务器则是亚秒级的......

更新:

  • 在 Win11 上捕获数据包,查看 LLNMR 和 mDNS 通过 udp 5355 和 udp 5353 进行过滤。没有结果。
  • 在 Ubuntu 盒子上捕获数据包,与上面的 wireshark 过滤器相同,没有流量。

使用过滤器 (udp.port == 5355) || (udp.port == 5353)。任何关于如何过滤网络流量以缩小范围以找到有用内容的建议都会很有帮助。

找到了延迟的原因:更多的数据包捕获显示端口 113 存在端口标识问题。服务器在 113 上发送请求,然后进行 3 次 TCP 重新传输,因此造成延迟。

还是不明白:

  1. 为什么该问题只出现在 LAN 上
  2. 更重要的是,在 Windows 防火墙中为 LAN 打开端口 113 没有任何效果 :(

解决方法:拒绝 ssh 服务器端 113 端口上的所有流量。

答案1

您的 SSH 服务器已配置为向连接客户端发出 Ident 请求,以便了解客户端的操作系统用户名(大概是为了日志记录目的)。

为什么该问题只出现在 LAN 上

LAN 服务器是唯一专门配置为进行 Ident 查询的服务器。这不是默认设置(需要经过一些非常谨慎的配置才能实现这种情况),而且您的 WAN 服务器不会执行此操作。

我还没有看到任何 SSH 服务器可以自行进行 Ident 查询(OpenSSH 当然不会),但从你的日志来看,你的 sshd 似乎正在运行通过 inetd而不是像往常一样成为一项独立服务。(网管系统和 xinetd 是“超级服务器”服务,等待连接并根据需要启动实际的 sshd/ftpd/telnetd/etc 服务;这在 systemd 或 launchd 中也称为“套接字激活”。)

具体来说,服务器可能正在运行 xinetd 并在 中(或 中的某个位置)配置了一项ssh服务。如果发现该设置,请查找启用日志记录的设置 - 如果找到,请将其删除并重新启动 xinetd。它可能类似于以下内容:/etc/xinetd.conf/etc/xinetd.d/ssh*USERID

service ssh
{
    [...]
    log_on_success += HOST USERID
    log_on_failure += HOST USERID
}

更重要的是,在 Windows 防火墙中为 LAN 打开端口 113 没有任何效果 :(

它是非常如今很少有计算机运行 Ident 响应器(IRC 是唯一一个看到它被大量使用的地方),但通常到端口 113 的传入连接会立即被 TCP RST 数据包拒绝,服务器将继续运行。同样,可以设置防火墙通过明确拒绝连接来阻止连接。

但是,Windows 防火墙默认以“隐身模式”运行,忽略连接尝试连接到没有监听套接字的端口,因此服务器被迫等待约 30 秒的 TCP 连接超时。即使您明确允许连接到端口 113,这种情况也会发生,因为“隐身模式”功能适用于未使用端口上的所有请求,无论规则是否允许该流量。

因此,只要没有任何东西在监听端口 113 并且防火墙处于活动状态,该请求就会被悄悄忽略(而不是发送正确的 TCP RST 拒绝数据包)。

虽然首先阻止服务器进行 Ident 查询是一个更好的选择,但你也可以禁用“隐身”模式在 Windows 中通过注册表(它实际上可能没有声称的那么重要 - 被阻止的请求仍将继续被阻止):

  • 命令:

    for %p in (Public Private Domain Standard) do (
      reg add HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\%pProfile /v DisableStealthMode /t REG_DWORD /d 1
    )
    

相关内容