Eu tenho 3 sistemas -
- Sistema Windows 10 com firewall desativado
- Sistema CentOs 8 com firewall desabilitado (status do firewall inativo)
- VM Windows 10 na máquina CentOs 8 descrita acima com firewall desabilitado
Por algum motivo, não consigo conectar esses 3 em uma única rede. Todas as 3 máquinas receberam IPs estáticos, como -
I.P. estático -
192.168.1.10, 192.168.1.125, 192.168.1.25
máscara de sub-rede -
255.255.255.0
Gateway padrão -
192.168.1.1
O sistema Linux e o Windows 10 VMhospedado em cima dele se conectam bem (através de um adaptador de host para VirtualBox, tendo IPv4o valor do adaptador como 192.168.1.11) e podem até mesmo ssh nele.
No entanto, o Windows 10sistema autônomo não consegue localizar pingou mesmo sshentrar em nenhum desses sistemas. Com dynamic IPo fornecido pelo meu provedor, eles conseguem se conectar bem o suficiente, mas quando conecto os 2 sistemas (sistemas Windows 10 e Linux) por meio de um cabo ethernet em uma rede autônoma, tipo p2p, eles simplesmente não se encontram.
IPv6está desativado em cada uma das configurações de rede. A única coisa que consigo pensar é que as máquinas não especificam o mesmo workgroup, pois meu sistema Windows 10 está conectado a um domínio, e meu sistema Linux (com Windows 10 VM) não, mas no cenário descrito acima, há não há atividade de domínio, pois as máquinas estão conectadas via cabo LAN e não estão em nenhuma outra rede.
ATUALIZAR -
endereço 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
rota ip
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
Seu problema está aqui. Você tem duas redes fisicamente separadas que são numeradas
192.168.1.xem ambos os lados. No entanto, ainda são redes separadas; os pacotes não fluem automaticamente de uma interface no sistema host Linux para outra.Suas VMs ainda podem ter acesso à Internet porque você ou seu software de VM provavelmente configurou o host Linux para atuar como um roteador/gateway completo com NAT. (NAT é fita adesiva para redes.)
No entanto, como os números de rede são os mesmos em ambos os lados, suas VMs pensam que todos os endereços 192.168.1.x são locais (é o que a máscara de sub-rede informa a eles!), portanto, não usam um gateway para alcançá-los. Como resultado, os dois lados não podem alcançar um ao outro na configuração normal.
O host Linux também não lida bem com duas interfaces na mesma sub-rede. Você pode ver que
ip routetem duas entradas para o mesmo destino; apenas um deles é usado. O sistema operacional não rastreia quais hosts individuais estão em qual lado.Você tem quatro opções:
Continue usando o roteamento, mas altere o endereço IP do "adaptador de host" do VirtualBox (vboxnet0) para uma rede diferente, por exemplo, 192.168.2.x fará o trabalho.
Mesclar ambas as redes usando bridging Linux: Crie uma ponte no host (ip link add br0 type bridge) e, em seguida, coloque sua Ethernet real e a interface virtual do VirtualBox na ponte (ip link set eth0 master br0). Remova os endereços IP de ambas as interfaces e configure 192.168.1.11/24 em br0 (a ponte).
Mescle ambas as redes usando a ponte do VirtualBox: altere a configuração da VM para usar "Rede em ponte" e selecione a interface Ethernet física. Isso só funcionará enquanto sua Ethernet estiver configurada.
Crie duas interfaces na VM: uma para rede de host como agora, uma para rede em ponte com sua Ethernet física.
Absolutamente irrelevante. A única coisa que um "grupo de trabalho" faz é limitar quais máquinas aparecem na lista de computadores em rede, praticamente. (O mecanismo de "navegação do computador" NetBIOS foi projetado na década de 1980 e os grupos de trabalho foram usados para limitar a quantidade de dados que cada computador da LAN tinha que conter.) Ele não afeta a comunicação no nível IP ou TCP e, nesse caso, nem mesmo afeta conexões diretas de compartilhamento de arquivos SMB do Windows.