27850, 442, 651: 하나의 스택, 세 가지 첫 점검
세 오류는 모두 가상 어댑터 스택에서 나옵니다. 번호를 해당 계층에 맞추고, 그 계층을 점검하고, 정리한 뒤에만 다시 설치하십시오.
설치 관리자가 27850에서 멈추고, 연결은 442로 거부되며, 다른 프로필은 651을 반환한다. 번호만 보면 서로 무관한 세 고장처럼 보여서 보통은 클라이언트를 세 번 다시 설치한다. 그러나 발생 지점은 하나의 하위 시스템, 즉 가상 어댑터와 그 주변의 필터 스택이다. 오류 번호는 어느 계층이 실패했는지를 알려 주고, 그것이 첫 점검 항목을 정한다. 번호를 읽기 전에 다시 설치하면 대개 같은 고장이 재현된다.
번호를 계층에 맞추기
오류마다 발생 지점이 다르므로, 보이는 증상이 같은 연결 거부여도 첫 점검은 달라진다. 세 계열이 모든 경우를 덮는다. 설치 관리자, 어댑터, 그 아래의 포트다. 아래 표는 각 번호를 그것이 요구하는 점검 옆에 둔다.
| Error | When it appears | First check | Usual cause |
|---|---|---|---|
| 27850 | During install | Filter count and security suite | Stack at the filter limit, or a suite blocking the driver |
| 442 | On connect | Adapter state and display name | Disabled adapter, ICS holding it, malformed CVirtA name |
| 651 | On connect | WAN miniport and third-party drivers | Miniport failed to start, bridging driver attached |
프로필을 고르기 전에 오류가 나오면 설치 관리자 계열이다. 클라이언트가 어댑터를 올리려 할 때 나오면 어댑터 계열이다. 어댑터는 보이는데 포트가 한 번도 열리지 않으면 미니포트 계열이다. 무엇이든 바꾸기 전에 번호를 적어 두십시오. 세 가지 복구는 스택의 서로 다른 부분을 건드리므로, 계열을 잘못 짚은 변경은 다음 시도를 읽기 어렵게 만든다.
가득 찬 필터 스택, 또는 드라이버를 막는 보안 제품
클라이언트를 설치하면 어댑터 체인에 작은 필터 구성 요소가 등록된다. Windows에는 이런 구성 요소가 몇 개까지 연결될 수 있는지에 대한 엄격한 상한이 있고, 기본값은 백신, 가상화 브리지, 캡처 드라이버가 있으면 여유가 거의 없다. 그러면 VPN 패키지가 정상이어도 설치가 27850으로 실패한다. 설치 관리자는 가득 찬 스택과 망가진 스택을 구별하지 못한다.
현재 값을 읽고, 올리고, 다시 시도하기 전에 재부팅하십시오. 스택이 다시 만들어지기 전에는 새 필터가 연결될 수 없다:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters /t REG_DWORD /d 14 /f다른 원인은 눈에 보이는 안내 없이 드라이버 설치를 막는 보안 제품이다. 그 자기 방어 기능이 필터 등록을 막을 수 있어서 설치 관리자는 일반적인 구성 요소 실패를 보고한다. 제품 자체의 로그를 보고, 자기 방어가 방해한다면 설치하는 동안에만 끄고 곧바로 되돌리십시오. 값이 이미 올라가 있고 막는 제품이 없다면 다음을 찾으십시오 이전 VPN 제품이 남긴 고아 필터 드라이버. 대응하는 서비스가 없는 오래된 필터는 여전히 자리를 차지하고 새 설치를 실패시킬 수 있다.
어댑터는 있고 내려간 채로 남는다
오류 442는 가상 어댑터가 존재하지만 클라이언트가 올리지 못한다는 뜻이다. 첫 점검은 숨겨진 장치를 표시한 장치 관리자다. 비활성화된 어댑터, 경고 표시가 있는 어댑터, 없는 어댑터는 클라이언트에서는 똑같이 보이지만 필요한 복구가 다르다. Internet Connection Sharing이 잡고 있는 경우가 많다. 서비스가 어댑터를 점유했다면 레지스트리를 건드리기 전에 서비스를 멈추고 다시 시도하십시오. 남은 공유 설정이 재부팅 후 다시 점유할 수 있으므로, 수정이 재부팅 후에도 유지되는지 적어 두십시오.
다시 설치하면 어댑터를 관리할 수 없게 만드는 잘못된 표시 이름이 남을 수 있다. 값은 해결되지 않은 설치 토큰이 아니라 일반 텍스트여야 한다:
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName -Value "Cisco Systems VPN Adapter for 64-bit Windows"클라이언트가 기대하는 표시 이름을 사용하고, 그다음 재부팅해서 어댑터가 다시 열거되게 하십시오. 재부팅 없이 값을 설정하면 대개 이전 상태가 그대로 남고 다음 연결은 다시 442를 준다.
아래의 포트가 한 번도 열리지 않는다
오류 651은 연결 관리자가 WAN 미니포트를 열지 못할 때 보고된다. 클라이언트에서 어댑터가 건강해 보여도 그 아래 포트가 시작된 상태에 이르지 못할 수 있다. 무엇이든 다시 설치하기 전에 미니포트와 그 상태를 나열하십시오:
Get-PnpDevice -Class Net | Where-Object { $_.FriendlyName -like "*WAN Miniport*" } | Select-Object Status, FriendlyName오류 상태의 미니포트가 직접적인 단서다. 장치 관리자에서 다시 설치하면 포트가 다시 만들어지며, 클라이언트 재설치가 통하지 않을 때 이 복구가 통하는 이유가 그것이다. 물리 어댑터에 연결된 타사 드라이버도 흔한 원인이다. VirtualBox 브리지 네트워크 드라이버, OpenVPN 에서 남은 TAP 드라이버, 캡처 필터가 포트를 먼저 차지할 수 있다. 드라이버가 이미 연결되어 있다면 설치 중에 구성 요소 선택을 해제하는 것만으로는 부족하다. 어댑터 속성에서 제거하거나 드라이버 저장소에서 제거해야 한다.
VPN 연결에서 IPv6를 끄면 일부 빌드에서 이 오류가 해결되었지만, 영구 설계가 아니라 시험으로 다루십시오. IPv6를 끈 상태에서만 연결이 시작된다면 근본 원인은 여전히 미니포트나 드라이버다.
한 계층만 바꾸고 증거를 남긴다
변경한 레지스트리 값을 저장하고, 어댑터와 필터 목록을 전후로 기록하고, 시도 사이에 재부팅하십시오. 여기서는 모든 계열의 복구에 재부팅이 포함된다. 어댑터 스택은 부팅할 때 만들어지고 서비스 재시작으로는 다시 만들어지지 않기 때문이다.
이전 어댑터, 필터, 미니포트가 사라진 뒤에만 클라이언트를 다시 설치하십시오. 망가진 스택 위에 새 클라이언트를 얹는 것이 복구 가능한 27850을 반쯤 등록된 어댑터 두 개와 분명한 오류가 없는 기계로 만드는 길이다. 같은 오류가 계층별 점검을 두 번 통과하면 멈추고 위로 올리십시오. 그 시점의 유용한 다음 단계는 공급업체의 설치 로그와 함께 네트워크 스택을 깨끗하게 검토하는 것이지, 같은 재설치를 또 반복하는 것이 아니다.