pppd 바이너리를 찾을 수 없음: 인증이 아니라 실행 환경을 고치세요

클라이언트가 먼저 필요한 바이너리를 찾지 못했기 때문에 게이트웨이에는 아무것도 도달하지 않았습니다. 메시지는 실행 환경의 도우미를 언급하고, 자연스러운 반응은 상대편이 무언가를 거부했다고 가정하는 것입니다. 거부하지 않았습니다. PPP 기반 통합은 그 도우미를 로컬 머신에 필요로 하며, 그것이 없거나, 읽을 수 없거나, 호출자가 보는 곳에 없습니다.

메뉴와 데몬은 다른 것입니다

데스크톱 편집기는 저장은 기능이 아니라 필드를 검증하기 때문에, 그것을 설정할 도우미가 없더라도 프로필을 저장할 수 있습니다. 두 구성 요소는 다른 패키지로 배포되고 다른 시점에 실패합니다. 깔끔하게 저장되는 프로필과 즉시 실패하는 연결은 완전히 일관됩니다.

반대의 실수도 흔합니다: 디스크 어딘가의 실행 파일이 선택한 통합이 지원되는 사본을 찾는다는 증거는 아닙니다. 홈 디렉터리의 사본은 셸을 만족시키면서도 서비스에는 보이지 않을 수 있습니다.

파일이 아니라 패키지를 읽으세요

무엇이든 건드리기 전에 설치된 패키지의 상태, 선언된 의존성, 예상 파일 목록을 확인하세요. 배포판 패키징은 이를 명시적으로 문서화하며, Debian의 NetworkManager PPTP 패키지는 PPP 데몬 패키지와 PPTP 클라이언트에 각각 별도로 의존하기 때문에 유용한 예입니다. 이것은 오늘 PPTP를 배포하라는 권고가 아니라 오래된 통합입니다. 도우미가 클라이언트 안이 아니라 자체 의존성으로 도착하는 방식을 보여 줍니다.

세 가지 실패 방식을 구분하세요: 설치되지 않은 패키지, 후보를 제공하지 않는 저장소, 패키지 소유권 밖에서 수동으로 설치한 바이너리입니다. 각각 다른 수리가 필요하며, 같은 패키지를 다시 설치해 고쳐지는 것은 첫 번째뿐입니다.

셸에서 실행 파일을 확인하는 것은 그 셸의 검색 경로만 설명할 뿐 그 이상이 아닙니다. 관리자의 도우미는 다른 경로, 다른 환경, 또는 명시적으로 구성된 실행 파일 위치에서 실행될 수 있습니다.

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

다른 것을 깨지 않고 실행 환경을 고치세요

실행 환경이 명백히 불완전할 때는 배포판의 검토된 패키지 트랜잭션을 사용하고 무엇이 바뀔지 먼저 읽으세요. PPP는 여러 액세스 네트워크 통합이 공유하므로 제거하거나 다시 설치하면 작동 중인 사용자를 함께 데려갈 수 있습니다. 하나를 고치려고 관련 패키지를 모두 지우는 것이 노트북이 작동하는 연결 두 개를 잃는 방식입니다.

다른 VPN 클라이언트를 설치하는 것도 수리가 아닙니다. 새로운 호환성 요구를 만들면서 원래 프로필은 설명되지 않은 채로 둡니다.

조직이 프로토콜 자체를 없애기로 결정했다면 그것은 소유자가 있는 마이그레이션 결정입니다. 문제 해결 단계가 아니며, 연결이 실패하는 순간에 내려야 할 결정이 아닙니다.

다음 오류를 새 단계로 다루세요

도우미가 시작되면 다음 실패는 다를 것이라고 예상하세요. PPP 링크 협상, 사용자 인증, 주소 할당, 경로, 이름 확인은 각각 독립적으로 실패할 수 있고, 각각 고유한 증거가 있습니다.

나중의 거부에 의존성 수리를 되돌리거나 프로필의 모든 오래된 인증·압축 옵션을 켜서 응답하지 마세요. 그러면 진단 가능한 문제 하나가 상호 작용하는 여러 문제가 됩니다. 한 번에 설정 하나만 바꾸고 무엇이 바뀌었는지 기록하세요.

패키지 버전과 실제로 본 정확한 메시지를 기록하세요. 누락된 바이너리와 그것을 제공해야 할 패키지를 지목하는 보고서는 VPN에 대한 일반적인 불만에는 없는 실행 가능성을 가집니다.