Windows의 VPN 오류 720: 주소 풀인가 클라이언트 바인딩인가?
오류 720은 연결이 사용 가능한 주소를 한 번도 받지 못했다는 뜻입니다. 어댑터를 다시 설치하기 전에 한 호스트의 장애와 여러 호스트의 장애를 구분하십시오.
오류 720은 자격 증명이 수락된 뒤에 나타나며, 그래서 사람들을 암호 필드로 되돌려 보냅니다. 연결은 주소를 협상하는 지점까지 갔지만 주소를 받지 못했습니다. 아주 다른 두 가지 장애가 같은 대화 상자를 만듭니다. 서버에 나눠 줄 것이 없었거나, 이 클라이언트가 협상을 끝내지 못한 경우입니다. 무엇이든 건드리기 전에 이 둘을 구분하는 것이 복구의 대부분이며, 그 구분은 Microsoft의 오류 720 문제 해결 페이지에 문서화되어 있습니다.
대화 상자가 말하지 않는 것
메시지는 PPP 협상의 실패를 설명하며, 클라이언트가 서버가 거부한 이유를 볼 수 없기 때문에 의도적으로 모호합니다. 자격 증명 오류가 아니고 터널 암호화에 대한 진술도 아닙니다. 주소나 협상 매개변수가 전달되지 않았다는 뜻입니다.
서버 쪽의 흔한 원인은 할당입니다. 빈 주소가 없는 RRAS 정적 풀이나 범위가 고갈되었거나 도달할 수 없는 DHCP 구성은 시도하는 모든 클라이언트에 똑같은 증상을 냅니다. 클라이언트 쪽의 흔한 원인은 바인딩입니다. PPP를 운반하는 WAN Miniport는 올바른 구성 요소에 바인딩되어야 하며, 비활성화된 바인딩이나 삽입된 네트워크 필터는 눈에 보이는 장치 문제 없이 협상을 멈출 수 있습니다. 이 두 계열은 서로 다른 증거를 필요로 하며, 둘 중 하나를 고르는 가장 빠른 방법은 영향을 받는 클라이언트 수를 세는 것입니다.
먼저 모집단을 나누고, 그다음 풀을 보십시오
어떤 구성도 읽기 전에 영향을 받는 클라이언트를 세십시오. 모두를 한 번에 때리는 장애는 서버 상태이고, 한 머신을 네트워크 사이로 따라가는 장애는 클라이언트 상태입니다. 그 세기는 채팅 채널의 메시지 하나면 되고 오후 하나를 아낍니다.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
그다음 실패한 시도 하나를 서버 자체의 기록과 맞춰 보십시오. RRAS는 할당할 수 없을 때 이벤트를 기록하고 그 이벤트는 증상이 아니라 장애를 지목하기 때문입니다. 장애가 특정 클라이언트를 따라간다면 서버 로그는 그 시도에 대해 아무것도 보여 주지 않으며, 그 자체가 정보입니다. 할당 오류가 없다는 것은 문제를 그 클라이언트의 협상으로 좁히고 다음에 어떤 명령을 실행할지 알려 줍니다.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }서버의 할당 상태 읽기
RRAS 쪽에서는 문서가 가정하는 방식이 아니라 실제로 구성된 할당 방식을 확인하십시오. 정적 풀과 DHCP로 전달되는 구성은 서로 다른 방식으로 실패하며, 수정은 사용 중인 쪽에 속합니다. 정적 풀에서는 빈 주소를 세고, 아무도 기억하지 못하는 임대를 보유한 사용자별 할당을 찾으십시오. 커 보이는 풀이 완전히 점유되어 있을 수 있기 때문입니다. DHCP에서는 릴레이가 서버에 도달하는지, 범위에 빈 임대가 있는지 확인하십시오.
일반 클라이언트가 고갈시킨 범위는 잘못 구성된 풀과 같은 720을 내며, RRAS 콘솔은 두 경우 모두 완전히 건강해 보입니다. 풀을 더 작은 범위로 쪼개는 물려받은 우회책에 저항하십시오. 원래 조언은 관리자 한 사람의 결과를 설명한 것이며, 서버 자체의 이벤트가 직접 지목할 수 있는 할당 장애를 고치지 않습니다.
클라이언트 바인딩을 깨지 않고 읽기
증거가 클라이언트 하나를 가리키면 스택을 다시 설치하는 대신 숨은 어댑터를 살펴보십시오. 첫 번째 명령은 WAN Miniport 인터페이스와 그 이름을 나열하고, 두 번째는 그것이 반환한 이름을 씁니다. 가이드에서 베낀 이름이 아닙니다.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindings목록은 주소 확인 바인딩과 타사 필터에 대해 읽으십시오. 비활성화된 바인딩은 표적 복구이며, 필터의 존재는 그 소프트웨어 소유자에게 할 질문이지 보안 제품을 끌 권한이 아닙니다. 모든 어댑터를 삭제하는 것은 장애가 돌아올 때 필요할 증거를 파괴하는 유일한 동작입니다.
수정 후 같은 프로필을 다시 시도하고, 그것이 원래 증상이었다면 두 클라이언트 사례를 반복하십시오. 첫 연결이 성공하면 두 번째 클라이언트가 드러내는 할당 문제가 가려지기 때문입니다. 기록은 네 칸으로 유지하십시오. 어느 클라이언트, 어느 바인딩, 어느 이벤트, 무엇이 바뀌었는지입니다. 시도마다 한 계층만 바꾸십시오. 클라이언트 수정과 풀 변경을 함께 적용하면 원인을 돌릴 수 없고, 다음 장애는 같아도 새것처럼 보일 것입니다.