如何从 Mulvad VPN 的“本地网络共享”阻止中排除 libvirt 使用的 dnsmasq

Question

下面提到的链应该包含在一个单独的表中，例如：

table inet allowedLocal {
    ...
}

这取决于您希望允许的具体流量。如果您希望仅允许来自虚拟机的 DNS 请求（以及来自主机的回复），那么您应该使用如下链：

chain input {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } th dport 53 ct mark set 0x00000f41
}

设置了 (conntrack mark)后ct mark，您不需要任何hook output来自主机的回复链，因为它们将属于相应请求的相同“连接”，因此会ct mark自动获得相同的连接。priority mangle将确保ct mark在流量进入chain input（table inet mullvad所在位置ct mark 0x00000f41 accept）之前设置。

与我所知道/记得的相反，您似乎不需要设置正确的meta mark（fwmark）来根据需要路由回复，至少不需要从主机本身到“本地”网络的回复。（令人惊讶的是，实际行为似乎是特定于应用程序的。当我使用 systemd-resolved 存根额外侦听器进行测试时，回复会从请求发出的接口中发出，即使我消除了任何路由，包括但不限于前缀路由，当我使用 dnsmasq 进行测试时，回复始终按照路由main表进行路由，而忽略所有 ip 规则/备用表。）

如果您想允许所有“连接”由VM发起那是(L3-)目的地为主机，您可以删除meta l4proto { tcp, udp } th dport 53：

chain input {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 ct mark set 0x00000f41
}

请注意，上述链不会建立“连接”由主机发起那是(L3-) 发往 VM允许。如果你想允许这样的“连接”，你需要这样：

chain output {
    type route hook output priority filter; policy accept;
    ip daddr 192.168.122.0/24 ct mark set 0xf41 meta mark set 0x6d6f6c65
}

附带说明一下，ct mark该链中的设置主要是为了允许来自虚拟机的回复。真正让来自主机的发起流量被允许的是oif "wg-mullvad" accept中chain output的规则table inet mullvad。流量似乎是type route在稍后阶段遍历链的，因此即使在做出新的路由决策之前（因为meta mark），也必须允许原始路由。换句话说，我想如果一个人想要（进一步）过滤已被一条type route链“更改”的流量，他们将不得不使用另一条type route链（而不是一条type filter链）。（如果你不关心细节，可以忽略这一段。无论如何，这些信息可能并不完全正确。）

编辑：我只是注意到，chain prerouting实际上table inet mullvad设置了ct mark所有iif != "wg-mullvad"流量所需的流量，这意味着您不需要我上面给出的任何链来仅允许 DNS 为虚拟机工作。您可以尝试它们，看看它们是否有帮助，但现在我觉得问题可能是由于dnsmasq某种原因没有10.64.0.1用作其上游服务器，正如我最初怀疑的那样......

Answer 1