핫스폿을 통한 PPTP: TCP 1723은 절반에 불과하다

점검은 다음 순서로 진행한다: 제어 연결이 열리는지, GRE가 경로를 버티는지, 서버가 호출을 받아들이는지, 인증이 끝나는지다. PPTP 클라이언트에는 1723의 TCP 세션과 데이터를 나르는 GRE 경로가 모두 필요하며, 핫스폿은 하나를 통과시키고 다른 하나를 떨어뜨릴 수 있다. 순서대로 하면 추측 대신 어느 경계를 조사할지 알 수 있다. Windows 오류 번호는 그것을 대신해 주지 않는다.

GRE는 IP 프로토콜 47이다. TCP나 UDP 포트 47이 아니며, 이 차이가 방화벽에 대한 혼란의 대부분을 설명한다.

두 경로, 하나의 연결

제어 연결은 목적지 포트 1723으로 가는 평범한 TCP 세션이며, 대부분의 네트워크는 불평 없이 허용한다. 데이터 경로는 GRE, 프로토콜 47이고, 첫 번째를 허용하는 방화벽이 두 번째는 전혀 모를 수 있다. 이 조합은 시작하는 듯 보이다가 아무것도 나르지 않는 클라이언트를 만들며, 거부된 연결보다 훨씬 정보가 적은 증상이다. 통신사에 대해 결론을 내리기 전에 두 경로를 따로 시험하라.

변환은 자체 요구 사항을 더한다. 포트를 공유하는 게이트웨이는 호출 식별자를 주소와 함께 다시 쓰기 위해 PPTP를 이해하는 ALG가 필요한 경우가 많고, 그것이 없으면 패킷 손실처럼 보이는 방식으로 세션을 망칠 수 있다. 이 동작은 흔하지만 구현에 따라 다르므로 공급업체의 제한은 모든 핫스폿의 속성이 아니라 한 가지 예로 보아야 한다.

핫스폿은 두 개의 경계를 더한다

클라이언트 트래픽은 보통 휴대폰 자체의 공유 NAT를 거친 뒤 서버에 도달하기 전에 통신사 수준의 변환을 지난다. 사무실 라우터의 규칙은 다른 사람 소유의 중간 장치를 고칠 수 없으므로 집 쪽 포트 포워딩이 거의 도움이 되지 않는다. 나가는 클라이언트에는 들어오는 포트를 열어 줄 필요도 없고, 변환된 연결의 응답은 게이트웨이가 만든 상태를 통해 돌아온다. NAT 뒤에 호스팅된 서버는 전혀 다른 요구 사항 집합을 가진다.

PPTP passthrough라는 메뉴 항목이 있다면 그 장치가 이 프로토콜을 어떻게 처리하는지 결정한다. 휴대폰에서 VPN을 호스팅하거나 모든 프로토콜을 무조건 전달하는 것과 같은 기능이 아니며, 그것을 켜는 것이 GRE를 통과시키는 일반적인 허가도 아니다.

807은 판결이 아니라 중단으로 읽어라

Windows는 807을 중단된 연결로 보고하며, 이는 원인이 아니라 결과를 설명한다. 오류 표에서는 806을 GRE 관련 범주로 따로 다루며, 이론을 세우기 전에 그 차이를 아는 것이 좋다. 두 번호 중 어느 것도 통신사가 프로토콜 47을 걸러 냈는지, 서버 용량이 바닥났는지, 자격 증명이 맞았는지를 밝히지 않는다. 오류는 세션이 끝났다고 말하고, 경로는 어디서 끝났는지 말한다.

핫스폿에서 성공하는 브라우저 테스트는 평범한 응용 경로가 작동한다는 것만 증명한다. GRE에 대해서는 아무것도 말하지 않는다.

실패한 단계를 분리하라

노트북, 서버, 프로필을 고정한 뒤 접속 네트워크만 다른 승인된 망으로 바꾼다. 결과가 바뀌면 통제할 수 있는 경계에서 TCP와 GRE 교환을 캡처하고 결코 일어나지 않는 가장 이른 단계를 찾는다: 제어 설정, 호출 준비, 데이터 전달, PPP 인증 중 하나다. 각각은 캡처에 다른 서명을 남긴다. 작동하는 네트워크와 실패하는 네트워크를 비교하는 것이 오류 문구를 다시 읽는 것보다 훨씬 유익하다.

이 모든 것은 이미 존재하는 배포를 진단한다. 새 PPTP 서비스를 세우자는 주장이 아니며, 프로토콜은 협상으로 우회할 수 없다: 다른 클라이언트를 설치해도 변하지 않은 서버가 다른 말을 하게 되지는 않는다.

지속적인 접속을 위해서는 VPN 소유자와 지원되는 마이그레이션을 합의하라. 점검 목록은 우회책이 아니라 결정으로 끝난다.