A troca de kernel FIPS levou consigo os módulos de Wi-Fi e VPN

Ative fips-updates, reinicie, e a máquina volta sem interface sem fios enquanto o cliente VPN se recusa a arrancar porque falta o módulo do kernel. Não se desinstalou nada no sentido habitual dos pacotes, e é por isso que reinstalar o cliente não muda absolutamente nada. A máquina corre um kernel para o qual os seus controladores nunca foram compilados. Dois sintomas, uma causa, e a causa vê-se num único comando.

O que o reinício trocou realmente

As atualizações FIPS do Ubuntu Pro instalam uma variante certificada do kernel e tornam-na na entrada de arranque predefinida. Essa variante é um kernel verdadeiro: arranca, funciona e inicia os serviços que já tinha. O que não contém é cada módulo compilado para o kernel genérico, incluindo um controlador sem fios compilado fora da árvore e um módulo de túnel fornecido através do DKMS. O conjunto de controladores move-se com o kernel, não com o gestor de pacotes. Por isso o hardware continua lá e o software que fala com ele não.

Compare o kernel em execução com os pacotes instalados antes de abrir qualquer definição de rede. A cadeia de versão leva uma marca que o kernel genérico não tem, e esse único detalhe explica as duas peças em falta.

Leia também a entrada de arranque, porque uma máquina pode ter o kernel certificado instalado sem o executar. Nesse caso a história dos módulos é completamente diferente, e as portas e controladores que ia reinstalar estão bem.

Leia o estado dos módulos antes da configuração do cliente

Um módulo que não se encontra e um módulo que existe mas se recusa a carregar são falhas diferentes com correções diferentes. modinfo indica qual dos dois tem, e lsmod indica o que está carregado neste momento. Faça as duas coisas antes de tocar na configuração do cliente VPN, porque o erro do próprio cliente raramente os separa.

A parte sem fios precisa da mesma divisão. Uma interface que nunca aparece aponta para o controlador, enquanto uma que existe mas fica bloqueada aponta para rfkill ou para o gestor de rede. As duas parecem iguais numa applet de ambiente de trabalho e não partilham nada por baixo.

Execute as verificações na própria máquina enquanto a falha ainda é reproduzível. Uma saída colada de outro equipamento não substitui esta.

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

Quando modinfo não encontra o módulo de todo, reinstalar o pacote de espaço de utilizador não ajuda, porque o espaço de utilizador nunca foi a peça em falta. Essa observação poupa uma hora de mexidas em pacotes e aponta diretamente para o kernel.

Recue numa ordem que lhe deixe um kernel

Se o FIPS foi ativado por engano, o caminho de recuperação documentado desativa o serviço, remove os seus pacotes e depois restaura o kernel genérico. A ordem não é cosmética. A remoção recusa continuar quando não encontra outro kernel Ubuntu, porque remover o único deixaria uma máquina que não arranca. Essa verificação é a diferença entre um recuo e uma reconstrução. É também a razão pela qual a sequência falha quando o kernel genérico já tinha sido removido.

Execute-a enquanto o kernel genérico ainda está instalado, aceite o aviso sobre remover um kernel e reinicie depois. Em seguida confirme que não ficou nenhum pacote FIPS no estado instalado e que o kernel em execução é o que esperava.

Num equipamento remoto, trate primeiro do acesso por consola ou fora de banda. Remover um kernel por SSH está bem até exatamente ao reinício que não volta.

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

Quando a certificação é o requisito

Recuar é o movimento errado quando a certificação é contratual, porque a máquina sai então da configuração que a auditoria descreve. Nesse caso a lacuna de controladores é uma questão de escolha de hardware: escolha um adaptador sem fios cujo controlador venha com o kernel certificado, aceite uma máquina só com cabo, ou mude o túnel para um componente que o kernel certificado já suporte.

Compilar um módulo fora da árvore para dentro do kernel certificado não é uma solução neutra. Muda o que o kernel executa, e é precisamente essa propriedade que a certificação descreve.

Registe a decisão com o nome do proprietário ao lado, porque o pedido para simplesmente fazer o Wi-Fi funcionar volta dentro de alguns meses com menos contexto. Uma nota curta agora evita a mesma discussão mais tarde.

Verifique a pilha por camadas depois da alteração

Depois do recuo ou da alteração de hardware, verifique de baixo para cima em vez de do cliente VPN para baixo. A interface tem de existir, a ligação tem de estar ativa, o resolvedor tem de funcionar, e só então o túnel importa. Cada camada falha com a sua própria mensagem, e lê-las por ordem mantém o diagnóstico honesto.

Um estado de DNS sobrante do arranque anterior é um falso positivo comum, por isso leia o resolvedor antes de concluir que o túnel se estragou.

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

Se o túnel continuar a falhar quando o kernel voltar, leia a etapa que falha em vez da linha de resumo do cliente. Um módulo que nunca foi carregado, um certificado que o par rejeitou e uma credencial que o servidor recusou são três problemas separados, e um reinício não os distingue por si. Anote o nome da etapa no ticket, e o próximo engenheiro começa onde o utilizador parou.