SSTP는 먼저 서버를 인증하고 나중에 사용자를 인증한다

SSTP 클라이언트는 TLS를 완료하고도 한 초 뒤에 사용자를 거부할 수 있습니다. 이 순서는 버그가 아니라 전송 보안이 먼저이고 사용자 인증은 그다음인 프로토콜 스택입니다. 두 단계가 서로 다른 메시지로 실패하므로 수정도 서로 달라야 합니다. 어느 단계에서 오류가 났는지 읽는 것이 진단의 대부분입니다.

신뢰할 수 있는 인증서는 엔드포인트를 증명할 뿐 계정에 대해서는 아무것도 말해 주지 않습니다.

TLS 핸드셰이크가 확립하는 것

클라이언트는 서버가 제시한 인증서를 자체 신뢰 저장소, 요청된 호스트 이름, 유효 기간, 플랫폼이 적용하는 추가 정책과 대조해 검증합니다. 이는 의도한 엔드포인트로의 연결을 보호합니다. 특정 계정이 활성화되었거나 만료되지 않았거나 원격 액세스가 허용되었다는 것을 증명하지는 않습니다. 그런 것은 나중에 다른 구성 요소가 묻는 별개의 질문입니다.

그래서 로그인 프롬프트에 도달하려고 인증서 검사를 제거하는 것은 잘못된 수리입니다. 검증할 수 없는 연결에서 로그인 프롬프트를 얻을 뿐입니다. 인증서 오류는 호스트 이름, 시계, 체인 또는 신뢰 구성의 문제입니다.

SSTP와 PPP가 그 위에 더하는 것

SSTP는 HTTPS 위에서 동작하며 내부에 PPP를 실어 나르고, 연결 주위에 자체 제어 교환을 둡니다. 그다음 PPP가 링크 및 인증 단계를 실행하며, 인증 방법은 서버 정책과 클라이언트 기능에 따라 달라집니다. PAP, CHAP, MS-CHAPv2, EAP는 모두 성질이 크게 다른 PPP 인증 옵션입니다. VPN의 사용자 검사는 바로 그 PPP 단계이지 그 아래의 TLS 계층이 아닙니다.

따라서 사용자 거부는 자격 증명, 계정 제한 또는 방법 불일치를 뜻할 수 있습니다.

서버 측 이유는 프로필의 모든 비밀을 재설정하는 것보다 훨씬 유용합니다. 계정 비활성화 사건과 방법 협상 실패는 클라이언트에서는 비슷해 보이지만 서버에서는 공통점이 없습니다.

오류를 단계에 맞추기

연결이 TLS에 도달하는지, 그다음 SSTP HTTP 교환, 그다음 PPP 단계에 도달하는지 확인하십시오. 재시도 사이에 로그 타임스탬프를 정렬해 두어 이전 실패가 이후 성공과 혼동되지 않게 하십시오. 한 창에서 두 번의 시도를 기록하는 클라이언트는 그렇지 않으면 도달한 마지막 단계에서 실패한 것처럼 보입니다. 마지막 줄이 아니라 첫 번째 관련 오류를 읽으십시오.

같은 정렬은 서버 측에서도 중요한데, 인증 기록과 전송 로그는 흔히 서로 다른 시계를 가진 별도 파일입니다. 이 분의 차이만으로도 명백한 원인이 불가능해 보입니다.

로그인 후에도 권한 부여는 별개입니다

성공적인 로그인이 모든 개인 리소스를 허용하지는 않습니다. 경로가 무엇에 도달할 수 있는지 정하고, DNS가 무엇이 확인되는지 정하며, 각 서비스는 여전히 자체 권한을 적용합니다. 연결됨으로 표시되는 세션은 터널에 대한 진술이지 파일 공유에 대한 것이 아닙니다. 사용자가 연결할 수 있지만 한 호스트에 도달할 수 없다면 터널 단계는 이미 끝난 것입니다.

이것은 핸드셰이크가 보여 준 것과 같은 계층화이며, 한 단계 위입니다.

계정 복구는 명시적 사용자 거부에 대응해 전송 설정을 바꾸는 대신 운영자가 지원하는 절차 안에서 유지하십시오. 비활성화된 계정을 고치려고 전송을 바꾸는 것은 계정이 무관한 이유로 다시 활성화될 때 효과가 있는 것처럼 보이는 종류의 수리입니다.