Windows VPN이 연결되지 않나요? 코드를 이벤트 로그와 맞춰 보세요

금요일에는 작동했다. 월요일, 같은 Windows 클라이언트는 연결 시도가 실패했다는 대화 상자를 띄우고, 그 아래 문장은 수십 가지 무관한 문제에서 이미 본 문장이다. 그 대화 상자는 사슬의 끝이지 시작이 아니다. Windows는 시도가 실제로 죽은 단계를 숨기며, 두 가지 작은 증거 — 숫자 결과 코드와 같은 분의 RasClient 이벤트 하나 — 가 그것을 지목한다. 내가 쓰는 순서는 이렇다 — 시도를 고정하고, 코드를 읽고, 이벤트를 가져온 다음, 정확히 한 계층만 바꾼다.

대화 상자의 문구는 마지막 단계이지 원인이 아니다

읽고 있는 문장은 시도가 이미 풀린 뒤에 선택된다. "연결이 설정되기 전에 원격 컴퓨터에서 연결이 종료되었습니다"는 서버가 협상 중간에 끊었을 때, 사용자 이름이 전송되기 전에 IPsec이 실패했을 때, 정책이 터널을 곧바로 거부했을 때 나타난다. 서로 다른 세 주인, 하나의 문장. 문구를 증상 분류로 다루고, 코드가 동의할 때까지 그것이 아무것도 이끌지 못하게 하라.

아직 고정할 수 있는 것은 시도 자체다. 연결 이름, 프로필에 저장된 터널 유형 — PPTP, L2TP/IPsec, SSTP 또는 IKEv2 —, 초 단위의 시각, 그리고 코드를 적어 두라. 실제로 어떤 프로토콜이 돌았는지 확실하지 않다면 기억을 믿는 대신 %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk을 열어 항목을 읽어라 — 새 프로토콜에 재사용된 프로필은 예전 표시 이름을 그대로 유지한다.

말을 읽기 전에 숫자를 읽어라

코드는 세 단계로 나뉘며, 단계가 정확한 문구보다 중요하다 — 도달했지만 거부된 인증 교환, 결코 응답하지 않은 서버, 또는 링크가 올라온 뒤 무너진 협상이다. 691은 첫 번째 종류다 — 자격 증명 검사가 돌았고 실패했으며, 잘못된 비밀번호, 잠겼거나 만료된 계정, 또는 서버가 받아들이지 않는 인증 프로토콜 때문이다. 812도 거부이지만 자격 증명은 유효하고, 원격 액세스 서버의 정책이 당신에게 반대하여 결정한 것이다. Microsoft는 정본 전화 접속 및 VPN 연결 오류 코드 목록을 유지하며, 메시지 본문을 검색하기 전에 그곳에서 자기 번호를 읽어 볼 가치가 있다.

809은 반대 분류다 — 아무것도 돌아오지 않았다. 이것은 경로 문제다 — SSTP에는 TCP 443이 필터되고, PPTP에는 GRE가 차단되며, IPsec 통과에는 UDP 500과 4500 또는 ESP가 버려진다. 새 비밀번호로는 고칠 수 없고 새 인증서로도 안 된다. 720는 링크가 올라왔고 PPP가 협상을 끝내지 못했다는 뜻이며, 프로토콜 불일치나 주소를 할당하지 못한 서버를 가리킨다. 789, 또는 IKEv2에서는 13801은 IPsec 내부의 신원이다 — 다이얼하는 이름과 맞지 않는 주체의 인증서, 신뢰되지 않는 체인, 또는 양 끝에서 다른 사전 공유 키다.

같은 분의 RasClient 이벤트를 가져와라

이벤트 뷰어에서 소스 RasClient로 필터한 Windows Logs > Application이 가장 먼저 볼 곳이다. 오류 720에 관한 Microsoft의 문서는 그 로그의 이벤트 20227를 가리킨다. 같은 공급자는 다른 결과에 다른 식별자를 내보내므로, ID를 진단으로 여기지 말고 메시지와 그 안에 들어 있는 결과 코드를 읽어라 — 일반적인 대화 상자에 720을 담은 20227이 더해지면 이미 훨씬 좁은 이야기다.

PowerShell에서 GUI를 클릭하지 않고:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

