PPTP 패스스루 없음: Windows VPN 오류 807 해결

TCP 1723을 전달하면 PPTP의 앞부분만 열리고 나머지는 깨진 채로 남기 때문에 Windows는 시도할 때 여전히 오류 807을 반환한다. 다음 본능은 포트 47에 대한 규칙을 추가하는 것이고, 바로 그 단계가 오후 하나를 낭비한다. GRE는 IP 헤더 안의 프로토콜 번호이며 전달 테이블이 대조할 수 있는 포트가 아니다. 라우터가 프로토콜 47을 통과시키고 그것을 같은 호출에 묶을 때까지 터널은 시작될 수 없다. 아래 절들은 두 채널을 분리한 뒤 하나씩 검증한다.

포트 테이블에는 프로토콜 번호를 위한 행이 없다

PPTP는 서로 다른 방식으로 실패하는 두 대화를 사용한다. TCP 1723의 대화는 호출을 시작하고 링크 정보를 전달하며 사용자가 연결을 끊으면 해제한다. 페이로드 쪽은 GRE 안에서 동작하는데, IP 헤더가 프로토콜 번호 47로 표시하며 그 터널 안에서 PPP가 링크를 협상하고 MS-CHAPv2가 자격 증명을 확인한다.

GRE는 전송 헤더를 갖지 않으므로 포트를 드러내지 않으며, 따라서 포트용으로 작성된 규칙에는 대조할 대상이 없다. 1723을 전달하는 라우터는 해당 TCP 세션의 매핑을 만들고 거기서 멈춘다. 뒷부분을 처리하는 펌웨어는 이 기능을 PPTP 패스스루 또는 PPTP ALG라고 부르고, 어떤 펌웨어는 둘 다 제공하지 않으면서 그 공백을 언급조차 하지 않는다. 체크박스의 이름보다 프로토콜 47이 애초에 인식되는지가 더 중요하다.

데이터 경로가 죽을 때 Windows가 보고하는 것

오류 807은 연결을 완료할 수 없었다고 말하며, 실제로는 호출이 서버에 도달했고 데이터 채널이 올라오지 않았다는 뜻이다. 이것은 전송에 대한 판정이며 계정에 대한 판정이 아니다. 자격 증명이나 인증 프로토콜의 불일치를 가리키는 것은 오류 691이므로 전혀 다른 곳으로 보낸다.

비밀번호를 건드리기 전에 전송 계층을 다뤄라. 807을 쫓아 자격 증명을 바꾸면 실제 결함은 그대로 남고 다음 시도는 읽기 더 어려워진다.

두 번째 클라이언트가 작동 중인 터널을 깨는 이유

이들을 구분할 포트가 없기 때문에 NAT 장치는 두 HTTPS 세션을 나누는 방식으로 두 PPTP 클라이언트를 나눌 수 없다. 그래서 많은 소비자용 장치는 PPTP 호출을 하나만 허용하고 출발지 주소로 추적한다. 혼자서 작동하던 노트북도 두 번째 기계가 걸면 완료되지 않으며, 클라이언트 쪽에서는 실패가 무작위로 보인다. 그 패턴은 펌웨어에 속하며 어떤 프로필 변경도 그것을 바꾸지 않는다.

두 클라이언트가 거는 동안 연결 테이블을 관찰하라. 항상 첫 호스트만 매핑을 보유한다면 라우터는 지원의 한계에 도달한 것이고 클라이언트 측 설정으로는 움직이지 않는다.

어느 쪽 절반이 실패하는지 증명하라

라우터에서 무엇이든 바꾸기 전에 TCP 1723이 도착하는지 확인하라. 그 답이 어느 절반을 시험하는지 결정하기 때문이다. 이것들은 Windows 클라이언트에서 자신의 서버 이름을 대상으로 실행하라. 첫 번째는 포트가 응답했는지 출력하고, 두 번째는 대화상자 없이 걸기 때문에 반복 시도를 비교할 수 있다.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

포트 시험에서 참이 나오면 제어 채널이 열려 있고 GRE가 남은 용의자다. 거짓이 나오면 라우팅, 필터 또는 전달이 깨진 것이며 GRE를 바꿔도 그것을 구할 수 없다. 데이터 쪽은 볼 수 있는 곳, 즉 서버나 라우터에서 관찰해야 한다.

tcpdump -ni any proto 47

Wireshark에서의 등가물은 표시 필터 ip proto 47이며, 셸에 익숙하지 않은 사람에게 건네기 더 쉽다. 응답으로 아무것도 나가지 않은 채 GRE가 도착한다면 돌아오는 경로를 고쳐야 한다는 뜻이다.

실제로 오류를 고치는 것

라우터가 설정을 노출하는 곳에서는 PPTP 패스스루를 켜거나, 규칙을 받아들이는 펌웨어에서 프로토콜 47을 명시적으로 허용하라. RouterOS에서는 전달 규칙이 프로토콜을 직접 대조하며, 포트 기반 전달은 결코 그렇게 할 수 없었다. 소비자용 펌웨어는 보통 같은 결정을 체크박스 뒤에 숨기고, 때로는 포트 전달이 아니라 보안 설정 아래에 둔다. 그런 제어가 없다면 클라이언트 쪽에서는 보상할 방법이 없다.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP를 교체하는 것이 다른 선택지이며 종종 더 저렴하다. VPN을 스스로 종료하는 라우터는 들어오는 클라이언트의 이중 NAT를 피하고, 포트 기반 NAT가 이미 처리하는 프로토콜은 패스스루가 전혀 필요 없다: UDP 위의 OpenVPN, TCP 443 위의 SSTP, 또는 ESP를 UDP 4500에 감싸는 NAT-T를 쓰는 L2TP/IPsec이다. PPTP는 MS-CHAPv2에도 의존하며, 문서화된 약점 때문에 오류가 사라진 뒤에도 새 구축에는 나쁜 선택이다.

어떤 규칙이 차이를 만들었는지 기록하라. 두 번째 사용자가 접근을 요청할 때 같은 사이트가 같은 한계를 만나기 때문이다. 프로토콜 수준의 수정은 네트워크 노트에 속하며, 다음 엔지니어가 그곳을 본다.