El cambio de núcleo FIPS se llevó los módulos de Wi-Fi y VPN

Active fips-updates, reinicie y la máquina vuelve sin interfaz inalámbrica, mientras el cliente VPN se niega a arrancar porque le falta su módulo del núcleo. No se desinstaló nada en el sentido habitual de los paquetes, y por eso reinstalar el cliente no cambia absolutamente nada. La máquina ejecuta un núcleo para el que sus controladores nunca se compilaron. Dos síntomas, una causa, y la causa aparece en un solo comando.

Qué cambió realmente el reinicio

Las actualizaciones FIPS de Ubuntu Pro instalan una variante certificada del núcleo y la convierten en la entrada de arranque predeterminada. Esa variante es un núcleo real: arranca, funciona e inicia los servicios que ya tenía. Lo que no contiene es cada módulo compilado para el núcleo genérico, incluido un controlador inalámbrico compilado fuera del árbol y un módulo de túnel entregado mediante DKMS. El conjunto de controladores se mueve con el núcleo, no con el gestor de paquetes. Así que el hardware sigue ahí y el software que habla con él no.

Compare el núcleo en ejecución con los paquetes instalados antes de abrir cualquier ajuste de red. La cadena de versión lleva una marca que el núcleo genérico no tiene, y ese único detalle explica las dos piezas que faltan.

Lea también la entrada de arranque, porque una máquina puede tener el núcleo certificado instalado sin ejecutarlo. En ese caso la historia de los módulos es completamente distinta, y los puertos y controladores que estaba a punto de reinstalar están bien.

Lea el estado de los módulos antes de la configuración del cliente

Un módulo que no se encuentra y un módulo que existe pero se niega a cargarse son fallos distintos con soluciones distintas. modinfo indica cuál de los dos tiene, y lsmod indica qué está cargado ahora mismo. Haga las dos cosas antes de tocar la configuración del cliente VPN, porque el error propio del cliente rara vez los separa.

La parte inalámbrica necesita la misma división. Una interfaz que nunca aparece apunta al controlador, mientras que una que existe pero queda bloqueada apunta a rfkill o al gestor de red. Las dos se ven igual en un applet de escritorio y no comparten nada por debajo.

Ejecute las comprobaciones en la propia máquina mientras el fallo aún se puede reproducir. Una salida pegada desde otro equipo no sustituye a esta.

uname -r
pro status --all | grep -E 'fips|kernel'
modinfo wireguard 2>&1 | head -3
rfkill list

Cuando modinfo no encuentra el módulo en absoluto, reinstalar el paquete de espacio de usuario no ayudará, porque el espacio de usuario nunca fue la parte que faltaba. Esa observación ahorra una hora de trastear con paquetes y apunta directamente al núcleo.

Vuelva atrás en un orden que le deje un núcleo

Si FIPS se activó por error, la ruta de recuperación documentada desactiva el servicio, purga sus paquetes y después restaura el núcleo genérico. El orden no es cosmético. La purga se niega a continuar cuando no encuentra otro núcleo de Ubuntu, porque eliminar el único dejaría una máquina que no arranca. Esa comprobación es la diferencia entre una reversión y una reconstrucción. También es la razón por la que la secuencia falla cuando el núcleo genérico ya se había eliminado.

Ejecútelo mientras el núcleo genérico sigue instalado, acepte el aviso sobre eliminar un núcleo y reinicie después. Luego confirme que no queda ningún paquete FIPS en estado instalado y que el núcleo en ejecución es el que esperaba.

En un equipo remoto, organice primero el acceso por consola o fuera de banda. Eliminar un núcleo por SSH está bien hasta justo el reinicio que no vuelve.

dpkg -l | grep -E 'linux-image|fips'
sudo pro disable fips-updates --purge
sudo apt install --reinstall linux-generic
sudo reboot

Cuando la certificación es el requisito

Volver atrás es el movimiento equivocado cuando la certificación es contractual, porque entonces la máquina sale de la configuración que describe la auditoría. En ese caso el hueco de controladores es una cuestión de selección de hardware: elija un adaptador inalámbrico cuyo controlador venga con el núcleo certificado, acepte una máquina solo con cable o mueva el túnel a un componente que el núcleo certificado ya admita.

Compilar un módulo fuera del árbol dentro del núcleo certificado no es una solución neutra. Cambia lo que ejecuta el núcleo, y esa es precisamente la propiedad que describe la certificación.

Registre la decisión con el nombre del propietario al lado, porque la petición de simplemente hacer que el Wi-Fi funcione volverá dentro de unos meses con menos contexto. Una nota breve ahora evita la misma discusión más adelante.

Revise la pila por capas después del cambio

Después de la reversión o del cambio de hardware, verifique de abajo arriba en lugar de desde el cliente VPN hacia abajo. La interfaz tiene que existir, el enlace tiene que estar arriba, el resolutor tiene que funcionar, y solo entonces importa el túnel. Cada capa falla con su propio mensaje, y leerlos en orden mantiene el diagnóstico honesto.

El estado de DNS que sobra del arranque anterior es un falso positivo habitual, así que lea el resolutor antes de concluir que el túnel se rompió.

nmcli device status
ip -brief link
resolvectl status | head -12
systemctl --failed

Si el túnel sigue fallando cuando el núcleo ha vuelto, lea la etapa que falla en lugar de la línea de resumen del cliente. Un módulo que nunca se cargó, un certificado que el par rechazó y una credencial que el servidor rechazó son tres problemas separados, y un reinicio no los distinguirá por usted. Anote el nombre de la etapa en el ticket, y el siguiente ingeniero empezará donde usted lo dejó.