VPN 服务器上的入站告警：读懂观测点

藏在 VPN 后面的服务器会一直保留自己的公网服务入口，而人们也一直在找到它们。告警队列里出现的并不是一个发现，而是三种可能的发现，含义各不相同。第一件事，是把暴露的服务和暴露的凭据分开。

按顺序走完这些观测点。当证据换了类别就停下来，因为下一阶段回答的是另一个问题。

第一阶段：抓包究竟看到了什么

抓包记录的是它所在路径点上能看到的东西。那个点可能位于后续过滤决策之前。抓到包只能证明流量确实到了那里。它无法证明之后发生了什么。

接口也要注意。在公网网卡上抓包和在隧道内部抓包，描述的是不同的到达点；告警引用了错误的那个点，结论就会跑偏。

Windows 在协议栈的多个层次上都会过滤，所以「抓包工具在二层、防火墙在三层」这种整洁的模型，遇到真实产品就站不住。Windows Filtering Platform 的概述描述了跨栈层的过滤，正因如此，观测顺序必须去确立，而不能靠假设。

第二阶段：丢弃记录能确定什么

丢弃记录说明某个策略边界拒绝了那个包。这是很强的证据。它同样是很窄的证据，因为它只覆盖一个边界上的一次决策。栈里其他任何环节都不在它的描述范围内。

对齐四元组和时间戳：相同的源、相同的目标、相同的端口，且在同一秒内。没有这个匹配，另一个日志里看起来相似的事件就只是另一件事。把它们凑在一起，只会拼出一个没人守得住的故事。

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

关闭的端口和被丢弃的包，从外面看一模一样，在这两份输出里却完全不同。这个差别，正是要读本地记录的全部理由。

第三阶段：认证事件能证明什么

认证事件说明某个组件处理了请求，并且处理到足以记录结果的程度。三个阶段里只有它谈身份，而它对之前到过多少包只字不提。

要读事件的实际上下文。不存在的账号登录失败，是扫描带来的噪声。真实账号配上说得通的来源却登录失败，是另一种优先级。登录成功，则完全属于另一类事件。

协议名也要看。RPC 和 RDP 是两个独立服务，端口也不同。只盯其中一个的检测器，覆盖不到另一个。汇总网络活动的工具，并不总会说明事件来自这两者中的哪一个。

一个对齐过的样本胜过一整块仪表盘

挑一个经过授权的测试，故意跑一遍，并从头到尾追一遍：目标地址和接口、真实源地址、服务端口、实际生效的防火墙配置文件和规则，以及与之对应的服务结果。把上游映射或云防火墙也算进这条链路，因为那里一条放行规则就可能压过本地那条整洁的规则。

然后把两项职责分开。如果管理只应走 VPN，那就在公网路径和隧道路径上同时落实，同时保留一条经过批准的恢复通道。监控被拒绝的尝试，和决定服务器该接受什么，不是同一件事。

一条地理位置规则、或一个被挡掉的无关协议，都替代不了找出被观测到的入口以及它得到的处置。VPN 也一样：把出站流量送进隧道，并不能说明任何入站授权。