在 WSL2 上针对 Windows 中运行的服务运行围攻

在 WSL2 上针对 Windows 中运行的服务运行围攻

我在 Windows 的 localhost:8080 上有一个运行的 Spring 应用程序。

现在我想对它运行“siege”。我知道如何翻译主机名,以便我可以从 WSL 访问它,例如

ping NUKY.local

按预期工作:

aui@NUKY:~$ ping NUKY.local
PING NUKY (172.30.80.1) 56(84) bytes of data.
64 bytes from NUKY (172.30.80.1): icmp_seq=1 ttl=128 time=0.321 ms
64 bytes from NUKY (172.30.80.1): icmp_seq=2 ttl=128 time=0.728 ms

使用以下命令运行 siege 会产生错误:

aui@NUKY:~$ siege -c 1 -r 1 http://NUKY.local:8080/products/123
** SIEGE 4.0.4
** Preparing 1 concurrent users for battle.
The server is now under siege...[error] A non-recoverable resolution error for NUKY.local
: Resource temporarily unavailable

在 Windows shell 中我可以执行:

> curl http://localhost:8080/products/123
{"productId":"123","title":"Some random title"}

在 WSL shell 中我可以执行:

> curl http://NUKY.local:8080/products/123
{"productId":"123","title":"Some random title"}

我如何让 Siege 解决 Windows 服务并对其进行压力测试?

答案1

对于之前错误的回答,我深表歉意——我对此做出了错误的假设。我现在已经siege在 WSL 上的 Ubuntu 上进行了测试,并且可以自己重现此行为。

看起来可能是名称解析问题,但我尚未深入研究源头以确认。但siege肯定没有解析 mDNS 名称$(hostname).local(就您的情况而言NUKY.local)。

我可以使用此表单(通用版本)来完成这项工作:

siege -c 1 -r 1 http://$(dig -p 5353 $(hostname).local +short):8080/products/123

解释:

  • 使用 获取 mDNS 名称$(hostname).local。当然,您可以跳过此部分,只需像在示例中那样对 Windows 主机名进行硬编码(例如NUKY.local)。
  • 用于dig查找该主机名的 mDNS(端口 5353)IP

当然,如果查找过程中出现问题dig,您可以随时将 IP 本身硬编码到 URL 中siege。这对我来说也行得通。只是在siege尝试解析.local表单本身时,问题似乎才显现出来。

此外,由于 WSL2 与 Windows 主机位于“单独的网络”上,因此我仍然必须在 Windows 中为此创建防火墙规则,否则它将无法正常工作。对于内置的 Windows Defender,我使用类似的东西(来自 PowerShell):

New-NetFirewallRule -DisplayName "Spring App Testing" -InterfaceAlias "vEthernet (WSL)" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow 

因为您的curl命令是从 WSL 运行的,所以我假设这已经为您准备好了,或者您首先有一个更宽松的防火墙策略。

这条规则有点具体,也许“过于严格”(有些人称之为“最佳实践”),所以你可能需要稍微放宽一点。这条规则两个都

  • 将端口限制为 TCP 8080
  • 将网络接口限制为 WSL NIC

您可能希望删除其中一个,以便:

  • 8080 可从本地网络上的任何设备访问(甚至可以从另一个网络转发)
  • 或者接受来自 WSL vNIC 的所有连接。

当然,“最佳实践”也是在完成规则后删除该规则,使用:

Remove-NetFirewallRule -DisplayName "Spring App Testing"

警告——当然,我还没有用 Spring 应用程序测试过这个问题。但我假设根本原因是相同的,因为即使使用在 Windows 端用 Python 创建的简单 HTTP 服务器,我也可以重现您所看到的情况。希望这不是我的另一个错误假设 ;-)。

相关内容