PPTP 분할 터널링이 작동하지 않습니다: 먼저 GRE 경로를 고치세요

PPTP 연결이 올라오는 것을 보면 클라이언트가 인증하고 ppp0 어댑터나 WAN Miniport가 나타나며 상태 창이 초록색이 되므로, 어려운 부분이 끝났다고 믿기 쉽습니다. 그런데 내부 호스트로 가는 첫 요청이 시간 초과되면 프로필이 비난받습니다. 실제로는 두 개의 독립된 계층을 정리해야 하며, TCP 1723과 GRE를 나르는 바깥 전송과 어떤 목적지가 PPP 인터페이스를 쓰는지 결정하는 안쪽 정책입니다. 초록 상태는 첫 계층이 협상했다는 것만 증명하며 둘째 계층에 대해서는 아무 말도 하지 않습니다.

프로필에서 제어 소켓까지 클라이언트를 따라가세요

클라이언트 로그를 열고 서버에 접속하는 지점을 찾으세요. PPTP는 먼저 포트 1723으로 TCP 연결을 열고 그 채널에서 터널 매개변수를 협상합니다. 이 단계가 실패하면 뒤의 어떤 것도 중요하지 않으며, 오류는 보통 서버 주소나 시간 초과를 지목합니다.

어떤 경로도 건드리기 전에 네트워크에서 제어 연결을 확인하세요. 클라이언트나 미러 포트에서 한 번의 연결 시도에 대해 TCP 1723을 캡처합니다:

sudo tcpdump -ni any 'tcp port 1723' -c 20

핸드셰이크가 완료되고 세션이 수립되었다면 바깥 제어 채널이 작동한다는 뜻입니다. SYN-ACK를 전혀 받지 못하는 SYN은 방화벽, 잘못된 서버 주소, 포트를 거르는 공급자를 가리킵니다. 핸드셰이크 직후 재설정이 오면 서버가 자격 증명이나 터널 유형을 거부한 경우가 많습니다.

GRE는 두 번째 프로토콜이지 포트가 아닙니다

PPTP는 PPP 페이로드를 확장 GRE, 즉 IP 프로토콜 47 안에 나르지만, 여기에는 라우터가 추적할 포트 번호가 없습니다. 그래서 TCP 1723을 허용하는 규칙도 터널에 데이터 경로를 남기지 않을 수 있습니다. 상태 저장 NAT 장비는 응답을 되돌리려면 GRE 내부의 호출 ID를 이해해야 하는데, 많은 장비가 그러지 못합니다. PPTP 명세는 제어 채널과 GRE 페이로드를 별개 조각으로 두며, 테스트 계획도 그래야 합니다.

같은 캡처에서 프로토콜 47을 지켜보고, 나가는 것과 돌아오는 것을 비교하세요:

sudo tcpdump -ni any 'proto gre' -c 20

TCP 1723이 건강한데 응답 없이 나가는 패킷은 전형적인 GRE 차단 신호입니다. 소비자 라우터의 PPTP 패스스루는 그 특정 펌웨어의 기능이므로, 어떤 호텔 네트워크가 된다고 다음 네트워크도 보장되지 않습니다. 라우터가 패스스루를 제공하지 않고 바꿀 수 없다면 문제는 라우팅 테이블이 아니라 프로토콜 선택입니다.

터널이 패킷 하나를 옮긴다는 것을 증명하세요

GRE가 흐르기 시작하면 PPP 협상이 클라이언트 인터페이스에 주소를 할당합니다. 추정하지 말고 할당을 읽으세요:

ip -4 addr show ppp0

지점 간 링크의 목적지로 표시된 피어 주소로 핑을 보내세요. 이 단계의 응답은 캡슐화된 경로가 끝에서 끝까지 작동하고 서버가 터널 안에서 응답한다는 것을 증명합니다. 피어는 응답하는데 내부 호스트가 응답하지 않는다면 바깥 전송은 정상이고 장애는 안쪽으로 옮겨간 것입니다.

분할 경로를 추가하기 전에 이것을 하세요. 전송이 깨진 상태에서 경로를 바꾸면 두 번째 변수가 생기고 첫 번째를 가립니다.

분할 정책을 작성하세요, DNS도 포함하여

분할 라우팅은 결정의 목록이지 확인란이 아닙니다. 터널을 건너야 하는 각 사설 접두사에는 PPP 인터페이스를 통한 경로가 필요하고, 로컬에 남아야 하는 각 접두사는 그 안에 없어야 합니다. 응용 프로그램 서브넷의 경로가 사설 리졸버로 가는 대응 경로를 갖지 않는 것은 앱이 고장 난 것처럼 보이는 장애를 만드는 흔한 방법입니다.

각 범주의 주소 하나에 대해 커널이 내리는 결정을 확인하세요:

ip route get 10.20.5.10
ip route get 203.0.113.25

첫째는 ppp0을, 둘째는 일반 게이트웨이를 가리켜야 합니다. 둘 다 같은 인터페이스를 가리키면 정책은 전혀 분할되지 않은 것입니다. DNS 서버 자체의 주소를 터널 목록에 추가하세요, 그렇지 않으면 내부 호스트의 이름 확인이 로컬 리졸버로 나가 아무 쓸모도 없습니다.

다섯 단계로 반복할 수 있는 점검

계층을 순서대로 실행하고 처음 실패한 곳에서 멈추세요: 제어 채널, GRE 가시성, PPP 피어 응답, 내부 주소 하나의 분할 경로, 터널을 통한 응용 프로그램 요청입니다. 각 단계에는 전용 명령이 있으므로 실패를 미스터리가 아니라 원인에 돌릴 수 있습니다.

Linux 클라이언트용 간단한 버전은 이렇습니다:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Windows에서는 route print와 클라이언트에 표시되는 어댑터 상태로 같은 순서가 적용됩니다. PPTP는 레거시 프로토콜이며, 서버가 SSTP나 IKEv2를 제공한다면 모든 홉에서 프로토콜 47이 통과하는 데 의존하는 경로를 조정하는 것보다 옮기는 편이 보통 시간을 더 잘 쓰는 일입니다. 오래된 프로필을 새 릴리스에 복사하지 말고 교체 대상의 인증서와 인증 계약을 확인하세요.