Cliente VPN desinstalado, mas o túnel ainda arranca no boot
Um cliente VPN removido pode deixar uma unidade systemd, um perfil guardado, um auxiliar e um repositório apt. Inventarie os quatro antes de limpar qualquer outra coisa.
A sua distribuição remove o pacote, o menu perde a entrada e o túnel continua a subir depois do próximo reinício. Um cliente VPN comercial deixa peças que o gestor de pacotes nunca rastreou, por isso uma remoção limpa não é o mesmo que uma máquina limpa. Quatro dessas peças explicam quase todas as ligações fantasma: uma unidade, um perfil de ligação, um auxiliar privilegiado e um repositório do fornecedor. Leia as quatro antes de eliminar qualquer coisa e depois remova cada uma através do componente que a possui.
O que o desinstalador nunca registou
Um gestor de pacotes remove os ficheiros que ele próprio anotou e nada mais. Não tem registo de um perfil de ligação criado pelo cliente em tempo de execução, de uma unidade ativada após a instalação, nem de um auxiliar que se registou enquanto corria com privilégios elevados. Cada uma dessas peças pertence a um subsistema diferente e cada uma pode sobreviver ao pacote um ou vários reinícios. Essa lacuna explica porque um túnel pode estar saudável enquanto o software que o produziu já não existe.
O resíduo tem sempre um dono, seja systemd, NetworkManager, a configuração do repositório ou uma entrada de arranque automático por utilizador. Localizar primeiro o dono é o que impede que uma limpeza acabe numa máquina meio configurada. Eliminar ficheiros diretamente costuma funcionar até o dono os regenerar, e é por isso que os comandos abaixo começam com consultas.
Quatro donos, primeiro só leitura
Comece com consultas em vez de eliminações e anote os nomes exatos que aparecem. Os fornecedores enviam frequentemente uma carga versionada ao lado de um metapacote, pelo que um produto pode aparecer com dois nomes. Um nome que surge nas duas listas é um único produto com dois donos, e ambos têm de ser removidos. O primeiro lote cobre pacotes e unidades, onde a maioria dos resíduos se torna visível.
dpkg -l | grep -i acmevpn
systemctl list-unit-files | grep -i acmevpn
systemctl list-units --type=service --state=running | grep -i acmevpn
O segundo lote cobre os dois componentes que mais sobrevivem a uma limpeza, ou seja, o perfil de ligação e o repositório do fornecedor. Leia a coluna UUID em vez do nome, porque os nomes duplicados são comuns e o comando de eliminação espera o identificador. A linha do repositório vale a pena ser lida mesmo que não o remova hoje, já que um anfitrião de fornecedor morto pode partir uma instalação não relacionada meses depois. Nenhuma das listas altera nada, e é exatamente por isso que são executadas primeiro.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
grep -ril acmevpn /etc/apt/sources.list.d/ /etc/apt/sources.list
Um processo ainda vivo após a limpeza é ou uma unidade ativa ou o filho de outro programa. Leia a tabela de processos e a sua cadeia de pais antes de culpar um serviço que já não existe. As entradas de arranque automático por utilizador precisam da mesma passagem, e só aparecem num shell de início de sessão novo, não numa sessão root.
Três verbos que não são intermutáveis
Parar termina a execução atual, desativar remove as ligações de arranque e mascarar aponta a unidade para /dev/null. Só o terceiro também bloqueia a ativação através de um socket, um temporizador ou uma dependência, o que o torna o mais forte dos três. A ordem importa enquanto ainda decide o que fazer com a máquina. Mascarar é o estado correto durante essa decisão, porque falha ruidosamente em vez de arrancar em silêncio no próximo boot.
Desmascare antes de reinstalar, ou o novo pacote parecerá avariado por um motivo que ninguém anotou. A mesma cautela aplica-se às diferenças de empacotamento: uma compilação entrega uma unidade que pode ser parada, enquanto outra não deixa qualquer serviço. Estabeleça que empacotamento tem antes de escolher um verbo, porque o caminho de limpeza difere entre eles.
Com curingas elimina-se o perfil errado
Elimine o perfil com o UUID que anotou e nunca com um curinga. O diretório de keyfile também contém todos os perfis Wi-Fi e Ethernet da máquina, por isso uma correspondência ampla remove coisas de que ainda precisa. Um keyfile eliminado à mão pode ser regenerado pela política que o possui, o que faz a eliminação parecer ineficaz.
nmcli connection delete uuid <uuid>
Exporte primeiro o gateway e a identidade se esse perfil for a única cópia que ainda tem, porque uma eliminação local não revoga nada no servidor. O repositório segue a mesma regra: remova o único ficheiro do fornecedor e o seu porta-chaves, atualize depois as listas de pacotes e repita a instalação que realmente queria. Deixar uma entrada de terceiros obsoleta pode fixar uma dependência antiga ou não responder de todo. Ambas as remoções são pequenas, e qualquer uma pode ser desfeita a partir da cópia que guardar.
O que ainda corre depois do reinício
Reinicie antes de declarar vitória e depois procure artefactos em vez da aplicação. Uma interface de túnel, uma rota dividida obsoleta e DNS por ligação deixados pelo cliente antigo precisam cada um do seu próprio comando. Os três podem sobreviver a uma limpeza que removeu todos os pacotes com sucesso.
ip link
ip route
resolvectl status
Abra também um shell de início de sessão novo, porque uma entrada de arranque automático só dispara aí. Depois leia /etc/NetworkManager/dispatcher.d/ à procura de um script que levanta uma ligação sempre que uma interface muda de estado, o que explica um túnel que regressa sem serviço por trás. Se algo ainda marcar para fora, siga o processo até ao seu pai em vez de eliminar ficheiros até o sintoma parar. Limpar a máquina e revogar a conta continuam a ser tarefas separadas, e só uma delas está terminada quando o reinício parece calmo.