PPTP 오류 800과 812, 그리고 1분 뒤 끊기는 연결

PPTP 클라이언트 하나에서 나오는 세 가지 오류 메시지는 보통 서로 다른 세 가지 결함을 설명합니다. 오류 800은 터널이 아예 만들어지지 않았다는 뜻이고, 오류 812는 서버가 인증 방식을 거부했다는 뜻이며, 일 분 뒤의 끊김은 정상적인 피어가 사라졌다고 판단하는 keepalive 타이머입니다. 각 단계는 저마다의 이유로 실패하므로 각 단계에 맞는 점검이 필요합니다.

오류 800은 터널이 아예 만들어지지 않았다는 뜻입니다

Windows는 터널을 전혀 만들 수 없을 때 오류 800을 띄우며, 서버에 닿을 수 없다거나 보안 매개변수가 부적합하다는 문구는 진단이 아니라 요약입니다. PPTP는 자격 증명을 검사하기 전에 네트워크에서 두 가지 별개의 것을 요구합니다. TCP 1723이 제어 채널을 나르고, IP 프로토콜 47, 즉 GRE가 캡슐화된 페이로드를 나릅니다.

그 외부 경로는 자신의 LAN 바깥에서 시험하세요, 사무실 안에서 동작하는 연결은 가장자리에 대해 아무것도 증명하지 못하기 때문입니다:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

1723이 응답하는데 클라이언트가 접속을 시도하는 동안 캡처가 비어 있다면 경로가 프로토콜 47을 버리고 있는 것입니다. 1723은 전달하지만 PPTP 패스스루가 꺼져 있는 라우터는, TCP 핸드셰이크가 끝난 뒤 GRE 패킷이 사라져 로그인 시도조차 하지 않았는데 자격 증명 문제처럼 보이는 패턴을 만듭니다.

포워딩을 서버의 현재 LAN 주소로 돌리고, 라우터가 제공하는 곳에서 PPTP 패스스루를 켠 뒤 같은 외부 지점에서 다시 시도하세요. GRE가 상류에서 필터링되어 바꿀 수 없다면 TCP 443 위의 SSTP나 UDP 500 및 4500 위의 L2TP/IPsec이 Windows 쪽에서 할 수 있는 어떤 변경보다 나은 가능성을 가집니다.

오류 812는 서버가 인증 방식을 거부하는 것입니다

오류 812는 터널이 올라온 뒤에 돌아오므로 비밀번호 문제처럼 느껴집니다. 서버는 연결을 위해 협상된 인증 방식을 거부하는 것이지 반드시 비밀번호 자체를 거부하는 것은 아닙니다. 클라이언트에서 VPN 항목을 열고 보안 탭으로 가서 유형을 Point-to-Point Tunneling Protocol로 설정하고 명시적 프로토콜 목록을 고른 다음 Microsoft CHAP 버전 2를 선택하세요.

대화 상자를 클릭하지 않고도 현재 설정을 읽을 수 있습니다:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

MS-CHAP v2를 요구하는 서버는 PAP나 더 약한 것을 협상하는 자동 유형에 그대로 둔 클라이언트를 거부하며, 오류는 어떤 사용자 비밀번호도 평가되기 전에 도착합니다. 계정 형식은 같은 거부의 나머지 절반입니다. 한 사례에서 Windows는 서버가 로컬 또는 도메인 계정을 원했는데 MicrosoftAccount\[email protected] 형태의 Microsoft 계정 ID를 보냈습니다. SERVERNAME\username을 입력하자 Windows에 어느 계정 저장소를 조회할지 알려 주었고 오류가 사라졌습니다. 저장된 자격 증명이 이전 형식을 재생하도록 두지 말고 이름을 직접 입력하세요.

일 분 뒤의 끊김은 keepalive 결정입니다

터널이 연결되고 약간의 트래픽을 통과시킨 뒤 끊긴다면, 클라이언트를 건드리기 전에 서버의 LCP 에코 동작을 보세요. 데몬은 주기적으로 피어에게 아직 있는지 확인을 요청합니다. 설정된 예산 안에 응답이 너무 적게 도착하면 사용자에게 아직 작동하는 링크가 있어도 세션이 끊깁니다.

Linux pptpd 서버에서는 그 값들이 /etc/ppp/options.pptpd에 있으며, 보통의 수리는 간격을 줄이는 것이 아니라 예산을 넓히는 것입니다:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

다섯 초 간격에서 서른 번의 누락은 피어가 사라졌다고 선언하는 대신 짧은 멈춤을 용서합니다. 횟수를 하나나 둘로 줄이면 번역된 경로의 평범한 지터가 거의 일 분마다 연결 끊김이 됩니다. 서버가 pptpd이 아니라 Windows RRAS라면 대신 PPP 세션 시간 제한과 유휴 시 연결 끊기 정책을 보세요. 그것들은 다른 곳에 있으며, 존재하지 않는 pppd 파일을 편집해도 아무것도 바뀌지 않습니다.

중첩된 서브넷은 데이터 경로를 깨뜨립니다

양쪽 사이트가 같은 사설 범위를 쓸 때, 예를 들어 사무실과 집에서 192.168.1.0/24를 쓸 때 PPTP 터널은 깨끗하게 인증되고도 아무 데도 도달하지 못할 수 있습니다. 클라이언트는 주어진 주소가 어느 호스트를 가리키는지 알 수 없고, 일부 스택은 하나를 고르는 대신 경로를 아예 설치하지 않습니다.

그것을 설계 결함으로 보고 한쪽의 번호를 다시 매기거나, 클라이언트에 의도적으로 변환된 액세스 범위를 주세요. PPTP 클라이언트를 디버깅해도 두 번 존재하는 주소 공간은 고칠 수 없고, 증상은 무작위 끊김처럼 계속 보일 것입니다.

실패한 단계부터 시작하세요: 800에는 GRE, 812에는 방식과 계정 문자열, 일정대로 죽는 터널에는 에코 설정입니다.