Azure VPN Client: VPN 플랫폼이 연결을 시작하지 않았습니다

상태 줄은 VPN 플랫폼이 연결을 시작하지 않았다고 말하고, 프로필은 불평 없이 가져와지며, 게이트웨이는 다른 모든 사람에게 정상입니다. 이 메시지는 Windows 내부의 핸드오프를 설명하지 자격 증명이 거부된 것이 아니므로, 유용한 순서는 가장 저렴한 상태 변경에서 가장 파괴적인 것 순으로 진행됩니다. 프로필을 다시 가져오는 데는 일 분, 패키지 복구에는 재부팅 한 번, 초기화에는 컴퓨터의 모든 프로필이 듭니다. 잘못된 순서로 작업하면 이 경우들을 구분하는 데 필요한 증거가 사라집니다.

다시 가져오기, 복구, 초기화: 세 가지 비용

세 동작은 서로 대체할 수 없고, 수고 없이 되돌릴 수 있는 것은 하나뿐입니다. 다시 가져오기는 프로필을 새로 고치고 앱 설치를 유지합니다. 복구는 가져온 프로필을 유지하고 패키지 파일을 다시 씁니다. 초기화는 프로필을 앱 상태와 함께 제거하므로 이후에 모든 것을 다시 가져와야 합니다.

게이트웨이, 주소 풀 또는 인증 방법이 바뀌었을 때는 azurevpnconfig.xml을 새로 내려받아 시작하십시오. 삭제된 게이트웨이를 가리키는 프로필은 정확히 이 상태 줄을 만들며, 클라이언트 복구로는 더 이상 없는 것을 가리키는 파일을 고칠 수 없습니다.

파괴적인 단계 전에 앱이 백그라운드에서 실행되도록 허용되었는지 확인하십시오. 설정, 앱, 설치된 앱, Azure VPN Client, 고급 옵션 순입니다. 일시 중단된 클라이언트는 플랫폼 핸드오프를 끝낼 수 없습니다.

RasMan은 클라이언트가 핸드오프하는 서비스입니다

Remote Access Connection Manager가 클라이언트 요청을 Windows 연결로 바꿉니다. 관리자 권한 명령 프롬프트에서 net stop rasman과 이어서 net start rasman으로 다시 시작하고, 다른 것을 바꾸기 전에 다시 연결하십시오.

그것으로 연결이 돌아오면 수정이 재부팅 후에도 남도록 시작 유형을 설정하십시오. sc.exe config rasman start= delayed-auto입니다. 지금은 실행 중이지만 부팅 시 사용 안 함인 서비스는 내일 아침 같은 실패를 반복합니다.

시작한 뒤 스스로 멈추는 서비스를 지켜보십시오. 이 패턴은 종속성이나 정책을 가리키며, 다시 시작하면 몇 분씩만 작동하므로 깔끔한 실패보다 나쁩니다. 간헐적인 네트워크 문제처럼 보이기 때문입니다. 시도 시각 전후의 System 로그에서 서비스 이름을 확인하고 종속성도 실행 중인지 확인하십시오.

현재 사용자 또는 로컬 컴퓨터: 두 개의 인증서 저장소

클라이언트가 빈 인증서 목록으로 열리면 프로필 탓도 서비스 탓도 아닙니다. 클라이언트는 현재 사용자의 개인 저장소를 읽습니다. certmgr.msc를 열고 Certificates, Current User, Personal, Certificates를 펼쳐 인증서가 개인 키와 함께 있는지 확인하십시오.

certlm.msc로 여는 로컬 컴퓨터 저장소는 다른 저장소이며, 그곳에 설치해도 사용자 저장소를 보는 클라이언트는 만족하지 않습니다. 인증서 인증에서는 게이트웨이가 루트의 공개 키만 가지며, 각 장치에는 그 루트에서 발급된 자체 인증서가 필요합니다. 다른 컴퓨터에서 복사한 인증서는 보통 개인 키 없이 도착하므로, 선택할 수는 있지만 여전히 인증할 수 없는 항목이 됩니다.

빈 선택기는 저장소 문제이지 터널 문제가 아닙니다.

인증서 인증 또는 Azure AD: 서로 다른 실패 형태

Azure AD 인증에는 지점-사이트 구성에 테넌트 URL, 대상으로서 Azure VPN Client 애플리케이션 ID, STS 발급자가 필요하며, 관리자가 Azure VPN 애플리케이션에 동의해야 합니다. 그 구성을 저장하고 패키지를 다시 내려받아 이전 사본을 재사용하는 대신 새 파일을 가져오십시오.

또한 클라이언트 주소 풀이 가상 네트워크나 온프레미스 범위와 겹치지 않는지, 대상 컴퓨터의 네트워크 보안 그룹이 그 풀을 허용하는지 확인하십시오. 이 두 실수는 클라이언트 측의 모든 복구를 피해 갑니다.

노트북 쪽인지 게이트웨이 쪽인지

공용 주소 확인으로 터널을 판단하지 마십시오. 지점-사이트 연결은 모든 인터넷 트래픽을 Azure로 보내지 않으므로, 터널이 올바르게 작동하는 동안 공용 주소가 그대로인 것은 예상된 일입니다. 대신 가상 네트워크 내부의 개인 주소를 시험하고 컴퓨터의 유효 경로를 읽으십시오.

어느 단계에서 연결이 돌아왔는지, 클라이언트 버전, 프로필 내려받은 날짜, 자격 증명을 인증서가 제공했는지 ID 공급자가 제공했는지 적어 두십시오. 그 기록은 다음 발생을 짧은 점검으로 바꾸고, 실패가 노트북에 머무는 대신 게이트웨이 쪽으로 이동하는지 보여 줍니다.

작업 순서는 최신 프로필을 다시 가져오고, RasMan을 다시 시작하고, 백그라운드 실행을 허용하고, 패키지를 복구하고, 인증서 저장소가 온전함이 확인된 경우에만 초기화하는 것입니다.