Não posso fornecer uma solução global para o seu problema, apenas uma parcial. Você pode adicionar isso à técnica de troca para ampliar seu leque de oportunidades.
Se o usuário executando a VM estiver conectado à sua LAN via wifi, você poderá identificá-lo por meio de um traceroute. O motivo é que você nos mostrou que a VM tem um IP na sua rede LAN, portanto, está em uma configuração em ponte . Por razões técnicas, as conexões Wi-Fi não podem ser conectadas, portanto, todos os hipervisores usam um truque interessante em vez de uma configuração de ponte real: eles empregam proxy_arp ; veja, por exemplo, esta entrada de blog do Bodhi Zazen para obter uma explicação de como isso funciona, para KVM e esta página. para VMWare .
Como há um PC respondendo às consultas ARP no lugar da VM, o traceroute identificará o nó antes da VM. Por exemplo, esta é a saída do meu traceroute de outro PC na minha LAN:
My traceroute [v0.85]
asusdb (0.0.0.0) Mon Jun 1 11:45:03 2015
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. rasal.z.lan 0.0% 1 6.0 6.0 6.0 6.0 0.0
2. FB.z.lan
rasal é a máquina host, FB é o convidado, estou emitindo isso a partir de um terceiro pc (asusdb).
No Windows, o comando apropriado é
tracert 10.0.0.131
No Linux, você pode fazer o mesmo com o utilitário muito conveniente mtr :
mtr 10.0.0.131
Isso complementa, em vez de substituir, a técnica de troca. Se o seu traceroute mostrar que não há saltos intermediários entre o PC e a VM, pelo menos você saberá que pode descartar todos os PCs LAN conectados via Wi-Fi, restringindo seu leque de possibilidades e tornando a técnica do switch uma possibilidade efetiva, se você possui um comutador gerenciado ou deseja desconectar os cabos do comutador, um por um.
Como alternativa, você pode fingir um problema técnico e desconectar todas as conexões Ethernet, forçando seus usuários a usar o Wi-Fi, até que o culpado morda a isca.