PPP CHAP 만으로 MPPE 요구 사항을 충족할 수 없는 이유

암호화를 고집하는 PPTP 프로필은 대개 같은 지점에서 실패합니다. PPP 가 MPPE 에 필요한 키 자료를 결코 생성하지 않는 인증 교환에 합의하는 것입니다. 터널은 반쯤 살아 있는 것처럼 보이고, 비밀번호는 받아들여지며, 어떤 트래픽도 지나가기 전에 링크가 끊깁니다. 무언가 연결될 때까지 CHAP 드롭다운에 손을 뻗는 것은 진짜 결함을 감춥니다. 그 결함은 인증 방식과 보호 정책 사이의 계약입니다. 아래 점검들은 각 항목이 다음보다 값싼 원인을 배제하도록 정렬되어 있습니다.

하나의 PPTP 연결 안에서 두 개의 협상이 진행됩니다

PPTP 는 GRE 터널 안에서 일반 PPP 세션을 나르며, 둘은 따로 협상합니다. 바깥 계층은 패킷이 어떻게 캡슐화되는지와 어떤 제어 채널이 있는지를 결정하고, 안쪽 PPP 세션은 누가 상대인지와 어떤 보호가 그 위에 얹히는지를 결정합니다. 따라서 비밀번호 프롬프트는 안쪽 계층에 대해서만 무언가를 증명하며, 완료된 바깥 핸드셰이크는 둘 중 어느 것에 대해서도 아무것도 증명하지 않습니다. 프로필이 여기서 실패하는 이유는 불일치가 PPP 안에 앉아 있는데 사람들이 터널을 디버깅하기 때문입니다.

일반 CHAP 은 RFC 1994 의 질의응답 교환으로, 공유 비밀 외에는 아무것도 기반으로 하지 않습니다. MS-CHAPv2 는 다른 메시지와 다른 출력을 가진 별개의 교환이며 RFC 2759 에 표준화되어 있습니다. 두 이름의 공통 단어는 전선 위에서 둘이 공유하는 유일한 것입니다. 어느 이름도 그 교환이 무엇을 생성하는지 말하지 않으며, 바로 그 부분만이 중요합니다.

그래서 단순히 CHAP 이라고 표시된 옵션은 오래된 프로필에서 모호합니다. 서버가 MS-CHAPv2 를 원하고 클라이언트가 일반 CHAP 을 제안하면, 링크 제어는 여전히 완료될 수 있고 비밀번호도 여전히 받아들여질 수 있습니다. 실패는 나중에, 서버가 아무것도 생성하지 않은 교환에서 보호 키를 끌어내려 할 때 찾아옵니다.

요구되는 방식을 그것이 생성할 수 있는 키에 맞추세요

MPPE 키는 일반적으로 PPP 의 속성이 아닙니다. Microsoft CHAP 계열의 경우 유도 방식이 RFC 3079 에 명시되어 있으며, 공유 비밀이 아니라 MS-CHAP 교환의 출력을 입력으로 받습니다. EAP 방식은 다른 경로로 같은 지점에 도달하며, 인증 서버가 키를 MS-MPPE-Recv-Key 와 MS-MPPE-Send-Key 속성으로 돌려줍니다. 일반 CHAP 은 두 경로 어디에도 나타나지 않으며, 그것이 이 불일치가 존재하는 전부의 이유입니다.

키를 공급할 수 있는 모든 방식을 거부하면서 MPPE 를 요구하는 구성은 내적으로 모순됩니다. pppd 는 그 모순을 키를 지어내는 대신 링크를 거부함으로써 해결하므로, 눈에 보이는 결과는 인증은 통과하지만 네트워크 단계에서 종료되는 세션입니다. 서버가 무언가를 유도하는 유일한 방식들을 거부하는 한 클라이언트를 다시 시도해도 바뀌지 않습니다.

따라오는 규칙은 짧습니다. 프로필이 MPPE 를 요구하면 방식은 MS-CHAP 변형이거나 서버가 키를 돌려주는 EAP 방식이어야 합니다. MS-CHAPv2 만 거부하는 것으로는 그것이 강제되지 않습니다. MS-CHAPv1 도 키를 유도하며 따로 거부하지 않는 한 사용 가능하게 남기 때문입니다. 둘 다 거부하면 일반 CHAP 과 PAP 이 남고, 이들은 아무것도 유도하지 않아 요구 사항을 채울 수 없게 만듭니다. 싫어하는 방식을 나열하는 대신 허용되는 방식을 명시하고, 클라이언트를 연결시키려고 암호화 요구를 떨어뜨리는 것은 수리가 아니라 격하임을 기억하세요.

