Cisco Secure Client가 RDP 세션에서 VPN 연결을 차단합니다

로그인은 성공하는데 터널이 올라오지 않습니다. 이 조합은 인증 문제로 잘못 읽히기 때문에, 원인이 아니었던 자격 증명을 재설정하며 반나절을 보내게 됩니다. Cisco Secure Client는 시도가 Remote Desktop 세션에서 왔다는 이유만으로 VPN 연결을 거부할 수 있으며, 그 판단은 클라이언트 측 정책이 합니다.

연결 흐름에서 이 문제가 나타나는 지점

클라이언트를 위에서부터 따라가 봅니다. 프로필이 로드되고 자격 증명이 수집되며 인증이 끝납니다. 그다음, 터널이 만들어지기 전에 클라이언트는 자신이 놓인 환경에 대해 세션 및 연결 설정을 평가합니다.

그 시점에 세 가지를 적어 두십시오. 정확한 메시지, 클라이언트 버전, 클라이언트에 표시되는 프로필 이름입니다. 이 세 가지가 모호한 불만을 누군가 조치할 수 있는 지원 요청으로 바꿉니다. 긴 메시지는 로그에서 잘리므로 대화 상자를 캡처해 두십시오. 시각도 기록하면 관리자가 헤드엔드와 대조할 수 있습니다.

실제로 판단하는 설정

관련 제어는 Windows VPN Establishment 정책이며, 문서화된 값은 두 가지입니다. 로컬 사용자만, 그리고 원격 사용자 허용입니다. 후자는 지원되는 구성에서 Remote Desktop 세션으로부터의 터널 생성을 허용합니다. 전자는 많은 기업 프로필의 기본 태도입니다.

Windows Logon Enforcement와 혼동하지 마십시오. 프로필 가이드는 이를 로그온 세션에 관한 별도 정책으로 문서화합니다. 하나는 어느 세션이 터널을 만들 수 있는지 정하고, 다른 하나는 동시 또는 로그온 전 동작을 정합니다. 잘못된 쪽을 바꾸면 눈에 보이는 효과가 없습니다.

실제로 적용된 프로필 읽기

관리되는 배포에서 클라이언트는 헤드엔드나 관리되는 위치에서 프로필을 받으며, 디스크에서 편집한 사본이 유효한 사본이 아닌 경우가 많습니다. 그래서 로컬 XML 변경이 올바르게 보여도 아무것도 바뀌지 않을 수 있습니다.

노트북에 어떤 파일이 있는지가 아니라 장치가 어떤 프로필과 그룹 정책을 받는지 관리자에게 물으십시오. 버전 업그레이드 후에는 둘이 자주 어긋납니다. 로컬 폴더의 오래된 사본은 여전히 편집기에서 열리고 여전히 올바르게 보입니다. 다만 클라이언트가 적용한 것이 아닐 뿐입니다.

터널이 올라온 뒤의 RDP 경로

원격 연결을 허용해도 Remote Desktop 세션이 살아남는다는 보장은 없습니다. 터널이 경로나 로컬 액세스 규칙을 바꾸면, 당신을 안으로 들여보낸 세션이 그것을 떠받치는 경로를 잃을 수 있습니다.

변경 전에 복구 경로를 계획하십시오. 콘솔 액세스, 대역 외 관리 경로, 또는 문서화된 재연결 절차입니다. 나중에 결정하면 보통 장비까지 가야 합니다.

정책을 우회하려고 세션을 가로채는 요령, 다른 원격 제어 도구, 스크립트에 적어 둔 비밀번호를 쓰지 마십시오. 조직이 이 작업 흐름을 승인하지 않는다면 올바른 행동은 조직이 지원하는 관리 경로입니다.

관리자에게 보낼 것

메시지 본문, 클라이언트 버전, 활성 프로필 이름, 접속한 세션 유형, 그리고 로컬 콘솔에서의 시도가 다르게 동작하는지를 전달하십시오. 타임스탬프를 덧붙이십시오.

시간을 아끼는 것은 마지막 비교입니다. 세션 정책에 따른 거부와 장치 전체의 장애를 구분해 주기 때문입니다.

승인된 변경 후 확인

프로필이 업데이트되면 새 RDP 세션을 만들고 다시 연결한 뒤, 연결 해제 순서를 의도적으로 수행하십시오. 터널이 올라오는지, 관리 경로가 살아남는지, 계정이 여전히 데스크톱에 로그인할 수 있는지 확인하십시오.

VPN 허용, 세션 유지, Windows 로그온 권한은 세 가지 별개의 점검입니다. 하나를 통과해도 나머지 둘에 대해서는 아무것도 알 수 없습니다.