Entre los requirimientos de Windows 11 están una CPU moderna, arranque EFI seguro y un dispositivo de seguridad TPM versión 2.0. A continuación os comentaré como lo instalé sin trucos en una máquina virtual dentro de una máquina que no tiene ni TPM ni arranque seguro EFI, así que el único requerimiento que cumplía era el tener una CPU algo moderna, con virtualización hardware, claro.

Para poder probar cosas con el Windows 11 en el trabajo he querido instalar Windows 11 como siempre hago con los Windows, es decir, en una máquina virtual dentro del sobremesa, hasta ahora siempre lo he hecho con VirtualBox, es cómodo y cumplía con lo que yo necesito.

Sin embargo en este caso, si queremos instalar Windows 11 sin trucos, necesitaremos un dispositivo de seguridad TPM, que no existe en VirtualBox, así que... he explorado un poco el mundo de libvirt usando por debajo KVM, que sí que nos permite usar un TPM software y el resto de cosas que necesita Windows 11 para funcionar.

He utilizado los paquetes de Bookworm (ahora en testing mientras no se convierte en la nueva estable) para contar con las últimas versiones y no tener que andar haciendo las cosas "a mano" editando los XML y tal, con las versiones de Bookworm se puede hacer todo en plan gráfico sin problema, con versiones anteriores igual también se puede, pero en algunas hay que tocar los XML a mano.

La cosa para mi ha sido instalar por un lado la parte de libvirt, instalé estos paquetes: virt-manager virt-viewer libvirt-daemon-driver-qemu libvirt-daemon-system libvirt-daemon-system-systemd libvirt-daemon-config-nwfilter libvirt-daemon-config-network libvirt-clients gir1.2-spiceclientgtk-3.0

Por otro lado para cumplir con los requerimientos del Windows 11 (TPM y arranque EFI) instalé: swtpm-tools ovmf

En algunas pruebas en alguna máquina muy "barebones" no tenía un polkit adecuado así que le instalé: lxpolkit Esto no será necesario en sistemas normales con interfaz gráfica ya que ya tendrán instalado un polkit, sino... el propio virt-manager os lo indicará con un error, sino... arrancarlo con "--debug"

Entre los requerimientos de Windows 11 están la CPU, que tiene que ser moderna y que el arranque sea EFI, por ello definiremos una nueva máquina en el virt-manager poniendo de arranque la ISO del Windows descargada de MS, dejaremos que detecte el operativo (detecta Windows 10, por ahora no tienen 11, pero nos sirve) y justo al final, antes de darle a finish, activaremos "Customize configuration before install" y ahí le ponemos en "overview" tendremos que cambiar el apartado "firmware" de BIOS a UEFI con arranque seguro (secboot), además iremos a la ventana "CPUs" y eligiremos en "Configuration" la opción "host-passthrough".

Si le dimos a "apply" en las opciones podemos volver a "overview" y comprobar en el xml que nos queda algo como esto:

machine=pc-q35-7.1 cpu mode='host-passthrough' ... firmware UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.secboot.fd

El otro requerimiento que tiene Windows 11 y que no suelen cumplir las máquinas menos modernas es el TPM, pero al ser una máquina virtual usamos el TPM software que hemos instalado y listo. Para esto añadimos a la máquina un dispositivo nuevo de tipo TPM y modelo TIS, y listo, ya podemos darle a "Begin installation".

Esta configuración de máquina es con la tarjeta gráfica qxl, cuando terminemos la instalación de Windows será conveniente instalar en el Windows 11 las spice guest tools que podemos descargar de spice-space.org para tener un buen soporte del esta y el resto del hardware.

Una vez instalemos eso apagamos la máquina y en el virtual-manager en la ventana de la máquina virtual Windows 11, seleccionamos "view", "scale display" y marcamos "autoresize vm with window"

Listo, con esto Windows debería reconocer todo el hardware y hacer escalado de la pantalla al tamaño de nuestra ventana.

La situación actual nos ha llevado a muchos a trabajar en remoto, algo para lo que hay muchas opciones, hablemos de alguna de ellas.

SSH

Es el sistema de acceso remoto por excelencia, lo usamos todos desde siempre, o al menos desde que la seguridad en la red importa, aunque no siempre fuera así, los ancianos del lugar usábamos el telnet, pero mejor no hablar de temeridades, no? ;-)

El secure shell como su propio nombre indica está diseñado para acceder a un shell, es decir, para acceso remoto a un entorno modo texto, pero como ya sabréis permite hacer túneles de todo tipo, desde puertos hasta forwarding de clientes X.

Si bien el SSH nos permite acceder a nuestros clientes X y traerlos hasta el servidor local de nuestro ordenador en casa, resulta que las X no están diseñadas para que el cliente y el servidor estén separados por las latencias de una wan por medio, por lo que aunque tengamos 1 giga de ancho de banda, nuestras aplicaciones X en remoto irán muy lentas, por eso... veamos que podemos utilizar para la parte gráfica...

x2go

Seguro que es el sistema más currado y más complejo para acceso remoto, soporta no sólo Linux, pero... si lo probáis veréis que hace muchas cosas por su cuenta sin contárnoslas, así que uno no deja de preguntarse... ¿para qué es todo esto? Lo tenemos soportado en Debian con paquetes tanto para hacer de servidor como para cliente, aunque ya os digo que a mi me pareció demasiado complejo y poco transparente.

Sin embargo si miramos debajo del capó vemos que utiliza la tecnología de NX que me parece más sencilla y entendible.

NX

