Ao tentar solucionar um ping com falha do host do Windows para o endereço IP de uma máquina virtual convidada do Linux (192.168.1.19), fiz um traceroute:
$ traceroute 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 Samsung.station (192.168.1.17) 3132.517 ms !H 3132.491 ms !H 3132.489 ms !H
$ ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19) 56(84) bytes of data.
From 192.168.1.17 icmp_seq=1 Destination Host Unreachable
From 192.168.1.17 icmp_seq=2 Destination Host Unreachable
$ ping hostname
PING hostname (192.168.1.19) 56(84) bytes of data.
From Samsung.station (192.168.1.17) icmp_seq=1 Destination Host Unreachable
From Samsung.station (192.168.1.17) icmp_seq=2 Destination Host Unreachable
Eu posso pingar o IP do host (192.168.1.15) do convidado. O problema é que eu sei o que tenho na minha rede, mas não tenho ideia do que essa Samsung.stationmáquina deveria ser. Fiz login no roteador Wi-Fi e não consigo identificar nenhum dispositivo com um endereço IP "192.168.1.17". Desliguei ou desconectei o Wi-Fi de todos os poucos dispositivos Samsung na rede, mas ainda obtenho o mesmo resultado.
Meu objetivo final é fazer o ping funcionar nos dois sentidos, mas agora também gostaria de saber se há algo que eu possa fazer para identificar esse misterioso dispositivo! Eu vi uma pergunta relacionada, mas ainda não estou tentando bloquear dispositivos, primeiro quero saber qual seria o melhor próximo passo aqui, antes de reiniciar o roteador. Se alguém puder dizer com confiança que não existem ferramentas Linux que possam me ajudar a resolver isso ou obter mais informações, essa também é uma resposta válida. Obrigada.
Atualizar
A máquina host está executando o Windows 10, conectado à rede na interface Wi-Fi integrada.
A máquina virtual está no VirtualBox. Eu escolhi um "Adaptador em Ponte" intencionalmente, para obter um endereço IP DHCP dedicado, o que torna fácil e conveniente acessar seu servidor web local. Essa configuração estava funcionando bem em uma VM Ubuntu anterior, mas a VM em questão aqui é uma nova instalação mínima do Debian 11 (sem desktop).
Eu também reiniciei o roteador Wi-Fi, então algumas coisas mudaram:
- O host do Windows está agora em 192.168.1.16, mas aparece no roteador Wi-Fi com o "nome do host" da VM! Provavelmente era o mesmo que antes da reinicialização, eu provavelmente tinha perdido o fato de que o nome do host para o host do Windows não estava na lista de dispositivos.
- A VM ainda relata um IP de 192.168.1.19. Mas agora ele também falha ao pingar o IP do host (.16) e
traceroutepara 192.168.1.16 apenas mostra* * *todos os 30 saltos. - Fazer
traceroutedo host para o IP do convidado relatado ainda mostra o misterioso salto para o IP do ponto 17, mas não tem mais o nome doSamsung.stationhost ao lado dele, não sei de onde veio antes. Aqui está:
$ traceroute 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 192.168.1.17 (192.168.1.17) 3121.263 ms !H 3121.242 ms !H 3121.239 ms !H
Eu colaria a saída da ip addressVM, mas não tenho a integração da área de transferência funcionando, e mesmo a pasta compartilhada que era fácil na VM anterior não é visível nesta, então também não posso redirecionar a saída para um arquivo.
Agora é evidente que a raiz do problema de conectividade parece ser que o adaptador em ponte falhou ao obter seu próprio IP DHCP do servidor DHCP do roteador, o que provavelmente perdi antes da reinicialização devido ao nome do host da VM aparecer na lista de Wi-Fi dispositivos no roteador.
Isso acabou sendo mais uma solução de problemas do VirtualBox do que qualquer coisa, peço desculpas por isso. Provavelmente vou atribuir um IP fixo à VM. Qualquer dica sobre o mistério do salto inesperado ainda seria interessante.
Segunda atualização
Acabei de lembrar que posso usar tcpdumppara obter mais informações. Tem sido uma das minhas ferramentas favoritas de solução de problemas de rede há anos! Vou postar uma atualização ou uma resposta dependendo do que eu encontrar. Além disso, ainda não reiniciei o Windows. Outras sugestões ainda são bem-vindas.
192.168.1.19 não existe. 192.168.1.17 está dizendo que não existe. Como está na mesma sub-rede e é o primeiro salto, isso sugere que 192.168.1.17, samsung.station, é o sistema no qual você está executando o traceroute e ping. Ou 192.168.1.17 está agindo como proxy e quaisquer nomes de host desconhecidos serão encaminhados a ele. Em outras palavras, não há nada para ver aqui.
TL;DR: O problema de rede foi causado pela execução manual
dockerdno WSL. Usandoip addressno mesmo terminal etcpdumpproporcionou maior clareza.Detalhes
As coisas ficaram claras o suficiente, então estou compartilhando minhas etapas de solução de problemas, pelo que vale a pena. A resposta aceita está absolutamente correta, o ping vinha de 192.168.1.17. Eu tinha um terminal do Windows aberto e estava pensando no IP de origem da guia Powershell, mesmo que eu estivesse executando o ping na guia Ubuntu WSL, então esse foi o meu erro. Se eu fizer
ip ano terminal WSL, posso ver uma entrada interessante:Observe o mistério 192.168.1.17 . Eu provavelmente já vi isso antes, mas ignorei porque a interface estava inativa e todo o ruído de todas as outras interfaces. Na verdade, eu tenho o docker instalado no WSL (com o apt, não a versão do Windows) e não tenho certeza de como ele está interagindo com a rede, mas parece ter dado o salto aparente. Quanto ao nome do host exibido ao lado do dot17, agora vi nomes diferentes mostrados, então é claramente algum nome em cache que deve ser ignorado porque é enganoso.
É mais fácil ver a operação em um arquivo PCAP no Wireshark, que capturei com:
O primeiro pacote:
E dentro do ICMP:
Portanto, não há salto extra. Também notei que poderia pingar o destino na guia Powershell, mas não na guia WSL. Então eu reiniciei o WSL:
Agora, se eu fizer
ip ano shell WSL recém-iniciado, a última entrada será:A interface do docker desapareceu. Eu posso pingar do shell WSL novamente. Então me ocorreu: eu tinha iniciado o daemon docker manualmente com
sudo dockerd &, foi quando a conectividade quebrou! Outro ponto de interesse é que a VM está usando uma interface em ponte e, embora tenha seu próprio endereço IP e possa executar ping em todos os outros dispositivos da rede, ela não pode executar ping no IP da máquina host.A boa notícia é que agora tenho o docker em execução na VM e posso SSH a partir do WSL, ou melhor ainda, diretamente do PowerShell, e tudo funciona bem.