更新 2：pf 已默认为 drop。是什么原因导致 nmap 注意到服务器？“received reset”是什么意思？
更新 1：也许我误解了我的发现。当使用 -v2 运行时，nmap 告诉我“主机已启动，已收到重置 ttl 52”。这是否意味着即使 ICMP 被阻止，nmap 也能够注意到服务器正在运行？这是由于 BLOCK/DROP 差异造成的吗？我正在探测的服务器运行带有 pf 的 OpenBSD。pf 设置为“全部阻止”，后跟非常具体的例外情况。在我看来，这默认为 BLOCK，而不是 pf 中的 DROP。
当我跑步时
nmap -sn
探测特定主机时，nmap 返回“主机已启动”，尽管我探测的服务器的 ICMP 已被完全阻止（时间除外）。根据 nmap 文档，我假设“主机已启动”消息基于 ICMP 响应（因为这是我所知道的唯一“开放”通道）：
使用 -sn 完成的默认主机发现默认包括 ICMP 回显请求、对端口 443 的 TCP SYN、对端口 80 的 TCP ACK 和 ICMP 时间戳请求。
现在我想知道是否有可能让 nmap 告诉我主机启动的原因，例如获取探测中涉及的单个步骤的详细输出。我尝试使用 -v 运行它，但这只会提供版本和一般闲聊。´
我知道我可以自己执行单个请求（例如：hping3），但我特别感兴趣的是这是否可以使用 nmap 来实现，因为我在这里绑定到 Windows 机器（并且 WSL 仍然不支持为此所需的原始套接字内容）。
谢谢。
答案1
一切都取决于选择。以下是网站在端口 80 和 443 上有一个正常工作的 Web 服务器，但是不响应 ping。
C:\Users\doug>ping www.rlmueller.net
Pinging www.rlmueller.net [65.254.227.240] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
让我们尝试使用 nmap 的-sn选项：
nmap -sn www.rlmueller.net
结果是：
…
Host is up (0.031s latency).
…
因此服务器已启动，但我们不知道 nmap 为何会这样认为。但我们知道服务器没有启动，因为服务器正在响应 ping。
让我们使用--reason下一个选项：
nmap -sn --reason www.rlmueller.net
结果是：
...
Host is up, received syn-ack ttl 53 (0.031s latency).
…
啊哈！因此 nmap 判定服务器已启动，因为它-sn使用 SYN-ACK 响应了 SYN（根据 nmap 的选项文档，发送到端口 443）。
详细程度开关怎么样？
nmap -sn -v1 www.rlmueller.net
不。它提供了更多信息，但结果仍然是：
Host is up (0.031s latency).
nmap -sn -v2 www.rlmueller.net
是的。与使用 `--reason`` 选项类似，我们得到：
Host is up, received syn-ack ttl 52 (0.032s latency).
使用这些debug选项，我们可以获得更多细节。
nmap -sn -d1 www.rlmueller.net
...
We got a TCP ping packet back from 65.254.227.240 port 443
…
Host is up, received syn-ack ttl 52 (0.031s latency).
…
太棒了！这与文档中提到的 SYN 数据包发送到端口 443 的情况相符。
更高的调试级别，例如-d2或提供更多详细信息。如果您愿意，-d3可以将其一直提升到。-d6