Nebula 灯塔过滤器与防火墙：各自拦截什么

从相反的一端看 Nebula 握手，两种机制看起来可以互换。一个决定节点向灯塔通告哪些地址、会尝试哪些远端地址；另一个决定隧道建立后什么可以通过。过滤器可以在任何防火墙规则被评估之前阻断连接，防火墙规则却无法救活被发现问题移除的端点。两层回答的是不同的问题，它们起作用的顺序才是关键。

沿着一条连接走过四个阶段：通告的本地地址、被考虑的远端端点、握手，以及叠加层中的流量。每个阶段都有自己的配置和自己的失败特征。

从节点通告的本地地址开始

local_allow_list 会在向灯塔上报之前过滤本机的本地地址。条目可以是地址范围，配置也支持接口名模式。当主机拥有容器网桥或不应成为对等端点的额外隧穿接口时，这一点很有用。

逐一检查主机接口，问哪些是远端对等体真正能到达的。Docker 网桥地址对该主机是本地的，对另一网络中的对等体毫无用处。通告它只会浪费发现，还可能把对等体引向一个永不响应的地址。对等体无法路由到的一切，都是灯塔应答中的噪声。

在这里，窄的允许列表比宽的拒绝列表更安全。如果只有允许条目，未指定的其余部分会被排除；之后再加入拒绝条目会改变默认逻辑，并且需要单独复核。这一改动值得再审视一次默认值。

remote_allow_list 会在握手期间过滤本机为远端对等体考虑的地址。它作用于底层地址，而不是隧道建立后对等体所使用的叠加层地址。

私有地址段在共享办公网络中完全可用，而当两台主机位于互不相关、都使用 10.0.0.0/8 的网络中时就毫无意义。过滤器让你优先选择可路由的路径，并忽略这种巧合。

当对等体连不上时，把正在尝试的地址与匹配它的规则对照。开启握手日志并读取被选中的远端地址；日志行会指出通过过滤的端点，这比该对等体拥有的地址列表更有用。

通告一侧的接口名过滤器可以在接收一侧看到之前就移除该端点。只有单向失败时，请检查两端节点。

Nebula 防火墙规则在叠加层内部、隧道建立之后起作用。它们匹配主机、组、端口和协议，并决定数据包能否进入或离开本地主机。它们不选择底层端点。

这种分离解释了一种常见的误诊。运维人员为某个端口加上防火墙规则，却仍然连不上，因为灯塔过滤器移除了唯一可达的端点。另一位运维人员打开了地址过滤器，却仍然到不了服务，因为叠加层防火墙拒绝了该端口。

要在正确的层读取失败。始终无法完成的握手指向发现、端点过滤或网络路径。握手完成后服务连接被拒绝或被丢弃，则指向叠加层防火墙或应用本身。

灯塔配置支持只允许、只拒绝和混合列表，未指定其余部分的默认值在这些形态之间并不相同。混合列表需要为地址族给出明确的默认值；假设其余部分会像旧配置那样行为，正是让一个原本可用的端点悄然消失的方式。

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

把默认值当作规则的一部分，而不是样板文字。如果该族的默认值是否决，那么每一个未列出的地址都会被排除，包括在写完配置之后新增的办公网段。

记录哪些地址本应可达，并从两侧测试。对一对对等体有效的过滤器，可能对另一对失效，因为后者唯一的公共路径使用了列表排除的地址。

如果每个候选端点都被过滤掉或不可达，答案不是一份更宽的、把你并不信任的地址重新放行的允许列表。当直连不可行时，Nebula 的 relay 配置提供了一条替代的对等体路径。

Relay 解决的是传输与发现，而不是授权，它也不会拓宽防火墙。叠加层防火墙仍然决定可以使用哪些服务，relay 也不会把灯塔过滤变成访问控制机制。

在关闭直连端点的情况下测试 relay 路径，确认预期服务仍能工作，而不该工作的服务则不行。这一个测试把传输修复与策略变更区分开来，也让两层都保持诚实。