SSTP 시간 초과인가 인증서 오류인가 — 둘을 구분하는 방법

SSTP 연결은 사용자의 자리에서는 똑같아 보이는 두 가지 방식으로 실패하며, 각각의 수리는 다른 계층에 있습니다. 시간 초과는 필요한 교환이 끝까지 완료되지 않았다는 뜻이고, 인증서 오류는 신원 자료가 도착했는데 거부되었다는 뜻입니다. 두 번째를 첫 번째처럼 다루면 애초에 문제가 아니었던 방화벽과 비밀번호로 향하게 됩니다. 구분해 주는 증거는 클라이언트 자체의 로그에 있으며, 무엇이든 바꾸기 전에 읽으면 알 수 있습니다.

두 가지 실패, 두 가지 다른 교환

SSTP는 HTTPS 모양의 세션 안에 터널을 실어 나르므로 443 외에는 허용하지 않는 네트워크에서도 살아남습니다. 클라이언트는 TLS 핸드셰이크를 마치고 프로토콜 특유의 메서드로 HTTP 요청을 보낸 뒤, 그 스트림 안에서 터널이 흐릅니다. 이 단계 중 어디서든 실패하면 연결이 멈추고, 자격 증명이 관련되는 것은 뒤의 단계뿐입니다.

그 순서가 바로 진단입니다. TLS 핸드셰이크가 끝나지 않으면 자격 증명이 전송되지 않은 것이므로 비밀번호 재설정으로는 해결되지 않습니다. 핸드셰이크가 끝난 뒤 멈춘다면 신원은 받아들여졌고 요청 경로의 무언가가 거부한 것입니다. 핸드셰이크가 검증 메시지와 함께 실패한다면 서버가 응답했고 클라이언트가 들은 내용을 받아들이지 않은 것입니다. 세 가지 결과, 세 계층입니다.

로그 한 줄은 보통 세 가지 중 어디에 있는지 알려 주므로 첫 변경 전에 기록해 둘 가치가 있습니다.

시간 초과는 단계가 끝나지 않았다는 뜻이다

이름 해석과 TCP 도달성부터 시작하십시오. 그곳의 시간 초과는 나중의 시간 초과와 똑같이 보이기 때문입니다. 443이 열려 있다고 보고하는 포트 검사기는 수신 측이 연결을 받아들였다는 것만 증명하며 그 이상은 아닙니다.

다음 용의자는 호스트가 아니라 경로입니다. 프록시와 애플리케이션을 인식하는 방화벽은 때때로 SSTP가 쓰는 요청 메서드를 거부하거나 몇 시간씩 열린 스트림을 끊으며, 두 행동 모두 클라이언트 쪽에서는 시간 초과처럼 보입니다. 같은 호스트가 제공하는 평범한 HTTPS 페이지는 완벽하게 열리는데 터널 메서드는 거부되므로, 엔드포인트를 브라우저로 열어 보는 것은 아주 적은 것만 증명합니다. 이 두 경우를 가르려면 프록시가 없는 네트워크에서 시험하십시오.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

상대의 어떤 응답도 오기 전의 시간 초과는 계정에 대해 아무것도 말해 주지 않으며, 그 시점에 비밀번호를 바꾸는 것은 변수를 하나 더할 뿐입니다.

인증서 오류는 신원이 거부되었다는 뜻이다

여기서는 서버가 실제로 응답했으므로 네트워크는 동작하고 질문은 신원으로 옮겨 갑니다. 클라이언트가 접속하는 이름과 인증서가 실제로 주장하는 이름을 비교한 뒤 유효 기간과 발급 체인을 확인하십시오.

클라이언트가 신뢰하지 않는 사설 CA는 만료된 인증서와 같은 부류의 오류를 만들고, 몇 시간씩 어긋난 시계도 마찬가지입니다. 원시 주소로 접속하면 새로운 불일치가 생깁니다. 인증서가 주장하는 것은 주소가 아니라 이름이기 때문입니다. 관리되는 배포에서는 오류 페이지가 제시하는 대체 루트를 받아들이는 대신 관리자에게서 의도된 신뢰 구성을 받으십시오. 원인을 고치는 동안 검증은 켜 둡니다.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

성공한 TLS 단계는 통과한 뒤에도 그대로 두십시오. 나중에 되돌리면 어떤 변경이 실제로 터널을 고쳤는지 가려지기 때문입니다.

둘이 뒤섞이는 지점

두 실패 모두 연결이 올라오지 않는 모습으로 나타나고, 둘 다 사용자가 무관한 것을 바꾼 뒤에 찾아옵니다. 그 우연이 잘못된 수리를 한동안 그럴듯하게 보이게 합니다.

두 습관이 둘을 갈라놓습니다. 구성을 건드리기 전에 클라이언트 로그를 기록해 첫 상태를 남기십시오. 시도마다 계층을 하나만 바꾸어 다음 결과가 알려진 변수에 속하게 하십시오. 포트 검사기와 브라우저는 전체 순서가 아니라 부분적인 관측이며, 어느 것도 클라이언트 자체의 보고를 대신하지 못합니다. 두 습관 모두 비용이 들지 않고, 둘 다 조사를 짧게 만듭니다.

인증서 문제와 도달성 문제가 따로 문서화된 데에는 이유가 있습니다.

실제 클라이언트로 다시 시험한 뒤 안쪽으로 이동하라

구체적인 수정이 자리를 잡으면 브라우저 탭이 아니라 실제 SSTP 클라이언트와 진짜 프로필로 다시 시도하십시오.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

세션이 연결되는데 자원이 여전히 실패한다면 터널은 더 이상 용의자가 아닙니다. 라우팅, DNS, 서비스 접근으로 넘어가십시오. 그것은 다른 증거를 가진 다른 조사입니다. 동작하는 TLS와 인증 단계를 유지하면 첫 조사의 반복이 되지 않습니다. 실패한 단계를 티켓에 적으십시오. 그렇지 않으면 다음 사람이 다시 맨 위에서 시작합니다.