三个人用同样的话提出同样的要求:屏蔽对某个服务名的访问。一个人指的是浏览器不应打开该站点,另一个人指的是桌面语音客户端不应连到它的服务器,第三个人指的是某组外包人员不应使用某个特定的内部应用。句子一字不差,执行机制却几乎没有共同点。

按这一层实际能看到的标识符来选层,再按它覆盖的客户端来选。从你早已熟悉的防火墙命令出发,正是规则最终什么都拦不住、或者拦得太多的原因。

名字不是每一层都能核验的身份

Netfilter 一类包过滤器看到的是地址、协议和端口。它们看不到主机名,而等数据包到达它们时,名字早已解析完毕。针对地址写下的规则,就是关于该地址的规则,无论用户输入什么名字来访问它。

DNS 策略位于路径更早的位置,看到的是查询,它与随后的连接是不同对象。它管的是受控解析器返回的答案,而不是已经打开的连接,也不是配置为绕过该解析器的客户端。已解析的地址还可能在策略复核与下一次请求之间变化,所以 DNS 答案不是一份持久的授权声明。

越高的层看到越多上下文,覆盖的客户端却越少。这个取舍就是全篇的主题,也解释了为什么表中没有任何一行永远是正确答案。选择能看到你的策略真正针对的那个标识符的一行。然后接受那一行所意味的覆盖范围。

每一层能识别什么

从中间一列向外读表:一层能看到的标识符,决定了它能诚实执行的策略。

LayerIdentifier it seesWhat it cannot see
Packet filteraddress, protocol, portthe name, or which other services share that address
DNS policythe queried name and the answer handed backconnections made by clients that ignore the resolver
Managed browsersupported URL patterns on managed profilesnon-browser clients, or unmanaged devices
CONNECT proxyhost and port for tunnelled requeststhe path inside an encrypted request

只有当一层看到的标识符与你治理的标识符一致时,这一层才属于该策略。表也说明了为什么在一层写下的规则很少能原样迁移到另一层,除非重新决定它保护什么。

显而易见的规则在哪里失效

地址规则对于由你掌控专用地址的服务完全正确,而这种归属应当写进策略。对于共享内容分发地址背后的一切则完全错误:同一条规则会波及无关服务,刷新后的 DNS 答案也不会把规则变成主机名授权。

受管浏览器策略比照抄的地址列表更直接地表达 Web 限制,但它只适用于管理系统所管辖的浏览器和配置文件。

那条浏览器规则对向另一台主机发送 UDP 的语音客户端毫无作用,它的模式由该产品定义,而不是借用别处的通配符惯例。CONNECT 代理同样只拿到隧道请求的主机和端口,读不到加密会话内部的路径。围绕协议暴露的东西来设计规则。然后写下它没有覆盖的部分,因为下一次请求恰恰来自那个缺口。

按客户端选,而不是按命令选

问清楚策略必须覆盖哪些客户端、可以漏掉哪些客户端。受管浏览器策略覆盖管理系统能触及的范围,止步于浏览器边界。解析器策略覆盖所有使用你的解析器的东西,这是更大的集合,而对不使用的人则开放失败。

对于你运营的服务,应用内的授权比任何网络边界都强,因为它跟随账号而不是路径。VPN 路由只是可达性,仅此而已:能向某个服务发包并不等于有权使用它。当真正要紧的标识符是用户或频道权限时,就在那里强制执行,并把网络规则当作第二层。

用资源的语言写规则

站得住脚的策略会写明资源、身份、范围内的应用以及承载它们的路径,包括在用的两个地址族。它还会说明规则顺带影响的共享基础设施会怎样。

这种表述产生一个日后可供审计的决定。以今天解析出的地址为依据的规则,会在地址第一次变化时制造事故,而没有人能解释当初的封锁为何正确。

相关文章