我有 3 个系统 -
- 已禁用防火墙的 Windows 10 系统
- CentOs 8 系统防火墙已禁用(防火墙状态为非活动)
- 上述 CentOs 8 计算机上的 Windows 10 VM,已禁用防火墙
由于某种原因,我无法将这 3 台机器连接到一个网络上。这 3 台机器都分配了静态 IP,如下所示:
静态IP -
192.168.1.10, 192.168.1.125, 192.168.1.25
子网掩码 -
255.255.255.0
默认网关 -
192.168.1.1
Linux 系统和VM
托管在其上的 Windows 10 连接良好(通过主机适配器VirtualBox
,适配器IPv4
值为 192.168.1.11),甚至可以通过 ssh 进入。
但是,Windows 10
独立系统无法定位,ping
甚至无法ssh
进入任何这些系统。通过dynamic IP
我的提供商提供的服务,它们能够很好地连接,但是当我通过以太网电缆在独立的 p2p 网络中连接这两个系统(Windows 10 和 Linux 系统)时,它们就是找不到对方。
IPv6
在每个网络配置中都被禁用。我唯一能想到的是,机器没有指定相同的workgroup
,因为我的 Windows 10 系统已登录到域,而我的 Linux 系统(带有 Windows 10 VM)没有,但在上述场景中,没有域活动,因为机器通过 LAN 电缆连接并且不在任何其他网络上。
更新 -
IP 地址
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:04:5f:9e:94:43 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global noprefixroute enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::204:5fff:fe9e:9443/64 scope link
valid_lft forever preferred_lft forever
3: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 00:04:5f:9e:94:42 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:31:3c:a5 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:31:3c:a5 brd ff:ff:ff:ff:ff:ff
6: br-c91ce55ad4d6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:e6:4e:bd:04 brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-c91ce55ad4d6
valid_lft forever preferred_lft forever
7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:ca:60:cc:f5 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
8: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.11/24 brd 192.168.1.255 scope global vboxnet0
valid_lft forever preferred_lft forever
inet6 fe80::800:27ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
路由
default via 192.168.1.1 dev enp1s0 proto static metric 100 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-c91ce55ad4d6 proto kernel scope link src 172.18.0.1 linkdown
192.168.1.0/24 dev vboxnet0 proto kernel scope link src 192.168.1.11
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.10 metric 100 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
答案1
托管在其上的 Linux 系统和 Windows 10 VM 连接良好(通过 VirtualBox 的主机适配器,适配器 IPv4 值为 192.168.1.11),甚至可以通过 ssh 进入。
你的问题就在这里。你有两个物理上独立的网络192.168.1.x
只是恰好两侧都有编号。然而,它们仍然是独立的网络;数据包不会自动从主机 Linux 系统的一个接口流向另一个接口。
您的虚拟机可能仍可以访问 Internet,因为您或您的虚拟机软件可能已将 Linux 主机配置为充当路由器/网关,并配备 NAT。(NAT 是网络的管道胶带。)
但是,由于两边的网络号相同,因此您的虚拟机认为每个 192.168.1.x 地址都是当地的(子网掩码告诉它们!),因此它们不使用网关来访问它们。结果,在正常配置下,双方无法互相访问。
Linux 主机也无法很好地处理同一子网上的两个接口。您可以看到,ip route
有两个条目指向同一个目标;但只使用其中一个。操作系统不会跟踪哪台主机位于哪一侧。
您有四个选择:
继续使用路由,但将 VirtualBox“主机适配器”(vboxnet0)IP 地址更改为不同的网络,例如 192.168.2.x 就可以了。
使用 Linux 桥接合并两个网络:创建一个桥在主机上 (ip link add br0 type bridge),然后将您的真实以太网和 VirtualBox 虚拟接口都放入网桥中 (ip link set eth0 master br0)。从两个接口中删除 IP 地址,并在 br0 (网桥) 上配置 192.168.1.11/24。
使用 VirtualBox 桥接合并两个网络:将 VM 配置更改为使用“桥接网络”并选择物理以太网接口。这仅在您的以太网配置好后才有效。
在虚拟机中创建两个接口:一个用于像现在这样的主机网络,一个用于与物理以太网桥接网络。
我唯一能想到的是机器没有指定同一个工作组,
完全不相关。仅有的“工作组”的作用实际上是限制哪些计算机出现在网络计算机列表中。(NetBIOS“计算机浏览”机制设计于 20 世纪 80 年代,工作组用于限制每台 LAN 计算机必须保存的数据量。)它不会影响 IP 或 TCP 级别的通信,甚至不会影响直接的 Windows SMB 文件共享连接。