通过 VPN 后 Nmap 结果不同？先固定目标

对同一网站做两次端口扫描，结果可能不一致，因为两次运行之间域名解析到了另一个地址，而不是隧道改变了目标所暴露的内容。主机名只是一条查询指令，Nmap 在扫描时会照它执行。当解析器返回另一条记录时，第二次扫描测量的其实是另一台机器。

把数字地址固定下来，比较才重新有意义。报告里的其他一切，从计时到中间设备，仍然是需要单独控制的变量。

在报告里看起来一样的两个实验

拿一个域名和它自己比较，你至少同时改动了两个东西：数据包经过的路径，以及解析器返回的目的地。输出上的差异无法归因于其中任何一个。这种含糊正是前后两次扫描常常变成谁也说不清的争论的常见原因。

拿一个地址和它自己比较，目的地在构造上就是固定的。仍然存在的差异属于路径、源地址、中间的过滤，或机器自身的状态。你去掉了一个变量，但这不等于去掉了全部。

在从端口表得出任何结论之前，先写下你实际做的是这两个实验中的哪一个。这种区分听起来很学术，直到有报告声称 VPN 拦下了一个在你第二次访问的地址上从未开放过的端口。

先解析，再扫描你记录下来的地址

把解析和探测分开，让这两件事落在不同的地方。问系统它解析出了什么，把答案存下来，然后把字面地址交给 Nmap。在隧道断开和建立两种状态下重复同样两条命令。

getent hosts scan.example.net
dig +short scan.example.net A
nmap -Pn -sV -p 443,8443 192.0.2.40

这里的 -Pn 参数很重要，因为忽略发现探测的主机会被报告为下线，空结果也会被误读成端口关闭。只在运营方已批准的目标上使用 -sV；版本探测比裸连接更吵，属于书面范围之内。

Nmap 的目标规范参考明确写道，主机名会在扫描前解析成地址，返回多个地址时工具只扫描第一个，除非你要求全部。这种行为里没有任何 VPN 特有的东西。分割 DNS、另一个解析器，或者以新顺序应答的负载均衡器，都能在没有任何隧道的情况下造成同样的效果。

把解析出的值留在扫描输出旁边，连同地址族、参数集合和时间戳。反向查询返回公司名是另一种观察，并不能证明是哪个后端应答的。

改变的端口状态能说明什么、不能说明什么

目标固定之后，从开放变成被过滤的端口通常指向路径。想想上游的 ACL、有状态防火墙，或者对隧道出口和家庭出口区别对待的服务商。在范围允许时，测试同一子网里第二个已批准的地址来缩小范围，因为换掉主机名会把解析器的问题重新引进来。每次运行只动一个变量，这就是全部方法。

服务横幅变化时端口仍然开放，是另一回事。那种模式符合在多个后端之间分配连接的前端，你这边再怎么扫描也点不出它背后的租户。

扫描从不说的是意图。被过滤的端口是策略结果，不是有人专门针对你隧道的证据；开放的端口也不是背后应用会为你服务的证据。在写下两种说法中的任何一种之前，先和你运维的组件日志做对照。

记录结果，让比较经得起复核

有用的记录包含请求的域名、解析出的地址及其地址族、确切的参数、使用的源地址，以及覆盖该目标的授权。还要加上时间，因为 DNS 应答会轮换，没有时间戳的报告会把同一场争论再请回来一次。也加上扫描器版本，因为默认探测行为会随版本漂移。如果两次运行用了不同方法，就把它们当成不同实验，并在标题里说明，而不是写在脚注里。

按事实给发现贴标签：目的地不同、源路径不同，还是差异仍未解释。这套说法能让扫描报告保持诚实，也能阻止解析器的应答被重新发布成 VPN 拦截事件。下一步通常是在固定地址的前提下再跑一次，而不是扩大扫描范围。