Se trata de una tecnología que nos permitirá la utilización de aplicaciones nativas X tal cual, se basa en la proxificación de los clientes X de modo que los eventos no tengan tanta latencia y por lo tanto todo vaya mucho más fluido. Además añadiremos un servidor X en el lado remoto que nos permitirá tener una mejor respuesta y sesiones permanentes.

Su uso es sencillo, veamos un ejemplo, la idea es que accedemos al sistema remoto via ssh -L 4008:localhost:4008 host.remoto (forwardeamos el puerto 4008 que usaremos para el proxy de NX que correremos con :8 o sea usando el puerto 4008) y allí ejecutamos un proxy al que nos conectamos desde localhost a través de este puerto que hemos forwardeado. Esa es la parte de proxificado, pero vamos a añadir el agente que lo que hace es añadir un servidor X local sobre que lanzaremos las aplicaciones X y que nos dará también una sesión permanente que nos permite desconectarnos y conectarnos cuando queramos, veamos esto:

Remoto: nxproxy -C :8 & Local: nxproxy -S localhost:8 & Remoto: nxagent -display nx/:8 -geometry 1276x976 :9 & DISPLAY=:9 startlxqt

En el ejemplo arrancamos el lxqt, pero se puede arrancar lo que sea. Esta sesión sera permanente, ya que como dijimos estamos arrancando un servidor X en el equipo remoto, en este caso el DISPLAY será :9, contra el que irán las aplicaciones X. Aunque apaguemos el equipo local, se corten las comunicaciones o lo que sea, podremos reconectar. Para esto sólo hay que rearrancar las partes del proxy remoto y local y luego avisar al nxagent de que queremos que nos vuelva a mandar el display utilizando por ejemplo:

killall nxagent -HUP

VNC

Que decir de VNC, ha estado ahí desde hace muchos años.

Tenemos el servidor al estilo windows, en el paquete x11vnc que podemos arrancar así: x11vnc -rfbport 5900 -bg -o %HOME/.vnc/x11vnc.log.%VNCDISPLAY -rfbauth ~/.vnc/passwd -display :0 o el tigervnc-scraping-server que al igual que el anterior nos permitirá acceder vía cliente VNC a unas X que estén corriendo, aunque ahora tenemos también la extensión de X tigervnc-xorg-extension que nos dará la misma funcionalidad pero de una manera mucho más eficiente. Estos están bien para ver lo que hay en ejecución en la pantalla de un equipo y por ejemplo ofrecer ayuda remota.

Además tenemos el tigervnc-standalone-server y el tightvncserver que lo que nos permiten es tener todas las sesiones X que queramos (ya que no van atadas a nuestra gráfica ni nada) y accederlas en remoto vía VNC, y por supuesto varios clientes específicos de vnc como tigervnc-viewer y xtightvncviewer además de otros que soportan VNC y otros protocolos.

El handicap de siempre del VNC es que todo va en claro, nada va cifrado, así que necesita sí o sí de SSH o similar para cifrar los datos.

RDP

Este protocolo diseñado por Microsoft tiene ahora tanto servidores como clientes para Linux, requiere mucho menos ancho de banda que VNC y soporta diversos tipos de cifrado, tanto cifrado propio como incluso una capa de TLS.

Al igual que en el caso de VNC tenemos también servidores para acceso a un servidor X ya existente, como el freerdp-shadow-cli en el paquete freerdp2-shadow-x11. Lo podemos lanzar con esta orden para acceder a las X corriendo en :0:

DISPLAY=:0 freerdp-shadow-cli /port:12345

Ya sabéis, como en el caso del VNC, es muy útil para ayuda remota. Si bien es conveniente tener en cuenta este bug ya que hace que nofuncione la autenticación mientras que no lo arreglemos, así que o bien recompilamos o bien añadimos el parámetro -auth, pero entonces cualquiera que tenga acceso al puerto podrá tomar control de la sesión X.

También tenemos clientes como el clásico rdesktop o el xfreerdp del paquete freerdp2-x11 y otros clientes que soportan VNC, RDP y más, como vinagre, de GNOME o remmina.

Pero si lo que queremos es un acceso remoto a un entorno de trabajo Linux persistente tendremos que fijarnos en xrdp, todo un servidor rdp para dar acceso a tantas sesiones de escritorios Linux como queramos, estas sesiones serán permanentes y podremos conectarnos y desconectarnos de las mismas cuando queramos, además soporta sonido, aunque eso requerirá que compilemos los módulos siguiendo estas instrucciones, la reproducción de sonido es estándar, por lo que funcionará en cualquier cliente, pero si queremos mandar nuestro micro al server deberemos utilizar por ejemplo el paquete de rdesktop de buster (lo he probado y funciona) o algún otro compatible, ya que han hecho una implementación no estándar :-(

No voy a hablar de más protocolos (que los hay) pero si quería hablar de algo que me parece muy interesante, un potente cliente web de todos estos protocolos y más...

Guacamole

Esto si que no lo tenemos en Debian, aunque hubo algún intento de paquetización antiguo y probablemente os podáis encontrar todavía por ahí los paquetes viejos, no os los aconsejo porque tienen varios bugs de seguridad. Este cliente es bastante complejo, con diversas partes, basado en java, requiere al menos un tomcat para mover el servidor, ... pero a cambio tendremos acceso a servidores RDP, VNC, ssh, ... con seguridad de dos factores en varios estilos y colores y el cliente no necesitará nada más que un navegador web, algo que nos puede aligerar los requisitos para los trabajadores que tengan que acceder en remoto.

Bueno, eso es todo lo que se ocurre ahora mismo, podéis sugerir otras ideas en los comentarios.

Saludos.