主机名访问规则在各网络层分别意味着什么
服务名可以在 DNS、浏览器、代理或防火墙层面强制执行。请选择能看到你要治理的身份的那一层。
三个人用同样的话提出同样的要求:屏蔽对某个服务名的访问。一个人指的是浏览器不应打开该站点,另一个人指的是桌面语音客户端不应连到它的服务器,第三个人指的是某组外包人员不应使用某个特定的内部应用。句子一字不差,执行机制却几乎没有共同点。
按这一层实际能看到的标识符来选层,再按它覆盖的客户端来选。从你早已熟悉的防火墙命令出发,正是规则最终什么都拦不住、或者拦得太多的原因。
名字不是每一层都能核验的身份
Netfilter 一类包过滤器看到的是地址、协议和端口。它们看不到主机名,而等数据包到达它们时,名字早已解析完毕。针对地址写下的规则,就是关于该地址的规则,无论用户输入什么名字来访问它。
DNS 策略位于路径更早的位置,看到的是查询,它与随后的连接是不同对象。它管的是受控解析器返回的答案,而不是已经打开的连接,也不是配置为绕过该解析器的客户端。已解析的地址还可能在策略复核与下一次请求之间变化,所以 DNS 答案不是一份持久的授权声明。
越高的层看到越多上下文,覆盖的客户端却越少。这个取舍就是全篇的主题,也解释了为什么表中没有任何一行永远是正确答案。选择能看到你的策略真正针对的那个标识符的一行。然后接受那一行所意味的覆盖范围。
每一层能识别什么
从中间一列向外读表:一层能看到的标识符,决定了它能诚实执行的策略。
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
只有当一层看到的标识符与你治理的标识符一致时,这一层才属于该策略。表也说明了为什么在一层写下的规则很少能原样迁移到另一层,除非重新决定它保护什么。
显而易见的规则在哪里失效
地址规则对于由你掌控专用地址的服务完全正确,而这种归属应当写进策略。对于共享内容分发地址背后的一切则完全错误:同一条规则会波及无关服务,刷新后的 DNS 答案也不会把规则变成主机名授权。
受管浏览器策略比照抄的地址列表更直接地表达 Web 限制,但它只适用于管理系统所管辖的浏览器和配置文件。
那条浏览器规则对向另一台主机发送 UDP 的语音客户端毫无作用,它的模式由该产品定义,而不是借用别处的通配符惯例。CONNECT 代理同样只拿到隧道请求的主机和端口,读不到加密会话内部的路径。围绕协议暴露的东西来设计规则。然后写下它没有覆盖的部分,因为下一次请求恰恰来自那个缺口。
按客户端选,而不是按命令选
问清楚策略必须覆盖哪些客户端、可以漏掉哪些客户端。受管浏览器策略覆盖管理系统能触及的范围,止步于浏览器边界。解析器策略覆盖所有使用你的解析器的东西,这是更大的集合,而对不使用的人则开放失败。
对于你运营的服务,应用内的授权比任何网络边界都强,因为它跟随账号而不是路径。VPN 路由只是可达性,仅此而已:能向某个服务发包并不等于有权使用它。当真正要紧的标识符是用户或频道权限时,就在那里强制执行,并把网络规则当作第二层。
用资源的语言写规则
站得住脚的策略会写明资源、身份、范围内的应用以及承载它们的路径,包括在用的两个地址族。它还会说明规则顺带影响的共享基础设施会怎样。
这种表述产生一个日后可供审计的决定。以今天解析出的地址为依据的规则,会在地址第一次变化时制造事故,而没有人能解释当初的封锁为何正确。