☰

双网卡不允许局域网中的 Minecraft 服务器

tag-icon • tag-icon networking server minecraft
双网卡不允许局域网中的 Minecraft 服务器

我正在运行配置了两个 NIC 的 Ubuntu Server 22.04。这是一台虚拟机，其 NIC1 在 VLAN0 上，NIC2 在 VLAN10 上（虚拟机不知道，这是在主机的网桥中指定的）。

我使用 netplan 来设置网络配置：

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18: # NIC1 (VLAN0)
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.168.1.131/24
      nameservers:
        addresses:
          - 192.168.1.1
        search: []
      routes:
        - to: 192.168.1.0/24
          via: 192.168.1.1
    ens19: # NIC2 (VLAN10)
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.168.10.103/24
      nameservers:
        addresses:
          - 1.1.1.1
          - 1.0.0.1
        search: []
      routes:
        - to: default
          via: 192.168.10.1
        - to: 192.168.10.0/24
          via: 192.168.10.1

在大多数情况下，这似乎工作得很好。我的防火墙（网关）阻止了 VLAN 之间的所有流量，但端口 25565 的 VLAN0 到 VLAN10 除外（稍后会详细介绍），并且建立了从 VLAN10 到 VLAN0 的连接规则。

有时我会遇到这种奇怪的情况：我可以在两个网卡上 ping 通 LAN 之外的 IP 地址，但无法下载东西（wget、curl 等）。只有网卡 2 可以工作。我搞不清楚问题是什么，也不知道为什么它在重启后可以工作。

但我面临的主要问题是我正在使用 Docker 容器运行 Minecraft 服务器。我已将其绑定到接口 ens19（NIC2），端口为 25565（默认 MC 端口）。我可以使用我的公共 IP 地址从 LAN 外部访问 MC 服务器，我可以使用虚拟机 IP 地址（NIC2）从 LAN 内部访问服务器。但是，我无法使用我的公共 IP 地址从 LAN 内部访问服务器。

我已经确认这不是我的防火墙（网关），因为我可以看到它没有阻止该连接，甚至通过我上面解释的端口 25565 规则接受该连接。我无法弄清楚这一点，它似乎与路由有关，但在使用服务器的 LAN IP 地址时它显然有效。如果我没记错的话，无论我是通过 LAN 还是公共连接，传入客户端的返回地址（源）都应该相同？

我还确认我的环回工作正常，因为我可以通过 LAN 内的公共 IP 地址访问另一台 VM（只有 1 个 NIC）上的 Web 服务器。

当我pktstat -n尝试从 LAN 连接到 MC 服务器时，我可以看到以下内容：

292.9 8% tcp 192.168.1.217:55701 <-> 192.168.10.103:25565 192.168.1.217 是我在 LAN 中尝试连接到 MC 服务器的计算机。但是，当指定接口时，pkstat -n -i ens18它仍然会显示出来，即使这不是 MC 服务器正在监听的接口。数据包显示在两个接口上。我可以使用服务器的 NIC1 IP 地址连接到服务器，并且数据包在两个接口上都可见。

编辑：当我删除第一个接口时，我无法直接访问我的 LAN，并且只有 2nc NIC 的 VM 网络，一切都正常。这显然是双 NIC 的问题，可能与 Docker 容器有关。

答案1

您无法从 LAN 内部访问公共 IP。这是不可能的，因为 NAT 是在路由器的 WAN 链路上提供的，除非流量来自外部->内部，否则这些规则不会生效。通过公共 IP 的内部到内部流量将被丢弃。Ping WAN 地址会起作用，因为不需要进行另一个 NAT 或“重新注入”即可成功。

但是，最好的解释方式是，您的流量将转到公共 IP，并且由于它已经从内部到外部 NIC 路由了“一次”，因此路由器认为它已经完成了。流量将不会重新注入其自己的接口。根本不可能发生这种情况。公共地址永远不应该为您工作。（而且，您为什么需要它？）

NIC2 被指定为 ping 的默认路由，因此所有流量都将从那里发起。NIC1 仅在您 ping 192.168.1.0/24 网络上的任何地址的情况下使用，因为这将是该流量的最直接链接，并将抢占只有“模糊”默认路由的 NIC2。

curl，不管是什么，这都是防火墙规则在某个地方出错了。除非您在路由器上安装了过滤规则集，否则路由器不会做出这些决定。为了测试，我会禁用它们，并确保它们符合您的预期。删除所有防火墙规则，进行测试，然后慢慢将内容重新添加到其中。通常的罪魁祸首是没有将“全部删除”规则作为最后一条规则。如果不是这种情况，则忽略后面的规则。在允许流量的规则评估之前，内容会被删除。顺序很重要……所有允许规则都先执行，所有删除都最后​​执行。防火墙规则通常是“首次匹配”，因此如果删除在允许规则之前，则每次都会删除。这是我能想到的唯一会导致您出现问题的原因。

相关内容