Meshnet、Docker 与两者之间的权限

两个 URL 在节点浏览器里可能一模一样，对防火墙而言却是完全不同的两回事。一个指向直接监听在主机上的服务。另一个指向一台主机地址，其端口被发布到容器网络，再由一步转换把连接交给另一个 IP。在以逐节点权限控制本地网络访问的点对点 mesh 里，这点差别就是整场评审。

权限说的是主机端点，转换说的是 Docker，登录说的是应用。三个决定，三个该看的地方。

发布之后，跟着目的地址走

以一台 Linux Docker 主机为例，它把容器的 80 端口发布到主机的 8080 端口。节点连接主机 8080 上的 mesh 地址，主机接受连接，随后目的地址转换把它改写成容器的网桥地址，通常是 172.17.0.2 的 80 端口之类。

等到某条规则检查这条流时，真正值得关注的目的地是容器，而不是主机。只围绕“本机上的某个服务”做推理的策略，推理的是错误的对象。请求落在了主机上，却被投递到了别处。

正因如此，mesh 文档才把 Docker 容器列入 Linux 上受本地网络权限管辖的资源。该权限不是普通 VPN 允许列表条目的同义词，这两个控制也不能互相替代。一个决定节点究竟能否访问本地资源，另一个决定隧道路由承载哪些目的地。

决定一条权限授予多少本地访问

给一个节点开放本地网络访问，并不是关于单个容器的决定。它可能暴露同一主机上其他已发布的服务，而且取决于主机如何转发，还可能伸得更远。为一个仪表盘按下开关之前，先审阅实际生效的范围。

然后看 Docker 在哪里发布端口。发布在 0.0.0.0 上会在每个主机地址上创建监听，这可能在 mesh 条目之外再加一条普通 LAN 条目。如果需求只是 mesh，把发布绑定到你确实想要的那个地址或网卡上，并把更宽的绑定当作单独的问题，而不是当作方便。

把主机的转发策略和应用自身的认证都收得足够窄，只覆盖该服务。看起来私有的 URL 不是访问控制，而一个信任网桥网络上所有来源的容器，也不会因为 mesh 节点已被批准就受到保护。应用自身的认证是第三个决定，也是唯一知道用户是谁的那个。主机层面的权限提供不了这份认知。

测试权限本身，而不只是 URL

从已批准的节点打开确切的这项服务，确认它能用。然后试一个应当保持拒绝的目的地，确认它确实不能用。只测顺利路径只能告诉你权限已授予，却不会告诉你边界就在你以为的地方。

单独比较一个主机原生服务。如果数据库监听在主机上，而仪表盘跑在容器里，它们穿过同一条权限的路径不同，主机的转发策略对二者的管辖也可能并不一致。写评审笔记之前，先记下哪个是哪个。

不要为了“重置”访问而清空 Docker 的表或 mesh 客户端的规则。两个产品都会安装各自的策略集成，清掉它只会造出一台看似能用、实则绕过了你被要求评估的那些控制的主机。某条规则看着不对，就读懂它、只改那一条。如果你说不清一条规则在做什么，那本身就是问题，而不是删掉它的理由。

用系统自己的说法来写问题

真正要紧的是产品实际执行的那种区分，而不是评审模板里的那种：到达主机端点的权限、到达被路由的私有资源的权限、使用应用的权限。发布端口并不会移动这三个决定中的任何一个，把三者当成一个的评审者，会批准错误的范围。

把主机地址、发布的端口、容器目的地和节点权限写进同一句话。这句话别人可以复验，也正是这一点让它成为问题而不是观点。