Fallou a retirada do paquete VPN en prerm: que comprobar primeiro

As desinstalacións poden deter a medio camiño cun erro que nomea un script de mantemento, deixando a VPN medio retirada: os ficheiros de configuración permanecen, o servizo pode seguir en execución, e o xestor de paquetes négase a continuar. A solución tentadora dun fío antigo do foro é borrar o script e forzar a retirada. Iso trata o síntoma e descarta o paso de limpeza que fallou. Lea primeiro a etapa e o estado do paquete.

Que paso do ciclo de vida fallou realmente

Os paquetes Debian executan preinst e postinst na instalación, e prerm e postrm na retirada ou na purga, e o estado de saída de cada script determina a acción seguinte. Un erro de prerm significa que a retirada se detivo antes de borrar os ficheiros do paquete; un erro de postrm significa que a retirada xa ocorrera e que a limpeza fallou. Son situacións distintas con recuperacións distintas. A política da distribución tamén espera que os scripts toleren unha execución repetida, porque unha etapa fallida debe reintentarse en lugar de evitarse.

Anote o primeiro erro textualmente, xunto co nome do paquete, a versión e a versión da distribución. Os erros posteriores adoitan ser consecuencias.

Lea o estado do paquete antes de cambialo

Pregunte ao xestor de paquetes que cre que ocorreu antes de emitir outra orde.

dpkg -l vpn-package
dpkg --audit
apt-get -s remove vpn-package

A listaxe mostra os indicadores de estado do paquete, a auditoría atopa paquetes deixados rotos ou medio configurados, e a retirada simulada imprime o que faría apt sen tocar nada. Unha simulación que falla no mesmo script confirma a etapa, non a rede. Anote o script nomeado no erro e liste os ficheiros de información do paquete se precisa ver que scripts existen. Nada diso xustifica aínda editar eses ficheiros.

Protexa a vía de xestión antes da reparación

Se a VPN transporta a súa única sesión SSH cara a este host, retirala remata o seu acceso a medio da reparación. Dispoña primeiro dunha consola, dunha interface de xestión fóra de banda ou dunha segunda ruta, e confirme que funciona antes de comezar. Conserve o perfil e calquera instrución de rexistro novo que necesitará despois, porque unha purga pode eliminar configuración xerada. Manteña as credenciais fóra das notas que pega nun ticket, e manteña as claves privadas completamente fóra do diagnóstico.

Trate unha anulación manual documentada como último recurso baixo a guía do propietario do paquete, cos pasos omitidos contabilizados. Nunca borre scripts con comodíns, porque a propia lista de limpeza do paquete é o rexistro do que aínda queda por facer.

Separe os resultados de paquete, rede e credenciais

Cómpre comprobar tres resultados de forma independente cando remata o procedemento admitido. A transacción do paquete debe amosar un estado limpo, sen entradas medio configuradas que queden na auditoría. A rede debe coincidir co que pretendía: o servizo correcto detido, ningunha ruta nin axuste de DNS obsoleto, e unha vía funcional para a substitución ou o acceso directo. O lado remoto é o terceiro resultado, e as credenciais obsoletas deben retirarse a través do propietario desa conta, porque desinstalar un cliente non revoga nada.

Despois reconecte e probe un destino permitido. Un estado de paquete limpo cun túnel aínda en execución é un resultado distinto dunha rede limpa, e só o segundo lle di que a retirada tivo efecto de verdade.