PPTP가 비밀번호가 틀렸다고 할 때: 어느 수정을 먼저 할까

비밀번호가 틀렸다고 주장하는 PPTP 프로필은 들리는 것보다 좁은 이야기를 하고 있다. 시크릿은 기능 협상으로 시작하는 사슬의 맨 끝에서 검사되므로, 그 사슬 앞쪽의 어떤 불일치든 인증 실패로 드러난다. 그래서 비밀번호를 재설정하거나 다시 입력하거나 프로필을 다시 만들어도 아무것도 바뀌지 않는다. 먼저 협상을 읽고, 경로를 얼마나 통제하는지에 따라 수정을 고른다.

시크릿이 절대 검사되지 않는 이유

PPP 인증은 서버가 방식을 제안하고 클라이언트가 할 수 있는 것으로 응답하며 자격 증명이 오가기 전에 양쪽이 하나로 합의하는 협상이다. 서버가 EAP-PEAP만 제안하는데 클라이언트의 pppd가 이를 구현하지 않으면 대화는 제안 단계에서 끝난다. 서버가 인증 실패를 기록하는 것은 실패한 단계가 바로 그 단계이기 때문이며, 비밀번호를 비교해 부족하다고 판정했기 때문이 아니다.

그래서 잘못된 비밀번호와 방식 불일치에서 오류가 똑같다. 로그만이 둘을 구별하며, 그것도 클라이언트가 상세 출력을 허용받을 때뿐이다.

마지막 오류가 아니라 협상을 읽어라

디버깅을 켠 채 연결을 포그라운드에서 실행하고 인증 줄을 위에서부터 읽는다. 로그에는 제안된 방식, 수락된 방식, 교환이 멈춘 지점이 적혀 있다. 서버가 PEAP를 기대하는데 프로필이 CHAP나 MSCHAPv2를 벗어나지 않는다면 이는 방식 문제이지 자격 증명 문제가 아니다. 그 로그의 마지막 줄은 클라이언트가 포기한 지점이지 원인이 있는 곳이 아니다.

sudo pppd call provider debug nodetach

그 출력을 보관하라. 서버 정책을 바꾸기 전에 네트워크 소유자에게 필요한 증거이기도 하고, 비밀번호가 애초에 관여했는지에 대한 질문도 정리해 준다.

두 번째 원인은 시크릿 파일에 숨어 있다

로그에서 방식이 일치한다면 시크릿을 저장하는 파일을 보라. 비밀번호 필드에 적힌 개행이나 끝의 공백은 비밀번호의 일부로 전송되므로 서버는 입력한 것과 다른 문자열을 비교한다. 편집기에서는 파일이 올바로 보이며, 바로 그래서 이 문제는 수많은 재시도에도 살아남는다.

sudo cat -A /etc/ppp/chap-secrets

그 출력에서 각 줄의 끝은 달러 기호로 표시된다. 그 기호 앞에 무언가가 있는 비밀번호 필드나 필드 사이에 끼어든 공백은 도구가 문서화한 인용 방식으로 다시 써야 한다.

서버 소유자가 누구인지에 따라 수정을 고른다

서버가 본인 것이라면,그 계정에 MSCHAPv2를 허용하는 것이 가장 작은 변경이며, 더 약한 방식을 의도적으로 받아들였다는 점을 기록해야 한다. 남의 것이라면 EAP-PEAP를 구현한 클라이언트가 정직한 수정이고, pppd를 패치하면 비호환이 본인의 유지보수 문제가 된다. 프로토콜 선택이 아직 열려 있다면 PPTP는 설계에서 가장 약한 부분이며, 패치한 클라이언트를 살려 두는 것보다 이전하는 편이 보통 더 싸다. 그 결정을 프로필 옆에 적어 다음 사람이 다시 꺼내지 않게 하라.

어느 길을 택하든, 나중에 다른 네트워크의 두 번째 머신에서 시험하라. 저장된 프로필이 예전 방식을 계속 제안해 고친 서버가 망가진 것처럼 보일 수 있다. 그다음에는 상세한 PPP 로그가 공용 워크스테이션에서 원치 않는 것까지 기록할 수 있으므로 디버그 설정을 제거하라.