Não posso fornecer uma solução global para o seu problema, apenas parcial. Você pode adicionar isso à técnica para ampliar seu leque de oportunidades.
Se o usuário que estiver executando a VM estiver conectado à sua LAN via Wi-Fi, 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, por isso está em uma configuração bridged . Por razões técnicas, conexões wi-fi não podem ser conectadas, portanto, todos os hipervisores usam um truque em vez de uma configuração de ponte real: eles empregam proxy_arp , veja por exemplo entrada do blog de Bodhi Zazen para uma explicação de como isso funciona, para o KVM e esta página do VMWare .
Como há um pc respondendo a 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 de um terceiro pc (asusdb).
No Windows, o comando adequado é
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 seu PC e a VM, então pelo menos você saberá que pode excluir todas as LANs conectadas via Wi-Fi, restringindo seu leque de possibilidades e fazendo a alternar > em> técnica uma possibilidade efetiva, se você tem um switch gerenciado ou você está disposto a desconectar os cabos no switch um por um.
Alternativamente, você pode falsificar um problema técnico e desconectar todas as conexões ethernet, forçando seus usuários a usar wifi, até que o culpado morda a isca.