Windows VPN 오류 코드: 어느 단계가 실패했고 무엇을 기록할지

실패 후 Windows VPN 대화 상자를 열면 번호와 문장이 나오는데, 그 문장은 보통 덜 유용한 절반입니다. 번호는 연결의 어느 단계가 실패했는지 알려 주고, 단계는 다음에 어떤 로그와 어떤 설정, 어떤 팀을 볼지 결정합니다. 단계를 차례로 훑는 데는 약 십 분이 걸리며, 애초에 다이얼 권한이 없던 계정을 고치려고 어댑터를 다시 설치하고 프로토콜을 바꾸고 스택을 초기화하는 익숙한 순서를 막아 줍니다.

번호를 단계로 읽기

네이티브 연결은 네 개의 이정표를 지납니다. 서버에 도달해 링크를 세우고, 보안을 협상하고, 사용자를 인증하고, 주소 지정과 라우팅을 적용합니다. 각 단계의 실패는 서로 다른 증거를 남기며, 한 단계에 속한 코드는 다른 단계에 대해 유용한 것을 말해 주지 않습니다.

피해야 할 실수는 코드를 심각도로 취급하는 것입니다. 링크 실패와 권한 부여 실패는 둘 다 "연결할 수 없음"으로 읽히고, 그 외에 공통점이 없습니다. 심각도는 얼마나 긴급한지를 말하고, 단계는 무엇을 열어야 하는지를 말합니다.

첫 번째 단계: 링크와 다이얼 시도

829는 기반 링크가 끊겼다는 뜻입니다. 원격 피어가 응답을 멈췄는지, 중간 장비가 세션을 죽였는지, 클라이언트의 정책이 닫았는지는 알려 주지 않습니다. 703 같은 다이얼 완료 코드는 더 이르며, 시도가 링크를 가질 만큼 나아가지 못했으므로 보통 프로필, 서비스 상태 또는 로컬 정책을 가리킵니다.

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

이벤트 쿼리는 사람들이 건너뛰는 부분입니다. 타임스탬프와 인터페이스 이름이 있는 클라이언트 측 기록은 시도가 기기 밖으로 나가기라도 했는지 알려 주므로 대화 상자보다 값어치가 있습니다. 기록도 없고 수신기의 응답도 없다면 도달성 문제이며, 클라이언트를 아무리 편집해도 바뀌지 않습니다.

같은 프로필이 다른 네트워크에서 동작한다면 여기서 멈추십시오. 이 코드는 구성 오류가 아니라 경로 조건을 설명하며, 다음의 유용한 비교는 또 한 번의 재설치가 아니라 두 개의 캡처입니다.

두 번째 단계: PPP와 미니포트 바인딩

720은 링크와 사용자 사이에 있습니다. 터널이 올라온 뒤 PPP 계층이 주소나 제어 프로토콜을 협상하지 못했는데, 이는 흔히 클라이언트의 바인딩 문제이지 자격 증명 거부가 아닙니다. 그 구분이 이 코드의 가치 전부여서 자격 증명까지 도달하지 못했다고 말하므로 계정은 용의자가 아닙니다.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

그 두 출력을 읽는 편이 무엇이든 초기화하는 것보다 정보가 많습니다. 존재하지만 시작되지 않은 미니포트, 또는 다른 소프트웨어가 사용하지 않도록 설정한 프로토콜 바인딩은 정확히 이 단계의 실패를 만듭니다. 둘 다 스택의 나머지를 건드리지 않고 고칠 수 있습니다. 반대로 전체 초기화는 결함과 무관한 주소 지정과 필터 상태를 지웁니다.

세 번째 단계: 신원과 권한 부여

691은 자격 증명이 거부되었다는 뜻입니다. 649는 계정에 다이얼 권한이 없다는 뜻이고, 812는 원격 액세스 정책이 연결을 거부했다는 뜻입니다. 이것은 결정이며 전송 결함이 아니므로, 클라이언트는 보고만 할 수 있습니다.

증거는 반대편에 있습니다. 게이트웨이 운영자에게 그 타임스탬프의 시도와 일치한 정책을 묻고, 디렉터리 소유자에게는 계정에 다이얼 권한이 있는지, 정책이 요구하는 그룹에 있는지 물으십시오. 터널 유형을 바꾸거나 클라이언트를 다시 설치해도 신원에 대해 내려진 결정은 바뀌지 않습니다.

이 단계에서 유용한 습관은 도메인 접두사를 포함해 정확한 계정 문자열을 티켓에 적는 것입니다. 놀랄 만큼 많은 691 사례가 잘못된 도메인에 저장된 자격 증명이며, 그것은 프로토콜 설정이 아니라 계정 문자열에 드러납니다.

네 번째 단계: 연결되었는데 아무것도 되지 않음

연결이 완료되어도 쓸모없을 수 있습니다. 주소는 있고 클라이언트는 성공을 보고하며, 애플리케이션의 모든 요청은 시간 초과됩니다. 대화 상자에는 그것이 전혀 드러나지 않고 살펴볼 코드도 없습니다. 그 시점에 대화 상자는 끝났고 유용한 증거는 다른 곳에 있습니다.

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

경로가 없으면 서버가 밀어 주지 않았거나 클라이언트가 버린 것입니다. 경로가 있고 이름 확인이 실패하면 해석이 문제입니다. 둘 다 되는데 애플리케이션이 여전히 실패하면 터널을 지나 애플리케이션 자체의 구성에 들어간 것입니다.

변경은 테스트당 한 계층으로 유지하십시오. 다음 시도 전에 한 모든 편집이 다음 코드의 문맥 일부가 되며, 마지막 편집을 설명하는 코드는 코드가 없는 것보다 나쁩니다.

한 번의 시도, 한 번의 변경, 한 건의 기록

어느 단계든 기록에는 코드, 메시지, 프로필 이름, 타임스탬프, 그리고 있었던 네트워크가 들어가야 합니다. 다섯 개 필드이며, 모두 이미 대화 상자나 클라이언트 로그에서 눈앞에 있습니다. 그 집합은 티켓에 붙여 넣을 만큼 작고 다른 사람이 재현할 만큼 구체적입니다.

그다음 그 타임스탬프를 반대편 기록 옆에 두십시오. 이 페이지 위쪽의 표가 각 불일치가 어느 단계의 것인지 말해 줍니다. 두 번째 기록이 없으면 코드는 검색을 좁힐 뿐이고, 있으면 단계가 판정됩니다. 추측이 아니라 진단으로 만드는 것이 바로 이 비교입니다.

그 습관은 Windows의 거의 모든 네이티브 VPN 결함을 포괄하며, 어느 분기도 무엇인가를 다시 설치할 것을 요구하지 않습니다. 대화 상자는 늘 어느 것인지 알려 주고 있었으므로, 일은 그것들을 모두 같은 문제로 취급하지 않는 데 있습니다.