pptpd의 GRE 쓰기 실패는 비밀번호 문제가 아니다

로그에 GRE 쓰기 실패가 보이면 첫 반응은 사용자의 비밀번호를 재설정하는 것이다. 그 반응은 거의 항상 틀렸다. 이 메시지들은 자격 증명 검사가 아니라 데이터 경로를 설명한다: 클라이언트가 인증에는 성공했지만 네트워크에 등록하는 단계에서 멈췄을 수 있다. 서로 다른 두 메시지는 서로 다른 두 결함을 가리키며, 어느 것도 새 비밀번호로 해결되지 않는다.

두 메시지, 두 가지 결함

읽기 실패는 GRE 패킷이 데몬에 도달하지 못하거나 들어오는 길에 버려진다는 뜻이다. 제어 연결은 완벽히 건강해 보여도 데이터 경로를 지나는 것은 아무것도 없을 수 있다. 인증만은 확실히 동작했다.

쓰기 실패는 보통 커널이나 클라이언트가 쓸 수 없는 무언가를 세션이 협상했다는 뜻이다. 제어 채널은 완료되었고, 그 교환에서 합의한 옵션은 엔드포인트가 실제로 할 수 있는 것과 맞지 않는다. 이것은 구성 불일치이며 인증 이벤트가 아니다.

무엇이든 바꾸기 전에 둘 중 어느 것이 나타나는지 읽어라. 둘은 서로 다른 계층으로 안내하며, 이를 하나의 증상으로 다루는 것이 같은 서버가 무관한 이유로 두 번 패치되는 까닭이다. 로그 한 줄이 무료로 얻는 유일한 진단이다.

프로토콜 47은 포트 47이 아니다

PPTP는 호출을 설정하는 데 TCP 1723을, 페이로드를 나르는 데 GRE를 쓴다. GRE는 포트 번호가 아니라 IP 프로토콜 47이므로, 포트 47을 여는 방화벽 규칙은 유용한 것을 아무것도 허용하지 않는다.

경로상의 라우터에는 PPTP 패스스루 기능이나 명시적 GRE 허용이 필요하다. 그것이 없으면 TCP 핸드셰이크는 끝나고 터널은 패킷을 전혀 나르지 않으며, 이는 위의 읽기 실패를 그대로 만든다. 방화벽의 포트 47 규칙은 이 프로토콜에서 가장 흔히 낭비되는 오후다.

어느 쪽이 트래픽을 버리는지 추측하는 대신 서버에서 양방향을 동시에 관찰하라: tcpdump -ni any port 1723 or proto gre.

1723이 호출 설정을 보여 주는데 GRE가 조용하다면 차단은 호스트 상류에 있다. GRE가 도착하는데도 데몬이 계속 실패한다면 문제는 국소적이며 옵션이 다음으로 볼 곳이다.

호스트가 실제로 전달하는 곳에서 GRE를 허용하라

GRE에 대한 forward 규칙을 넣는 것은 터널 트래픽을 전달하는 호스트에서 합리적인 시험이며 정책은 아니다. 한 프로토콜의 모든 것을 허용하는 시험 규칙은 진단이지 설계가 아니다. 무언가를 배울 만큼만 두고, 그다음 범위를 좁힌 규칙으로 바꿔라.

서버 자신에게 보내는 패킷에는 input 규칙을 추가하라(forward 체인이 그것들을 보지 못하기 때문이다). 그런 다음 연결 시도 전후로 규칙 카운터를 보면 패킷이 애초에 도착하는지 알 수 있다.

재부팅할 때마다 다시 실행하는 대신 배포판의 방화벽 서비스로 규칙을 영구화하라. nftables 호스트에서는 input 체인과 forward 체인 모두에서 ip protocol gre을 일치시켜라.

ppp_generic 모듈도 로드되었는지 확인하고, 연결 추적이 반환 방향을 버리는지 점검하라. 둘 다 방화벽 문제처럼 보이지만 아닌 결함을 만든다. 커널 모듈이 없으면 확인하기 전까지는 차단된 프로토콜과 똑같이 보인다.

옵션을 실제로 가진 클라이언트에 맞춰라

다른 보고서의 수정은 /etc/ppp/pptpd-options에 있으며, 그곳에서 레시피는 PAP, CHAP, MSCHAP을 거부하고 해당 require 줄을 주석 처리하며 상태 저장 MPPE를 유지한다. 그 레시피는 한 가지 클라이언트 조합을 위해 쓰였고, 눈먼 복사는 흔한 경우를 깨뜨린다. 거부 줄은 권장 사항이 아니라 작성자가 어떤 클라이언트를 가졌는지에 대한 진술로 읽어라.

Windows 클라이언트는 보통 MS-CHAPv2와 MPPE-128을 필요로 한다. 그 요구 사항은 유지하고 클라이언트가 정말 협상할 수 없는 옵션만 제거하라.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

연결을 성공시키려고 암호화를 끄는 것은 복구가 아니라 등급을 낮추는 일이다. 그런 변형은 실험실 회선에서 시험하고, 서비스가 실제 클라이언트를 만나기 전에 암호화를 되돌려라. 안전하지 않게 동작하는 연결은 정직하게 실패하는 연결보다 나쁘다.

클라이언트의 오류 번호를 읽어라

클라이언트의 숫자 코드는 서버 로그보다 빨리 단계를 좁힌다. 다른 무엇보다 먼저 그것을 읽어라. 691은 자격 증명이 거부되었다는 뜻이고, 721은 서버가 응답하지 않았다는 뜻이며, 619는 연결이 끊겼다는 뜻이다. 번호에 이 분을 쓰면 구성에 한 시간을 아낀다.

무엇이든 편집하기 전에 그 코드를 서버 로그와 비교하고, 변경할 때마다 같은 클라이언트로 다시 시험하라. 그렇지 않으면 두 번째 결함이 첫 번째 뒤에 숨어 수정이 효과 없어 보인다.

로그인이 성공하는데 트래픽이 움직이지 않으면 GRE가 여전히 용의자다. 그때는 자격 증명 저장소가 아니라 캡처로 돌아가야 한다.