빈 결과는 정보가 된다. 보통 다이얼이 RAS가 무언가를 기록할 만큼 멀리 가지 못했거나, 실패한 소프트웨어가 애초에 네이티브 클라이언트가 아님을 뜻한다 — 타사 클라이언트는 자체 진단을 유지하며 Application 로그에 아무것도 쓰지 않는 경우가 많다. 이벤트 로깅이 망가졌다고 결론 내리기 전에 공급업체의 로그를 확인하라.

이벤트 더미 대신 하나의 타임라인을 만들어라

재시도 루프는 소음을 만든다. 자동 재연결 다섯 번은 이벤트 무리를 남기고, 그것을 하나의 원인을 가진 하나의 연속으로 읽고 싶은 유혹이 생긴다. 그것은 다섯 번의 별개 시도이며, 서버에 닿은 것은 일부뿐이다. 두세 분의 창과 하나의 연결 이름을 잡고, 무엇이든 해석하기 전에 각 이벤트를 자기 코드와 함께 나열하라.

그다음 시도가 어디서 멈췄는지 물어라. 게이트웨이나 인증 백엔드가 그 타임스탬프에 대한 기록을 전혀 갖고 있지 않다면 클라이언트는 거기에 닿지 못한 것이고, 당신은 도달 가능성 문제를 보고 있다. 백엔드가 요청과 거부를 보여 준다면 결정은 거기서 내려졌고, 자격 증명 또는 정책 분류가 적용된다. 시각을 비교하기 전에 시계를 비교하라 — 클라이언트는 현지 시각을 보고하고 많은 게이트웨이는 UTC로 기록하며, 차이는 완벽하게 상관된 쌍을 무관해 보이게 만든다.

재현 가능한 캡처를 위해 명령줄에서 다이얼하고 결과를 출력하게 하라:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

콘솔은 GUI가 친절한 문구 뒤에 숨기는 번호를 보여 주며, 두 번 실행하면 코드가 안정적인지 간헐적인지 알 수 있다.

각 단계가 무엇을 바꾸라고 말하는가

단계를 명명하는 것은 변경 집합을 하나의 계층으로 줄일 때만 유용하다:

• 691 — 인증: 클라이언트가 제시하는 EAP 방식과 서버가 받아들이는 방식, 계정 상태, 비밀번호 만료, 다이얼인 권한.
• 812 — 서버 정책: 이 사용자와 이 시간 창에 맞는 원격 액세스 정책 또는 NPS 규칙.
• 809 — 도달 가능성: 경로상의 방화벽 규칙, NAT와 프로토콜 통과, 선택한 터널 유형에 필요한 포트.
• 720 — PPP 협상: 인증 프로토콜 불일치, 주소 할당, 서버 측 PPP 설정.
• 789 / 13801 — IPsec 신원: 다이얼하는 이름에 대한 인증서 주체, 신뢰 체인, 사전 공유 키.

그중 하나를 바꾸고, 같은 프로필을 다시 시험하고, 새 코드를 적어 두라. 변경 후 다른 코드는 모순이 아니라 진전이다 — 실패를 더 뒤 단계로 옮긴 것이고, 다단계 핸드셰이크를 고치는 모습이 그렇다. 하지 말아야 할 것은 방화벽과 인증서와 비밀번호를 한 자리에서 바꾸고 마지막에 온 것에 공을 돌리는 일이다.

증거를 공유하고 환경은 공유하지 마라

이벤트 메시지는 보이는 것보다 풍부하다. 연결 이름, 계정, 흔히 게이트웨이의 내부 이름이나 주소, 때로는 인증서 지문을 담는다. 원본은 있어야 할 곳에 두고, 다른 누구를 위해 별도로 가린 사본을 만들어라 — 타임라인을 기억에서 다시 타이핑하면 그것을 유용하게 만드는 세부가 정확히 사라진다.

실제로 처리될 인수인계에는 다섯 필드가 필요하다 — 코드, 그것이 속한 단계, 클라이언트와 터널 유형, 시간대가 붙은 타임스탬프, 그리고 게이트웨이가 요청을 아예 보았는지 여부다. 나머지는 선택 사항이다. 그 다섯이 있으면 다음 사람은 조사를 반복하지 않고 자격 증명 논쟁과 라우팅 논쟁을 구분할 수 있다.

무엇이든 닫기 전에 같은 프로필에서 시도를 다시 재생하고 코드가 지금 어디에 떨어지는지 확인하라. 성공하면 끝이고, 다른 실패라면 원래 단계는 고쳐졌으며 다음 단계가 손에 있다.