클라이언트를 편집하기 전에 서버의 옵션을 읽으세요

이 불일치의 대부분은 서버의 두 파일에서 보이며, 그것을 읽는 편이 클라이언트를 다시 만드는 것보다 쌉니다. Linux PPTP 엔드포인트에서는 관련 설정이 pptpd 가 넘기는 pppd 옵션 파일에 있습니다. 클라이언트 상태 화면이 아니라 서버에서 실행하세요. 보호 모드를 요구하거나 거부하거나 이름 붙이는 줄부터 시작합니다:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

출력을 플래그 목록이 아니라 계약으로 읽으세요. MPPE 를 요구하면서 MS-CHAP 의 두 변형을 모두 거부하는 줄은 어떤 클라이언트도 만족할 수 없고, MS-CHAP 방식에 대한 요구가 빠져 있으면 키를 주지 않는 교환에 문이 열린 채로 남습니다. 그다음 누가 인증할 수 있는지를 확인하세요. 이는 비밀 파일이 결정합니다:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

무엇이든 바꾸기 전에 세 가지 값을 적으세요. 바깥 프로토콜, 서버가 요구하는 인증 방식, 보호가 필수인지 선택인지입니다. 이 세 가지가 이후의 모든 결정을 좌우하며, 클라이언트 대화상자에서 그것을 짐작하는 것이 프로필을 반쯤 구성된 상태로 남기는 길입니다. 다음 절이 같은 세 값을 필요로 하므로 작업하는 동안 파일을 열어 두세요.

PPP 단계로 실패를 찾으세요

PPP 는 실패를 단계별로 보고하며, 그 단계가 계약의 어느 조항이 깨졌는지 알려 줍니다. 링크 제어를 한 번도 벗어나지 않는 링크는 캡슐화나 협상 문제를 안고 있고, 인증은 통과하지만 그 뒤 죽는 링크는 대개 정책이나 키 문제를 안고 있습니다. 올라간 채로 아무것도 나르지 않는 링크는 라우팅으로 넘어간 것이며, 그것은 다른 조사입니다.

저널은 단계 줄을 보관하며, 그 줄들은 더 높은 디버그 수준보다 유용합니다. PPP 프로세스와 보호 메시지를 요청하고, 그다음 무엇보다 먼저 인증 결과를 읽으세요. 마지막 줄들은 보통 거부한 조항을 지목합니다:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

그 출력에서 먼저 인증 결과를 찾고, 다음으로 보호가 요구되었지만 협상되지 않았다는 불평을 찾으세요. 두 번째 메시지가 위 모순의 서명이며, 서버가 키를 생성할 수 있는 유일한 방식을 거부하는 한 아무리 다시 시도해도 그것을 지우지 못합니다. 두 함정을 지목할 만합니다. 단계 줄을 읽지 않고 디버그 수준을 올리면 잡음이 생기고, 질의 자료나 비밀번호를 캡처하면 구성 작업이 자격 증명 유출로 바뀝니다. 어떤 옵션이든 바꾸기 전에 그 단계를 기록하세요.

옛 엔드포인트를 끄기 전에 출구를 계획하세요

MPPE 는 역사적인 링크 보호 메커니즘이며, 그 존재가 PPTP 를 새 배포에 합당한 선택으로 만들지는 않습니다. 현재 Microsoft 지침은 이미 새 원격 접속 배포에 대해 PPTP 와 사전 공유 키를 쓰는 L2TP/IPsec 을 권하지 않습니다. 옛 엔드포인트를 살려 두는 것은 기존 서비스에 대한 결정이며, 다음을 위한 템플릿이 아닙니다.

엔드포인트가 남아야 한다면 계약을 적으세요. 바깥 프로토콜, 요구되는 인증 방식, 필수 보호, 그리고 그것을 협상하는 클라이언트 버전입니다. 떠날 수 있다면 옛 프로필을 건드리기 전에 대체 게이트웨이의 신원, 그 클라이언트 인증, 자격 증명이 살 곳을 고르세요. 그다음 경로, DNS, 각 사용자가 접근 권한을 가진 자원을 계획하세요. 의도한 클라이언트는 동작하는 연결이 아니라 소유자의 요구 사항에 비추어 검증하세요.

의도적인 거부는 거부로 남아야 합니다. 시험을 통과시키려고 무보호 모드로 되돌아가면 정책 실패가 노출로 바뀌기 때문입니다. 완성된 상태는 지원되고 문서화된 계약이며, 옛 연결 하나를 성공시키는 최소한의 변경 집합이 아닙니다. 대체가 같은 점검을 통과할 때까지 옛 프로필을 제자리에, 쓰지 않고 문서화된 채로 두세요.