Hittade inte pppd-binären: reparera körmiljön, inte autentiseringen

Ingenting nådde gatewayen, eftersom klienten inte hittade en binär som den behöver först. Meddelandet namnger en hjälpare i körmiljön, och den naturliga reaktionen är att anta att andra sidan avvisade något. Det gjorde den inte. En PPP-baserad integration behöver den hjälparen på den lokala maskinen, och den saknas, är oläsbar eller finns inte där anroparen tittar.

Menyn och daemonen är olika saker

En skrivbordsredigerare kan spara en profil medan hjälparen som skulle upprätta den saknas, eftersom sparande validerar fält, inte förmågor. De två komponenterna levereras i olika paket och misslyckas vid olika tidpunkter. En profil som sparas rent och en anslutning som misslyckas omedelbart är helt förenliga.

Det omvända felet är lika vanligt: en körbar fil någonstans på disken bevisar inte att den valda integrationen hittar den stödda kopian. En kopia i hemkatalogen kan tillfredsställa ett skal och ändå vara osynlig för tjänsten.

Läs paketet, inte filen

Inspektera det installerade paketets tillstånd, dess deklarerade beroenden och dess förväntade fillista innan du rör något. Distributionernas paketering dokumenterar detta uttryckligen, och Debians NetworkManager PPTP-paket är ett användbart exempel, eftersom det beror på PPP-daemonpaketet och på PPTP-klienten var för sig. Det är en äldre integration, inte en rekommendation att distribuera PPTP i dag. Den visar hur en hjälpare kommer som sitt eget beroende och inte inne i klienten.

Håll tre felmoder åtskilda: ett paket som inte installerades, ett arkiv som inte erbjuder någon kandidat, och en binär som installerats manuellt utanför paketets ägande. De behöver olika reparationer, och bara den första löses genom att installera om samma paket.

En skal-kontroll av den körbara filen beskriver bara det skalets sökväg och ingenting mer. Hanterarens hjälpare kan köra med en annan sökväg, i en annan miljö eller med en uttryckligen konfigurerad plats för den körbara filen.

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

Reparera körmiljön utan att förstöra andra

När körmiljön är bevisligen ofullständig, använd distributionens granskade pakettransaktion och läs först vad den kommer att ändra. PPP delas av flera åtkomstnätverksintegrationer, så borttagning eller ominstallation kan ta med sig fungerande användare. Att rensa alla relaterade paket för att reparera ett trasigt är hur en bärbar dator förlorar två fungerande anslutningar.

Att installera en annan VPN-klient är inte heller en reparation. Det skapar ett nytt kompatibilitetskrav medan den ursprungliga profilen lämnas oförklarad.

Om organisationen har beslutat att själva protokollet ska bort, är det ett migreringsbeslut med en ägare. Det är inte ett felsökningssteg, och det bör inte fattas i det ögonblick en anslutning misslyckas.

Behandla nästa fel som en ny fas

När hjälparen startar, förvänta dig att nästa fel är annorlunda. PPP-länkförhandling, användarautentisering, adressutdelning, rutter och namnmatchning kan var och en misslyckas oberoende, och var och en har sina egna bevis.

Svara inte på ett senare avslag genom att ångra beroendereparationen eller genom att slå på alla gamla autentiserings- och komprimeringsalternativ i profilen. Det gör ett diagnostiserbart problem till flera som samverkar. Ändra en inställning i taget och notera vad den ändrade.

Notera paketversionerna och det exakta meddelande du såg. En rapport som namnger den saknade binären och paketet som borde tillhandahålla den är handlingsbar på ett sätt som ett allmänt klagomål på VPN inte är.