443 포트가 응답하는데 SSTP는 여전히 실패한다: 어느 단계가 깨졌나

터널이 결코 구축되지 않는데 443 포트로 TCP 핸드셰이크가 완료된다는 것은 한 가지를 증명하며, 그것은 작은 일입니다. 해당 주소에서 무언가가 수신 대기 중이고 연결을 받아들일 준비가 되어 있다는 뜻입니다. 서비스가 무엇인지, 어떤 인증서를 제시할지, 첫 바이트 이후 무슨 일이 일어나는지는 알려주지 않습니다.

그 핸드셰이크와 작동하는 터널 사이에는 네 단계가 있으며, 각 단계는 서로 다른 오류를 냅니다.

열린 포트는 한 계층만 설명한다

TCP 연결을 받아들인다는 것은 어떤 프로세스가 소켓을 소유하고 경로가 핸드셰이크를 허용한다는 뜻입니다. 그 프로세스가 SSTP 서버인지, 프로필의 이름에 유효한 인증서를 가졌는지, 계정을 승인할지는 말해주지 않습니다. 같은 주소의 웹 서버는 핸드셰이크에 완벽히 응답한 뒤 SSTP 요청에 HTTP 오류로 응답합니다. 그 핸드셰이크 위의 모든 것은 검증되지 않은 채 남습니다.

포트 테스트를 판정이 아니라 가능한 가장 저렴한 필터로 다루세요. 그 가치는 실패의 한 범주를 통째로 제거한다는 데 있지, 그 위의 모든 것을 확인한다는 데 있지 않습니다.

둘을 혼동하는 것이 바로 클라이언트의 실제 문제를 한 번도 조사하지 않은 테스트 후에 사람들이 클라이언트를 재설치하는 이유입니다.

증거로 네 단계를 분리하라

단계는 전송 도달성, TLS 검증, HTTPS를 통한 SSTP 교환, 터널 내부의 PPP 인증입니다. 첫 단계를 통과하고 네 번째에서 실패하는 경로는 자격 증명 수정이 필요하고, 두 번째에서 실패하는 경로는 인증서나 이름 수정이 필요합니다. 이 수정들은 공통점이 없으며, 잘못된 쪽을 고르면 장애 대응을 낭비합니다.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

세 번째 명령은 주의 깊게 읽을 가치가 있습니다. 평범한 웹 페이지의 200은 웹 서비스가 있다는 것만 알려주며, SSTP 요청이 이해될 것인지는 알려주지 않습니다. 같은 주소의 404도 VPN에 대해 그만큼 정보가 없습니다. 오직 클라이언트 로그만이 네 단계 중 어디에 도달했는지 알려줍니다.

각 명령이 어떤 이름을 사용했는지 보세요. 인증서는 보내는 이름으로 선택되므로, 프로필과 테스트 사이의 불일치는 당신이 들여온 불일치입니다. 그 이름을 결과 옆에 적어 두면 나중의 혼란을 막습니다.

부분적 성공을 올바른 방향으로 읽어라

중간 장치는 일반 브라우징을 허용하면서 이후 교환을 거부할 수 있으며, 그래서 웹사이트에 작동하는 프록시가 터널에는 실패할 수 있습니다. 같은 패턴은 인증서가 브라우저 이름에는 유효하지만 프로필에 설정된 이름에는 유효하지 않을 때 나타납니다. 브라우저는 만족하고 클라이언트는 만족하지 않으며, 둘 다 자기가 확인한 것에 대해서는 옳습니다.

이것을 진단하는 동안 서버 검증을 켜 두세요. 끄면 인증서 불일치가 성공적인 핸드셰이크로 바뀌고, 실패를 설명했을 유일한 증거가 숨겨집니다.

같은 프로필이 다른 네트워크에서 작동한다면 차이는 경로에 달려 있습니다. 그러면 중간 장치로 범위가 좁혀지지만 어느 것인지는 알 수 없고, 그래도 유용한 진전입니다. 사용한 네트워크를 기록하세요. 그것이 없으면 비교는 무의미합니다.

그다음 세션이 아니라 애플리케이션을 시험하라

세션이 있으면 그것이 필요한 클라이언트에서 의도한 경로, 이름 해석, 서비스 권한을 확인하세요. 연결된 터널에도 반대편의 전달 누락이나 존재한 적 없는 반환 경로가 있을 수 있으며, 기다리는 사람에게 그런 실패는 정확히 애플리케이션 문제처럼 보입니다.

모든 결론을 그것을 만들어 낸 단계에 붙여 두세요. 열린 포트를 작동하는 VPN이라고 부르는 것이 바로 다섯 분짜리 인증서 점검을 하루짜리 소프트웨어 재설치로 만드는 방법입니다.