브라우저의 HTTPS가 성공하는 곳에서 SSTP가 실패하는 이유
SSTP는 443 포트의 TLS 안에서 실행되지만 웹 요청이 아닙니다. TCP, TLS 신원, SSTP 교환, PPP 인증을 별개의 단계로 시험하십시오.
브라우저는 VPN 호스트 이름을 HTTPS로 아무 불평 없이 열지만, SSTP 클라이언트는 여전히 연결을 거부합니다. 그 쌍에는 모순이 없습니다. SSTP는 TLS를 외부 전송으로 사용한 뒤 그 연결 안에서 자체 요청과 PPP 페이로드를 실행하므로, 페이지가 성공적으로 로드되었다는 것은 아주 좁은 한 가지만 증명합니다: 호스트가 443 포트에서 GET에 응답한다는 것입니다. 클라이언트는 다른 질문을 하고 있고, 서버가 그 질문에 형편없이 답할 수 있습니다.
페이지는 로드되고 터널은 그렇지 않다
사람들은 브라우저 테스트가 빠르기 때문에 이를 찾고, 그 결과를 서버가 도달 가능하고 구성되어 있다는 증거로 받아들입니다. 그것은 주소 표시줄이 연 경로에 대한 GET의 증거일 뿐입니다. VPN 대화는 같은 TLS 핸드셰이크 뒤에 시작되지만 보내는 것은 웹 페이지가 결코 사용하지 않는 메서드와 경로입니다. 따라서 브라우저에 대한 200 응답은 SSTP 엔드포인트가 존재하는지에 대해 아무것도 말하지 않습니다.
두 관찰을 분리하면 조사가 짧아집니다. 전송과 인증서 체인은 작동하고, 그 위의 프로토콜 교환 어딘가가 작동하지 않습니다. 이것은 고장난 포트나 만료된 인증서와 다른 조사이며, 다른 증거를 필요로 합니다.
SSTP 클라이언트가 실제로 보내는 것
클라이언트는 SSTP_DUPLEX_POST 메서드로 /sra_{GUID}/ 경로에 HTTP 요청을 보낸 다음, 연결 본문을 PPP 프레임을 나르는 양방향 스트림으로 열어 둡니다. 규격을 따르는 서버는 HTTP/1.1 200으로 응답하고 웹 서버처럼 행동하기를 멈춥니다. 그 밖의 모든 것은 서명입니다: 405나 404는 엔드포인트가 없다는 뜻이고, 301이나 302는 무언가가 요청을 리디렉션한다는 뜻이며, 즉각적인 FIN은 프록시나 서버가 스트림을 닫았다는 뜻입니다.
그래서 목표는 TLS 인증서를 덧붙인 웹 서버가 아니라 SSTP 서버여야 합니다. 메서드, 경로, 장기 유지 본문은 프로토콜 요구 사항이므로 리버스 프록시가 구성만으로 추가할 수 없습니다. 일반 HTTPS를 완벽하게 전달하는 프록시도 인식하지 못하는 메서드는 거부할 수 있습니다.
프록시나 웹 서버가 스트림을 끊는 곳
중개자는 무엇이든 전달하기 전에 HTTP 요청 줄을 검사하며, 특이한 경로를 가진 사용자 정의 메서드는 그 규칙을 통과하지 못할 수 있습니다. 일부 장비는 정상 페이지를 제공하면서 터널을 거부하거나 중단하므로, 클라이언트는 깔끔한 거부 대신 시작했다가 죽는 연결을 보고합니다. 다른 장비는 요청을 받아들인 뒤 PPP 킵얼라이브가 견디지 못하는 본문 또는 유휴 타임아웃을 적용합니다. 둘 다 클라이언트 쪽에서는 똑같이 보이므로, 어느 단계가 실패했는지가 오류 텍스트보다 더 중요합니다.
웹 사이트와 SSTP 사이에 443 포트를 공유하는 것은 라우팅 선택이며, 모든 홉이 두 대화를 같은 방식으로 처리한다는 약속이 아닙니다. 경로에 로드 밸런서, 방화벽, TLS 종료 장치가 있다면 VPN 구성을 건드리기 전에 용의자 목록에 추가하십시오.
단계를 따로 시험하십시오
각 단계가 다른 계층을 배제하므로 검사를 순서대로 실행하고 첫 실패에서 멈추십시오. 아래 TLS 프로브는 인증서 신원을 SSTP가 하는 모든 것과 분리합니다. 호스트 이름을 자신의 엔드포인트로 바꾸고 출력되는 subject와 체인을 읽으십시오.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com그다음 클라이언트 오류에서 추측하는 대신 남은 증거를 단계에 대응시키십시오. 아래 표는 티켓에 인용할 점검 목록이며, 한 실패를 다음 실패와 구분하는 서명을 담고 있습니다.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
티켓에 "연결할 수 없음"이라고 쓰는 대신 마지막으로 성공한 단계를 기록하십시오. MS-SSTP 명세는 TLS 핸드셰이크 뒤에 오는 요청과 PPP 교환을 문서화하며, 브라우저 테스트가 둘 중 어느 것도 대신할 수 없는 이유의 근거입니다.
먼저 신원, 그다음 PPP
TLS 신원과 PPP 인증은 순차적이며 대안이 아니고, 이를 혼동하면 사람들이 잘못된 서버 설정으로 갑니다. 클라이언트는 먼저 서버 인증서와 그 의도된 용도를 검증한 다음, PPP가 자체 상태를 협상하고 챌린지-응답 방식이나 EAP로 사용자를 인증합니다. 인증서 문제는 거부된 비밀번호와 다른 오류를 내고, 어느 오류도 다른 쪽이 다루는 단계를 설명하지 않습니다.
호스트 이름을 주소로 바꾸거나 인증서 경고를 넘겨 클릭하면, 실패하는 단계를 식별했을 검사를 고치는 대신 제거합니다. 경고를 남기고 읽으십시오. HTTP 교환이 SSTP 동작에 도달조차 하지 않았고 자격 증명이 요구된 적이 없으므로 PPP 비밀번호를 재설정하지 마십시오.