你受到 CVE-2019-14899 影响吗？内核自查清单

扫描器在一台多年运行 VPN 的机器上报出 CVE-2019-14899，第一反应往往是宣布 VPN 坏了。这是错误的框架。被披露的问题是一名位于受害者本地网络中的攻击者推断某些 TCP 连接的信息，而不是某个网站解密你的隧道。

按顺序走完下面四项检查。每一项要么缩小问题范围，要么结束调查。

检查 1：公告是否覆盖你的内核

去查你自己发行版的记录，而不是博客对发布日期的转述。Ubuntu 针对该 CVE 的安全页面把 18.04 LTS 的通用 linux 包列为易受影响且修复被推迟，并在另外的行里跟踪其他内核包。把你的运行版本与内核包对应到正确的那一行。看起来眼熟的版本号并不等于匹配。

扫描器的命中只说明该标识适用于你资产清单中的某个东西，并不说明相邻设备利用了这台机器。

检查 2：模型里的攻击者是谁

威胁模型假定的是能够与受害者接入网络交互的相邻攻击者。那是一个特定位置，而不是任何不喜欢你出口节点的远程服务。如果用户从咖啡馆连接，这个假设是现实的；如果他们坐在受管理的企业局域网后面，那就是另一场讨论。

即使隧道已加密，也要把本地网络信任问题留着。加密回答的是与相邻性不同的问题。

检查 3：你依赖的是哪一层

正确校验的 HTTPS 为应用记录提供自己的保护，TLS 1.3 对这些数据做端到端认证。但它并不承诺攻击者无法中断底层 TCP 连接。因此应用可以读起来安全，却仍然可被中断，而中断与泄露不是同一种结果。评估风险之前先把两者分开。

这个区分对报告很重要。它把 VPN 不安全的含糊说法，变成关于相邻攻击者能观察到或中断什么的有界陈述。

检查 4：你实际部署了哪项缓解措施

披露文本讨论了路由与过滤类缓解，并明确其局限，包括反向路径过滤与非对称路由。不要把同一个 sysctl 值贴到每台 VPN 主机上就说修好了。反向路径过滤与路由相互作用，因此对一种拓扑有用的值可能破坏另一种。

验证是一条命令，不是一个勾选框。sysctl net.ipv4.conf.all.rp_filter 显示全局值，sysctl net.ipv4.conf.tun0.rp_filter 显示真正生效的按接口值。任何改动前后都要读这两个。

使用发行版指引和你自己的路由设计，然后在承载隧道的接口上确认设置，而不是在没人加载过的文件里。

该记下什么

记录相邻攻击者假设、正在运行的内核包、你匹配到的公告行、已部署的缓解措施及其作用位置，以及现有的应用层保护。再加上你核对公告的日期，因为那些页面会变。这样的组合才站得住脚。

操作系统发布日期和一条能用的 VPN 连接不是评估。它们只是两个恰好容易收集的事实。