SSTP는 HTTPS 위의 PPP이며, 포트 443의 웹 페이지가 아닙니다

SSTP는 PPP를 HTTPS 연결 내부에서 운반하므로, 중간에 있는 모든 것에는 웹 트래픽처럼 보입니다. TLS와 HTTP가 바깥 채널을 세우고, 다음으로 SSTP 제어 메시지가 터널을 준비하며, PPP가 세션 동작을 제공합니다. 같은 주소에서 페이지를 불러오는 브라우저는 첫 단계의 일부만 마쳤습니다. 그것을 VPN 테스트로 보는 것이, 동작하는 프록시가 프로토콜 불일치의 책임을 뒤집어쓰는 방식입니다.

네 단계를 순서대로 따라가면, 보고 있는 장애는 그중 하나에 해당합니다.

1단계: TCP와 TLS

클라이언트는 포트 443으로 TCP 연결을 열고 TLS 핸드셰이크를 수행합니다. 인증서 체인은 클라이언트가 구성된 호스트 이름과 일치해야 합니다. 여기서 이름이 일치하지 않으면 어떤 SSTP 메시지도 교환되기 전에 장애가 생기며, SSTP 명세 는 이 바깥 HTTPS 채널이 이미 존재한다고 전제합니다. 이후 단계의 무엇도 여기서의 신뢰 실패를 보상하지 못합니다.

일반적인 웹 서버는 이 단계를 완벽히 마치고도 다음 단계에서 실패할 수 있습니다. TLS 성공은 인증서에 대한 증거이며, 그 뒤의 프로토콜에 대한 증거가 아닙니다.

2단계: HTTPS 요청

SSTP는 특정 메서드인 SSTP_DUPLEX_POST로 요청하고, 문서를 돌려주는 대신 교환을 열어 둡니다. 평범한 페이지 요청용으로 구성된 서버나 프록시는 연결을 받아들인 뒤 메서드를 거부할 수 있습니다. 그 거부가 사람들이 흔히 포트 443이 차단되었다고 설명하는 호환성 문제입니다.

서버 로그에서 응답 코드와 메서드를 읽으십시오. 이 단계에서의 거부는 TCP 시간 초과와 다른 문제이며, 둘은 서로 다른 수정으로 이어집니다.

3단계: 제어 메시지

요청이 수락되면 SSTP는 터널을 협상하고 준비하는 제어 메시지를 교환합니다. 이것은 HTTP 요청이 아니라 HTTPS 본문 내부의 프로토콜 메시지이므로, 본문을 검사하고 다시 쓰는 프록시는 페이지 요청은 그대로 두고 이것들을 깨뜨릴 수 있습니다.

여기서 심층 검사 미들박스가 명성을 얻습니다. 페이지는 열리는데 VPN이 실패한다면, 포트가 열려 있는지가 아니라 본문이 수정되는지를 확인하십시오.

4단계: PPP가 넘겨받습니다

그다음 PPP가 세션 동작을 제공합니다. 링크 협상, 인증, 그리고 이어지는 네트워크 계층 구성입니다. PPP 인증은 클라이언트가 이미 통과한 TLS 검사와 별개입니다. 클라이언트가 받아들이는 서버 인증서는 사용자의 자격 증명이 유효한지, 계정이 승인되었는지에 대해 아무것도 말하지 않습니다.

받아들인 인증서와 거부된 로그인은 모순되지 않습니다. 서로 독립적인 결과를 가진 연속된 단계입니다.

인증에는 여러 역할이 있습니다

클라이언트는 TLS 서버의 신원을 자체 신뢰 저장소와 구성된 이름에 대해 검증합니다. 그다음 PPP가 배포 방식에 따라 사용자나 머신을 인증합니다. 서버는 누가 연결할 수 있고 무엇에 도달할 수 있는지에 대한 자체 정책을 더할 수 있습니다. 호스트 이름을 인증서 신원과 일치하게 유지하십시오. 원시 주소로 바꾸면 동작하던 설정이 이름 검사 실패로 바뀝니다.

어느 단계가 장애를 보고했는지 적어 두십시오. 인증서, 메서드, 제어 메시지, PPP 인증, 그다음 경로: 다섯 곳, 다섯 가지 수정.

브라우저 테스트가 보여 줄 수 있는 것과 없는 것

그 주소에서 페이지를 불러오는 것은 DNS 해석, TCP 도달성, HTTP를 말하는 무언가가 듣고 있음을 증명합니다. 메서드가 받아들여지는지, 제어 교환이 살아남는지, PPP 인증이 구성되었는지는 증명하지 않습니다. 포트를 바꿔 다른 프로필을 변환하는 대신 SSTP를 구현한 클라이언트를 사용하십시오.

세션이 올라온 뒤에도 경로, DNS, 서버 측 전달이 사용자가 무엇에 도달할 수 있는지를 결정합니다. 터널은 경로이지 권한이 아닙니다.