Nmap 的原始扫描在 VPN 下失败，但 -sT 连接可用？

页面能通过隧道加载，而端口扫描却报告主机离线，第一反应往往是 VPN 拦了什么。通常它并不会拦什么新东西。两项检查向操作系统申请的能力不同，只有一项需要原始数据包访问。在碰隧道之前，先弄清是哪项能力失败了。

把能力与隧道分开

普通应用请求内核打开 TCP 连接，内核在无特殊权限的情况下完成握手。原始扫描自己构造数据包，这需要原始套接字或捕获驱动，具体取决于平台。这些是权限与驱动问题，无论 VPN 是否连接都存在。

这一区别解释了常见的不对称现象。curl 成功，因为套接字路径可用；SYN 扫描失败，因为进程无法在隧道接口上打开原始套接字。它也解释了相反的情形：路径丢弃探测包，于是原始扫描报告被过滤，而应用路径依然正常。

两个结果都没有描述远程服务。它们只描述了同一种方法下的一条路径，因此要把方法与结论绑在一起。

在一台获准的主机上运行连接检查

选定你的任务涉及的那一台主机，然后使用不需要原始访问的模式。这里的示例目标是 198.51.100.24，它是专为此类示意保留的文档地址空间。

一行命令，一台主机，一个端口，没有发现阶段：

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT 选择完整的 TCP 连接，因此走的是应用所用的同一条内核路径，不需要捕获驱动。-Pn 跳过主机发现；nmap 仍会为本地网段目标做链路层解析，因此该选项并不承诺零前置流量。--unprivileged 告诉 nmap 假定自己没有原始或窃听权限，这会改变方法却不会给予任何东西。

把每个选项当作一个变更，而不是修补

把每个选项看作关于方法的声明。-sT、-Pn 或 --unprivileged 都不会添加路由、打开远程防火墙或校验证书。连接扫描还会完成服务会记录的真实握手，因此获准检查与未获准扫描在服务器看来除规模与节奏外完全一致。不断堆叠选项直到输出变化，正是把方法问题记录成网络发现的方式。

输出显示已关闭时，说明有东西用重置回应了，这与沉默是不同的发现。输出显示已过滤时，说明某个设备丢弃了探测包或它的回应，VPN 可能只是巧合。记下确切措辞，因为发现阶段的判定与探测层面的故障指向不同层级。

如果确实需要特权模式，平台拥有者将决定权限、驱动与接口布局是否受支持。提升同一调用并不会改变它的方法。

停在传输结果上，然后再测试服务

完成的握手只回答了关于一个地址、端口、源与时刻的一个问题。它并不能证明后端健康，因为负载均衡器或前置代理可能接受了连接，而它后面的应用已经停止。

接着用服务自带的客户端，让 TLS 身份与应用行为作为独立事实被观察：

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

还有一个习惯能让结果保持可用。记下确切的命令、所用源地址与时间，因为没有这些语境，传输结果既无法复现也无法比较。

如果证书写的是你没预期的主机，那说明传输是通的，路由从未是问题；故障在于虚拟托管或 DNS。如果握手失败，记下本地错误字符串，而不是对隧道做概括。把范围说明放在结果旁边，因为下一个人需要知道是哪种方法得出的。