SSTP 대 OpenVPN: 같은 포트 443, 다른 프로토콜

두 옵션 모두 TCP 443 뒤에 놓일 수 있어서 사람들은 서로 바꿔 쓸 수 있는 끝점이라고 생각합니다. 실제로는 아닙니다: SSTP 서버는 HTTPS 안에서 PPP를 말하고, OpenVPN 서버는 TLS 위나 원시 UDP 흐름으로 자체 프로토콜을 말합니다. 한 클라이언트를 다른 쪽 포트로 향하게 하면 로그인 프롬프트에 절대 도달하지 못하는 연결이 됩니다. 선택의 기준은 어떤 클라이언트와 전송을 지원할 수 있는지이며, 번호가 아닙니다.

공유 포트가 공유 프로토콜을 만들지는 않는다

TLS 핸드셰이크가 완료되어도 다음에 무엇을 말할지 클라이언트와 서버가 합의하지 못해 아무 데도 갈 수 없습니다. 패킷 캡처에서는 깔끔한 핸드셰이크 뒤에 상대가 거부하거나 무시하는 애플리케이션 데이터가 이어지는 것을 봅니다. 이 패턴은 프로토콜 불일치의 서명이며 방화벽 차단이 아닙니다.

이름을 바꾼 프로필도, 다른 메뉴 항목도 하나를 다른 하나로 바꾸지 않습니다. SSTP 연결은 Windows VPN 설정에서 서버 주소와 운영자의 인증 정보로 만들어지고, OpenVPN 연결에는 클라이언트와 일치하는 구성 파일이 필요합니다. Microsoft의 SSTP 사양 은 전자를 설명하며 OpenVPN 핸드셰이크는 설명하지 않습니다.

포트 443은 정책상의 편의입니다. 다른 것을 거의 허용하지 않는 네트워크를 통과하며 그것은 실제 이점이지만, 그 뒤에서 어떤 프로토콜이 도는지는 알려주지 않습니다.

SSTP는 HTTPS 안에서 PPP를 터널링한다

이름이 구조를 설명합니다. HTTPS 세션 안에서 운반되는 PPP 프레임, 즉 아래에 TLS가 있고 클라이언트가 확인할 수 있는 인증서가 있습니다. Windows는 이를 기본 VPN 유형으로 포함하므로 관리되는 노트북은 운영자가 제공한 프로필 외에 추가 소프트웨어 없이 연결할 수 있는 경우가 많습니다.

다른 플랫폼은 다른 이야기입니다. Linux나 macOS 클라이언트에는 유지 관리되는 구현이 필요하며, 무엇을 지원하고 오류를 어떻게 보고하는지는 구현마다 다릅니다. Windows의 내장 기능이 그대로 넘어온다고 가정하지 말고 실제로 사용할 클라이언트를 확인하며, 프로필의 서버 이름이 서버가 제시하는 인증서와 일치하는지 확인하세요.

SSTP는 보통 TCP만 사용합니다. 그 단일 전송은 손실이 있는 링크에서의 동작에 영향을 줍니다. 재전송이 터널 안에서도, 그 아래에서도 일어나기 때문입니다.

OpenVPN은 자체 클라이언트와 전송 선택을 함께 제공한다

OpenVPN은 자체 클라이언트와 프로필을 제공하므로 기본 Windows 대화상자가 보여주지 않는 진단 정보를 얻을 수 있습니다. 서버는 UDP 또는 TCP에서 수신할 수 있고, 어느 것을 쓸지는 운영자의 구성이 결정합니다. 잘못된 전송을 향한 프로필은 인증 전에 실패합니다.

인증도 마찬가지로 구성에 달려 있습니다. 배포는 인증서만, 인증서에 사용자 이름과 비밀번호, 또는 그 위에 두 번째 요소를 요구할 수 있으며 클라이언트는 그 구성과 정확히 일치해야 합니다. 연결이 TLS 단계에 도달한다고 해서 다음에 어떤 자격 증명을 요구할지는 알 수 없습니다.

UDP가 일반적인 기본값인 이유는 신뢰할 수 있는 흐름을 또 다른 신뢰할 수 있는 흐름 안에 중첩하지 않기 때문입니다. TCP 모드는 UDP를 차단하는 네트워크를 위해 존재하고 작동하지만, 손실이 심하면 대체한 UDP 경로보다 더 나쁘게 느껴질 수 있습니다. 꼭 필요할 때 TCP를 선택하고, 더 신뢰할 수 있게 들린다는 이유로 선택하지 마세요.

클라이언트, 전송, 지원으로 선택한다

세 가지 질문이 이 결정의 대부분을 정리합니다. 모든 클라이언트 기기에 추가 소프트웨어 없이 작동하는 연결이 필요한가? 의존하는 네트워크가 UDP를 허용하는가, 아니면 TCP 443이 유일한 출구인가? 그리고 프로필이 만료될 때 클라이언트와 그 업데이트, 복구를 누가 지원하는가?

둘을 비교할 때는 같은 기기와 같은 액세스 네트워크에서 시험하세요. SSTP 끝점과 OpenVPN 끝점이 다른 서버나 다른 사이트라면 결과에는 프로토콜을 분리하는 대신 그 경로와 머신이 포함됩니다. 이런 비교가 자신감은 있지만 틀린 답을 내는 가장 흔한 방식입니다.

그런 다음 다른 무엇을 디버그하기 전에 실제로 어느 쪽을 세웠는지 확인하세요:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

어느 쪽이든 터널 상태에서 성공을 선언하는 대신 필요한 리소스와 DNS를 시험하며 마무리하세요. 두 프로토콜 모두 선택된 사설 트래픽만 나르도록 구성할 수 있고, 이름 해석이 작동하지 않는 연결된 터널은 실제로는 분할 터널이나 DNS 설계인데도 고장 난 VPN처럼 보입니다.

관리되는 함대에서는 프로필 배포와 업데이트 지원이 어떤 전송 벤치마크보다 훨씬 먼저 이 질문을 결정합니다.