TLS를 검사하는 프록시 뒤의 SSTP: 세션이 끊기는 지점

브라우저가 기업 인트라넷을 열고 프록시 인증서도 신뢰되지만, SSTP 클라이언트는 연결이 끝날 무렵 끊깁니다. 이 패턴은 잘못된 암호가 아니라 웹 요청과 터널 세션의 차이를 가리킵니다. TCP부터 위로 연결을 따라가며 처음 실패하는 단계를 적으십시오. 프록시가 원인인지는 오류 코드가 아니라 그 단계가 알려 줍니다.

클라이언트가 멈추는 지점에서 시작하십시오

클라이언트는 정해진 순서를 지납니다: 포트 443으로의 TCP 연결, TLS 핸드셰이크, 인증서 검증, SSTP의 HTTP 교환, PPP 협상과 인증, 그다음 IP 구성입니다. 각 단계의 실패는 다른 흔적을 남기며, 그것을 혼동하면 잘못된 구성 페이지로 가게 됩니다.

TCP 실패는 TLS 바이트가 나타나기 전의 시간 초과나 재설정입니다. TLS 실패는 경고나 핸드셰이크 시간 초과입니다. 인증서 실패는 체인이나 이름에 관한 경고를 냅니다. HTTP 실패는 핸드셰이크가 성공한 뒤에 오며, 흔히 상태 코드나 즉시 종료로 나타납니다. PPP 실패는 터널이 기술적으로 세워진 뒤에 오므로 인증 문제처럼 보입니다.

첫 오류 줄이 아니라 클라이언트 로그에서 마지막으로 성공한 단계를 읽으십시오. 오류 줄은 보통 결과를 보고하고, 단계 경계는 거절한 구성 요소를 지목합니다.

SSTP가 네트워크에 요구하는 것

SSTP는 TCP 443의 TLS 위에서 동작하고, 이어서 SSTP 명세에 정의된 SSTP_DUPLEX_POST라는 HTTP 요청을 /sra_{GUID}/ 형태의 경로로 보냅니다. 요청은 사실상 무제한의 콘텐츠 길이를 선언하고 세션 내내 스트림을 양방향으로 열어 둡니다. PPP 프레임은 그 스트림 안을 흐릅니다.

그래서 일반 탐색을 처리하는 프록시도 실패할 수 있습니다. 본문이 유한한 GET이나 POST는 버퍼링하고 검사하고 전달할 수 있지만, 끝나지 않는 본문을 가진 양방향 스트림은 그럴 수 없습니다. 본문이 끝나기를 기다리는 프록시는 영원히 기다리고, 클라이언트는 결국 시간 초과됩니다.

메서드 필터링과 인증은 저마다의 실패 방식을 더합니다. 프록시가 요청에 자격 증명을 요구하면 브라우저는 답하더라도 VPN 클라이언트는 답하지 않을 수 있습니다. 메서드를 제거하거나 다시 쓰면 게이트웨이는 PPP가 시작되기 전에 요청을 거부합니다.

검사가 신원을 바꾸는 이유

TLS를 검사하는 프록시는 클라이언트의 TLS 연결을 종료하고 게이트웨이로 별도 연결을 엽니다. 그래서 클라이언트는 게이트웨이의 인증서가 아니라 프록시의 인증서를 검증하고, 게이트웨이는 프록시를 자신의 상대로 봅니다. 조직이 자체 루트를 배포하면 브라우저와 VPN 클라이언트가 모두 그 체인을 받아들일 수 있어 핸드셰이크는 성공하고 문제는 다음 단계로 넘어갑니다.

검증이 성공했다고 프록시가 세션을 실어 나를 수 있는 것은 아닙니다. 프록시는 여전히 버퍼링 없이 무제한 양방향 POST를 중계해야 하고 두 연결을 몇 시간씩 살려 두어야 합니다. 많은 검사 제품은 요청-응답 트래픽을 위해 만들어졌고 이 경우를 잘 다루지 못하거나 아예 다루지 못합니다.

그래서 알 수 없는 루트를 추가하거나 검증을 끄는 것은 잘못된 수리입니다. 클라이언트가 어떤 인증서를 받아들이는지만 바꿀 뿐, 실제로 세션을 끊은 스트림 처리는 건드리지 않습니다.

설정을 바꾸기 전에 발급자를 확인하십시오

엔드포인트에 어떤 인증서를 제시하고 누가 서명했는지 물으십시오. 아래 명령은 VPN 세션을 시작하지 않고 체인과 발급자를 보여 줍니다.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

발급자가 공인 CA라면 이 호스트의 연결은 아마 가로채이지 않으며 실패는 다른 곳에 있습니다. 발급자가 조직 자체 CA라면 검사가 활성이고 게이트웨이에는 프록시를 거쳐 도달합니다. 이름만으로 결론을 내리기 전에 지문을 네트워크 팀이 기대하는 값과 비교하십시오.

같은 호스트에 대한 브라우저 테스트는 프록시가 GET을 받아들인다는 것만 증명합니다. SSTP 메서드, 요청 URI, 본문의 수명에 대해서는 아무 말도 하지 않으므로, 동작하는 인트라넷 페이지를 터널 경로가 지원된다는 증거로 삼지 마십시오.

지원되는 경로를 선택하십시오

네트워크 소유자에게 구체적인 질문 하나를 하십시오: 그 프록시가 이 게이트웨이로 포트 443의 버퍼링 없는 양방향 POST를 허용합니까? 예라면 프록시 예외나 VPN 호스트에 대한 문서화된 우회로 이어집니다. 아니오라면 검사된 경로가 SSTP를 실을 수 없고, 지원되는 해결책은 클라이언트 조정이 아니라 다른 경로나 프로토콜입니다.

선택지에는 보통 VPN 게이트웨이용 비검사 출구, 기업 트래픽만 프록시로 보내는 분할 터널 설계, 또는 조직이 다른 포트에서 지원하는 대체 프로토콜이 포함됩니다. 각각은 네트워크 설계에 속하며, 비교가 경로를 분리할 수 있도록 같은 장치와 프로필로 시험해야 합니다.

결과를 기록하십시오: 발급자, 실패한 단계, 프록시 규칙, 선택한 경로입니다. 같은 98퍼센트 지연을 본 다음 사람은 전체 과정을 반복하는 대신 한 가지 사실을 확인할 수 있습니다.