Windows VPN 주소 필드의 포트는 SSTP에서만 동작합니다

VPN 서버가 TCP 10443에서 응답하고 Windows 기본 클라이언트의 자격 증명도 올바른데도 DNS 타임아웃처럼 보이는 멈춤 뒤에 연결이 끊깁니다. 원인은 대개 주소 필드로, vpn.example.com:10443을 서버 이름 또는 주소에 입력하면 Windows가 문자열 전체를 호스트 이름으로 읽습니다. 이 필드는 일반적인 host:port 입력이 아니어서 포트를 여기에 쓸 수 있는지는 프로필이 쓰는 터널 종류에 달려 있고, 네 종류 가운데 하나만 값을 해석할 수 있는 형태로 취급합니다.

주소 필드가 host:port 필드가 아닌 이유

이 필드 뒤에 있는 프로필 속성은 ServerAddress이며 터널 종류마다 문자열을 다루는 방식이 다릅니다. 세 종류에는 채울 포트 매개변수가 없어서 콜론과 숫자는 해석되지 않는 이름 속 글자에 지나지 않습니다. 네 번째는 HTTPS 위에서 동작하고 포트가 URL의 일부이므로 값이 URL로 해석되는 형식으로 쓰여야 합니다.

그래서 실패가 연결 거부가 아니라 이름 확인처럼 보입니다. 보고할 잘못된 포트는 없고 존재하지 않는 호스트 이름만 있으며, 오류는 확인자가 포기한 뒤에 도착합니다. 서버를 건드리기 전에 프로필이 어떤 터널 종류를 쓴다고 하는지 확인하십시오.

포트가 고정된 세 종류

PPTP는 TCP 1723에 접속한 뒤 터널을 GRE, IP 프로토콜 47로 나릅니다. L2TP/IPsec는 터널에 UDP 1701을, IPsec에 UDP 500과 4500을 사용하며 4500은 NAT 통과용 포트입니다. IKEv2도 UDP 500과 4500을 사용합니다. 이 프로필들은 인터페이스 어디에도 포트 필드를 노출하지 않으며 비표준 포트를 협상하지도 않습니다.

따라서 사용자 지정 포트에서 수신하는 서버는 주소를 어떻게 쓰든 이 프로필들에서는 도달할 수 없습니다. 실무적인 답은 좁아서, 서버에서 표준 포트를 공개하거나 앞단의 라우터에서 표준 포트를 사용자 지정 포트로 변환하는 것입니다. 둘 다 클라이언트 프로필을 그대로 두며, 프로필을 직접 입력하지 않고 정책으로 배포할 때 큰 가치가 있습니다.

SSTP에는 이름이 아니라 URL이 필요합니다

SSTP는 TLS 세션 안에서 동작하기 때문에 예외입니다. 이 필드는 URL로 해석되어야 하며 먼저 https:// 스킴, 다음 호스트, 그다음 콜론과 포트가 옵니다. 스킴이 없으면 Windows는 값을 그냥 이름으로 취급하고 TLS 교환이 일어나기 전에 연결이 실패합니다.

사람들이 놀라는 이유는 기본 포트라면 호스트 이름만으로도 받아 주기 때문입니다. 사용자 지정 포트가 한 번도 필요 없었던 프로필은 이 규칙을 가르쳐 주지 않고 처음 추가한 사람은 실패를 통해 알게 되므로, 저장한 뒤에는 대화 상자를 믿지 말고 저장된 값을 다시 읽으십시오.

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress는 저장된 내용을 그대로 보여 줍니다. 콜론이 들어간 맨 호스트 이름으로 읽힌다면 그 프로필은 URL을 받은 적이 없고, 몇 번을 다시 시도해도 고쳐지지 않습니다.

같은 필드에 붙여 넣는 공급업체 구문

일부 게이트웨이는 포트 뒤에 붙는 realm이나 인증서 처리를 바꾸는 쿼리 매개변수처럼 이 필드에 대한 추가 관례를 문서화합니다. 그것들은 해당 공급업체 서버와 일부 빌드에서는 자사 클라이언트가 이해합니다. Windows 프로필 형식의 일부가 아니며, 기본 제공 프로필에 붙여 넣으면 대개 같은 조용한 이름 실패가 생깁니다.

인증서 검증을 끄는 매개변수는 수정이 아니라 경고로 다루십시오. 그 매개변수로만 연결된다면 인증서가 사용 중인 이름과 맞지 않는 것이고, 올바른 수리는 클라이언트가 아니라 게이트웨이에서 해야 합니다. 포트 뒤의 realm도 같은 성질로, 반대편 서버가 기대할 때만 의미가 있습니다.

포트를 입증하고 실패 단계를 읽으십시오

프로필을 탓하기 전에 클라이언트 네트워크에서 해당 포트로 TCP를 받아 주는 것이 있는지 확인하십시오:

Test-NetConnection vpn.example.com -Port 10443

성공은 수신 대기가 있음을 증명할 뿐 SSTP를 증명하지 않습니다. 웹 서버나 역방향 프록시, 로드 밸런서는 TCP 핸드셰이크를 마치고도 SSTP를 말하지 않을 수 있으므로 테스트가 초록색인데 VPN이 빨간색인 것은 실제 조합입니다. 인증서 주체를 프로필의 이름과 비교하고, 포함된 빌드에서는 일반 타임아웃이 아니라 실패한 단계가 기록되는 RasClient 로그를 확인하십시오.

그다음 문제를 문서화하는 대신 없애는 선택지로, 외부의 TCP 443을 VPN 서버의 10443으로 전달하는 방법을 검토하십시오. 그러면 클라이언트는 포트를 전혀 쓰지 않는 기본 프로필을 사용하고, 관리되는 기기 집단에서는 대개 가장 깔끔한 구성이며 사용자 지정 포트는 내부 세부 사항으로 남습니다.