当处于 NAT 模式时，管理程序的网络子系统通过在数据包离开主机时对其进行修改来运行。假设 TCP/IP over ethernet，肯定改变的组件是：

• 源地址
• 源 MAC
• 通常是 TTL
• 通常是源端口

有时其他 TCP 标志也会被修改，例如 DF、窗口大小等。

在一个行为良好的网络中，所有这些标志和选项都以根据 RFC 有意义的方式设置，然后可以并且预期会适当地修改这些内容。然而，漏洞评估工具通过以不合规和行为不端的方式做事来运作。因此，那些通常可接受的标头和协议修改实际上会导致软件误解结果。

我们以操作系统检测为例。系统将向系统抛出正常和异常数据包的组合。大多数操作系统中使用的网络堆栈是众所周知的，因此它们的响应在成功和失败情况下都应该是可预测的。因此，评估工具将获取响应，在操作系统检测表中查找它们，并根据这些响应对它认为远程主机正在运行的内容做出一些猜测。由于 NAT 设备通过处理所有进出的数据包来工作，因此会污染您的数据。

现在，在绝大多数情况下，数据可能仍然完全没问题。但是，由于数据包是从评估工具外部修改的，因此该工具不一定知道进行了哪些更改。因此，您冒着工具对不正确的数据执行分析的风险，这可能会使您的结果无效。

在相关说明中，历史上一直建议不要在漏洞评估系统上运行主机防火墙，原因大致相同。由于它们在设计上会喷出异常流量，并且由于防火墙旨在保护您免受异常流量的影响，因此您的防火墙完全有可能以评估工具意想不到的方式丢弃某些东西。与 NAT 示例非常相似，这也会使您的结果无效。