O cambio de núcleo FIPS levou consigo os módulos de Wi-Fi e VPN

Active fips-updates, reinicie e a máquina volve sen interface sen fíos, mentres o cliente VPN négase a arrincar porque lle falta o módulo do núcleo. Non se desinstalou nada no sentido habitual dos paquetes, e por iso reinstalar o cliente non cambia absolutamente nada. A máquina executa un núcleo para o que os seus controladores nunca se compilaron. Dous síntomas, unha causa, e a causa aparece nun só comando.

Que cambiou realmente o reinicio

As actualizacións FIPS de Ubuntu Pro instalan unha variante certificada do núcleo e convértena na entrada de arranque predeterminada. Esa variante é un núcleo real: arrinca, funciona e inicia os servizos que xa tiña. O que non contén é cada módulo compilado para o núcleo xenérico, incluído un controlador sen fíos compilado fóra da árbore e un módulo de túnel fornecido mediante DKMS. O conxunto de controladores móvese co núcleo, non co xestor de paquetes. Así que o hardware segue aí e o software que fala con el non.

Compare o núcleo en execución cos paquetes instalados antes de abrir calquera axuste de rede. A cadea de versión leva unha marca que o núcleo xenérico non ten, e ese único detalle explica as dúas pezas que faltan.

Lea tamén a entrada de arranque, porque unha máquina pode ter o núcleo certificado instalado sen executalo. Nese caso a historia dos módulos é completamente distinta, e os portos e controladores que estaba a piques de reinstalar están ben.

Lea o estado dos módulos antes da configuración do cliente

Un módulo que non se atopa e un módulo que existe pero négase a cargar son fallos distintos con solucións distintas. modinfo indica cal dos dous ten, e lsmod indica que está cargado agora mesmo. Faga as dúas cousas antes de tocar a configuración do cliente VPN, porque o erro propio do cliente raramente os separa.

A parte sen fíos necesita a mesma división. Unha interface que nunca aparece apunta ao controlador, mentres que unha que existe pero queda bloqueada apunta a rfkill ou ao xestor de rede. As dúas vense igual nun applet de escritorio e non comparten nada por baixo.

Execute as comprobacións na propia máquina mentres o fallo aínda se pode reproducir. Unha saída pegada desde outro equipo non substitúe esta.

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

Cando modinfo non atopa o módulo en absoluto, reinstalar o paquete de espazo de usuario non axudará, porque o espazo de usuario nunca foi a parte que faltaba. Esa observación aforra unha hora de manexo de paquetes e apunta directamente ao núcleo.

Volva atrás nunha orde que lle deixe un núcleo

Se FIPS se activou por erro, a ruta de recuperación documentada desactiva o servizo, purga os seus paquetes e despois restaura o núcleo xenérico. A orde non é cosmética. A purga négase a continuar cando non atopa outro núcleo de Ubuntu, porque eliminar o único deixaría unha máquina que non arrinca. Esa comprobación é a diferenza entre unha reversión e unha reconstrución. Tamén é a razón pola que a secuencia falla cando o núcleo xenérico xa se eliminara.

Execúteo mentres o núcleo xenérico segue instalado, acepte o aviso sobre eliminar un núcleo e reinicie despois. Logo confirme que non queda ningún paquete FIPS en estado instalado e que o núcleo en execución é o que esperaba.

Nun equipo remoto, organice primeiro o acceso por consola ou fóra de banda. Eliminar un núcleo por SSH está ben ata xusto o reinicio que non volve.

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

Cando a certificación é o requisito

Volver atrás é o movemento equivocado cando a certificación é contractual, porque entón a máquina sae da configuración que describe a auditoría. Nese caso o oco de controladores é unha cuestión de selección de hardware: escolla un adaptador sen fíos cuxo controlador veña co núcleo certificado, acepte unha máquina só con cable ou mova o túnel a un compoñente que o núcleo certificado xa admita.

Compilar un módulo fóra da árbore dentro do núcleo certificado non é unha solución neutra. Cambia o que executa o núcleo, e esa é precisamente a propiedade que describe a certificación.

Rexiste a decisión co nome do propietario ao lado, porque a petición de simplemente facer que o Wi-Fi funcione volverá dentro uns meses con menos contexto. Unha nota breve agora evita a mesma discusión máis adiante.

Revise a pila por capas despois do cambio

Despois da reversión ou do cambio de hardware, verifique de abaixo arriba en lugar de desde o cliente VPN cara abaixo. A interface ten que existir, a ligazón ten que estar arriba, o resolutor ten que funcionar, e só entón importa o túnel. Cada capa falla coa súa propia mensaxe, e lelas en orde mantén o diagnóstico honesto.

O estado de DNS que sobra do arranque anterior é un falso positivo habitual, así que lea o resolutor antes de concluír que o túnel se rompeu.

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

Se o túnel segue fallando cando o núcleo volveu, lea a etapa que falla en lugar da liña de resumo do cliente. Un módulo que nunca se cargou, un certificado que o par rexeitou e unha credencial que o servidor rexeitou son tres problemas separados, e un reinicio non os distinguirá por vostede. Anote o nome da etapa no tícket, e o seguinte enxeñeiro comezará onde vostede o deixou.