Nada chegou ao gateway, porque o cliente não encontrou um binário de que precisa primeiro. A mensagem nomeia um auxiliar do ambiente, e a reação natural é supor que o outro extremo recusou algo. Não recusou. Uma integração baseada em PPP precisa desse auxiliar na máquina local, e ele falta, é ilegível ou não está onde o chamador olha.

O menu e o daemon são coisas diferentes

Um editor de ambiente de trabalho pode guardar um perfil enquanto o auxiliar que o estabeleceria está ausente, porque guardar valida campos, não capacidades. Os dois componentes vêm em pacotes diferentes e falham em momentos diferentes. Um perfil que é guardado sem erros e uma ligação que falha imediatamente são totalmente coerentes.

O erro inverso é igualmente comum: um executável algures no disco não prova que a integração escolhida encontre a cópia suportada. Uma cópia no diretório pessoal pode satisfazer uma shell e continuar invisível ao serviço.

Leia o pacote, não o ficheiro

Inspecione o estado do pacote instalado, as suas dependências declaradas e a lista de ficheiros esperada antes de tocar em qualquer coisa. O empacotamento das distribuições documenta isto explicitamente, e o pacote NetworkManager PPTP do Debian é um exemplo útil, porque depende separadamente do pacote do daemon PPP e do cliente PPTP. É uma integração herdada, não uma recomendação para implantar PPTP hoje. Mostra como um auxiliar chega como dependência própria e não dentro do cliente.

Mantenha três modos de falha separados: um pacote que não foi instalado, um repositório que não oferece nenhum candidato e um binário instalado à mão fora da propriedade do pacote. Exigem reparações diferentes, e só o primeiro se resolve reinstalando o mesmo pacote.

A verificação do executável numa shell descreve apenas o caminho de procura dessa shell e nada mais. O auxiliar do gestor pode correr com outro caminho, noutro ambiente ou com uma localização de executável configurada explicitamente.

dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppd

Corrija o ambiente sem quebrar os outros

Quando o ambiente está comprovadamente incompleto, use a transação de pacotes revista da distribuição e leia primeiro o que ela vai mudar. O PPP é partilhado por várias integrações de redes de acesso, pelo que removê-lo ou reinstalá-lo pode levar consigo consumidores que funcionam. Purgar todos os pacotes relacionados para reparar um avariado é como um portátil perde duas ligações que funcionam.

Instalar outro cliente VPN também não é uma reparação. Cria um novo requisito de compatibilidade enquanto deixa o perfil original sem explicação.

Se a organização decidiu que o próprio protocolo deve desaparecer, isso é uma decisão de migração com um responsável. Não é um passo de resolução de problemas, e não deve ser tomada no momento em que uma ligação falha.

Trate o erro seguinte como uma nova etapa

Assim que o auxiliar arrancar, espere que a falha seguinte seja diferente. A negociação da ligação PPP, a autenticação do utilizador, a atribuição de endereços, as rotas e a resolução de nomes podem falhar cada uma de forma independente, e cada uma tem as suas provas.

Não responda a uma recusa posterior anulando a reparação da dependência nem ativando todas as opções antigas de autenticação e compressão no perfil. Isso transforma um problema diagnosticável em vários que interagem. Mude uma definição de cada vez e registe o que mudou.

Registe as versões dos pacotes e a mensagem exata que viu. Um relatório que nomeia o binário ausente e o pacote que o deveria fornecer é acionável de uma forma que uma queixa geral sobre a VPN não é.

Artigos relacionados