Windows 기본 제공 VPN이 공급업체의 SSL 게이트웨이에 도달하지 못하는 이유

Windows에는 네 가지 터널 유형만 있고 공급업체의 SSL 게이트웨이는 그중 하나가 아닙니다. 그래도 기본 제공 프로필을 이런 게이트웨이로 지정하면 자격 증명을 묻기도 전에 연결이 실패하며, 보통 로컬 시스템에서 연결이 종료되었다는 메시지가 나옵니다. 그 문구는 불일치의 신호이며 진단이 아닙니다. 프로필 유형과 해당 프로토콜을 소유한 클라이언트가 일치해야 하며, 둘 중 하나가 빠져 있습니다.

네 가지 유형과 하나의 대화 상자

저장된 모든 프로필은 터널 유형을 가집니다. 기본 제공 클라이언트가 받아들이는 것은 PPTP, L2TP, IKEv2, SSTP와 이들을 순서대로 시도하는 자동 모드입니다. 범용 SSL VPN 항목은 없고 대화 상자로 추가할 방법도 없습니다. 공급업체 게이트웨이는 TLS 위에서 자체 애플리케이션 프로토콜을 사용하며, 이를 구현한 것은 해당 공급업체의 클라이언트뿐입니다.

목록은 명령 하나 거리에 있으며 다른 어떤 문제 해결보다 먼저 실행할 가치가 있는데, 잠깐이면 끝나고 잘못된 가정을 통째로 한 부류 없앨 수 있기 때문입니다:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

프로필이 SSTP라고 하고 게이트웨이가 RRAS 서버가 아니라면 불일치는 이미 확정된 것입니다. 인증서나 방화벽 작업으로는 바뀌지 않습니다.

SSTP와 공급업체 TLS는 443 포트에서 똑같아 보입니다

SSTP는 PPP 세션을 TLS 안에 감싸고 TCP 443으로 이동합니다. Microsoft 스택에서는 RRAS가 이를 종료하며, 클라이언트가 검증하는 서버 인증서를 제시합니다. Fortinet, Citrix, Pulse 어플라이언스도 443에서 TLS를 종료하며, 그 포털은 어떤 브라우저에서든 문제없이 열립니다.

그 브라우저 테스트가 증명하는 것은 도달 가능성이지 호환성이 아닙니다. 포털 뒤의 세션 프로토콜은 공급업체의 것이고 기본 제공 클라이언트에는 그 구현이 없습니다. 공급업체가 자체 클라이언트를 제공하는지가 불일치의 어느 절반을 다루는지 알려 줍니다.

반대 방향의 혼동도 생깁니다. SSTP로 구성한 프로필을 정품 RRAS 서버에 연결하면 포털은 멀쩡한데 인증서 검증에서 실패할 수 있으며, 이는 프로토콜 문제가 아니라 인증서 문제입니다.

터널이 생기기 전에 나타나는 오류

800번대 코드는 어떤 터널도 수립되기 전에 보고되므로 방화벽 규칙으로는 거의 바뀌지 않습니다. 오류 812는 클라이언트가 제시한 인증 방법을 서버 쪽 정책이 거부하는 것입니다. 같은 범위의 나머지는 네트워크가 아니라 로컬 연결 관리자에서 나옵니다.

무엇이든 다시 만들기 전에 추적을 켜십시오. 추적은 실패한 단계를 이름으로 알려 주며, 단계 이름은 대화 상자 문구보다 값어치가 있습니다:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

추적은 추적 디렉터리에 남아 지울 때까지 유지되므로, 몇 주씩 켜 두지 말고 나중에 끄십시오.

연결된 프로필도 모든 것을 망가뜨릴 수 있습니다

연결은 되지만 그다음 브라우징이나 로컬 공유, 컨테이너 엔진이 깨지는 프로필은 터널 문제가 아니라 라우팅 문제입니다. 기본 게이트웨이가 터널로 옮겨졌으므로 이제 모든 목적지가 해당 경로를 라우팅하지 않을 수 있는 피어를 거칩니다.

두 가지 제어가 이를 결정합니다. 하나는 프로필의 분할 터널링 속성입니다. 다른 하나는 원격 네트워크의 기본 게이트웨이를 사용하는 어댑터별 옵션이며, IPv4 고급 설정에 있습니다.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

경로를 추가하지 않고 분할 터널링을 켜면 연결은 되지만 아무 곳에도 도달하지 못하는 터널이 됩니다. DNS를 확인하지 않고 끄면 어댑터 자체의 접미사와 서버가 사용되지 않아 내부 이름이 공용 응답으로 확인됩니다.

배관을 먼저 확인하고 그다음 유형을 확인하십시오

이 순서로 작업하고, 모든 것을 한꺼번에 조정하지 말고 단계가 실패하면 멈추십시오:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

첫 명령은 도달 가능성과 프로토콜을 분리합니다. 두 번째는 프로필이 무엇이라고 주장하는지 확인합니다. 경로 테이블은 터널이 기본 경로를 가져갔는지 보여 줍니다. 전화 걸기 명령은 연결 관리자 자체의 오류를 보고하며, 이는 대화 상자보다 명확한 경우가 많습니다.

티켓에 터널 유형, 게이트웨이 제품, 정확한 오류를 기록하십시오. 그러면 다음 사람은 몇 분 안에 이것이 프로토콜 불일치인지, 인증서 실패인지, 라우팅 결정인지 알 수 있고 “VPN이 안 된다”에서 시작하지 않아도 됩니다.