No puedo proporcionar una solución global a su problema, solo parcial. Puede agregar esto a la técnica de cambio para ampliar su gama de oportunidades.
Si el usuario que ejecuta la VM está conectado a su LAN a través de wifi, puede identificarlo mediante un traceroute. La razón es que nos mostró que la VM tiene una IP en su red LAN, por lo tanto, está en una configuración puenteada . Por razones técnicas, las conexiones wifi no se pueden puentear, por lo tanto, todos los hipervisores usan un truco ordenado en lugar de una configuración de puente real: emplean proxy_arp , consulte, por ejemplo, la entrada del blog de Bodhi Zazen para obtener una explicación de cómo funciona esto, para KVM, y esta página para VMWare .
Como hay una PC que responde a las consultas ARP en lugar de la VM, traceroute identificará el nodo antes de la VM. Por ejemplo, esta es la salida de mi traceroute desde otra PC en mi 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 es la máquina host, FB es el invitado, estoy emitiendo esto desde una tercera PC (asusdb).
En Windows, el comando correcto es
tracert 10.0.0.131
En Linux, puede hacer lo mismo con la práctica utilidad mtr :
mtr 10.0.0.131
Esto complementa, en lugar de reemplazar, la técnica de cambio. Si su traceroute muestra que no hay saltos intermedios entre su PC y la VM, entonces al menos sabrá que puede descartar todas las PC LAN conectadas a través de wifi, restringiendo su rango de posibilidades y haciendo que la técnica de cambio sea una posibilidad efectiva, si tiene un conmutador administrado o está dispuesto a desconectar los cables en el conmutador uno por uno.
Alternativamente, puede fingir un problema técnico y desconectar todas las conexiones de Ethernet, obligando a sus usuarios a usar wifi, hasta que su culpable muerda el anzuelo.