반응형
  • Client OS: Ubuntu 16.04
  • FreeRDP (xfreerdp) version: 2.0.0-dev2 (3c4385e)
  • Server OS: Windows 10 (version 1709, build 16299.309)



xfreerdp를 이용해서 리눅스에서 원격 윈도우 머신에 RDP (Remote Desktop Protocol) 연결을 해서 쓰고 있었는데, 2018년 들어서 윈도우10이 업데이트되고 나서는 아래와 같이 오류가 나면서 접속이 되지 않았다.



[19:43:47:999] [2320:2321] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[19:43:47:033] [2320:2321] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F]
[19:43:47:033] [2320:2321] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error


확인해 보니, 윈도우 10에서 네트워크 수준 인증(Network Leval Authentication; NLA)을 사용하여 원격 접속을 허용하는 옵션과 연관된 듯 했다. 비슷한 문제를 겪는 사람들의 의견을 봤을 때, NLA 옵션을 끄니까 다시 되더라는 사람도 있었고, xfreerdp를 실행할 때 보안 옵션(/sec)으로 nla를 지정해 주었더니 되더라는 사람도 있었다.




*네트워크 수준 인증 (NLA) 끄는 방법:

  1. 시작버튼 누르고 "제어판"이라고 입력해서 제어판(윈도우10 설정 말고) 실행
  2. 시스템 선택
  3. 좌측에 "원격 설정" 선택
  4. 하단 부분에 "이 컴퓨터에 대한 원격 연결 허용" 아래에 있는 체크박스 해제 (네트워크 수준 인증을 사용하여 원격 데스크톱을 실행하는 컴퓨터에서만 연결 허용 (권장))



*xfreerdp에서 보안 옵션 지정하는 방법:

커맨드 라인에서 실행할 때 /sec 옵션을 추가해 준다.

  • 네트워크 수준 인증을 사용할 경우, /sec:nla
  • 그렇지 않을 경우, /sec:tls



나는 NLA 옵션을 끄고, xfreerdp를 실행할 때 /sec:tls 옵션을 추가했더니 문제 없이 접속이 잘 되었다.




<참고자료>

https://github.com/FreeRDP/FreeRDP/issues/4449#issuecomment-372979253



반응형
블로그 이미지

Bryan_

,
반응형

OS: 윈도우 10 (윈도우7, 8, 8.1 모두 해당될 것으로 예상됨)


윈도우에서 원격 데스크탑 연결(RDP)을 통한 접근을 어디서 누가 언제 했었는지 알고 싶을 때, 이벤트 로그에서 확인할 수 있다.

이벤트 로그를 볼 수 있는 이벤트 뷰어는 시작-실행에서 이벤트 뷰어(eventvwr)를 입력해서 실행할 수 있다.

RDP 관련 로그는 응용 프로그램 및 서비스 > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational 을 선택한다.


하나씩 항목을 눌러보면서 IP주소는 확인이 안되는 줄 알았는데, 알고보니 하단의 이벤트 정보를 보여주는 창 중에서 "일반" 바로 밑의 창에서 확인할 수 있었다. 가려져 있지만, 그림 1에서 빨간 네모칸 영역에 해당하는 부분을 키우거나 스크롤 단추를 눌러서 아래쪽을 보면 접속한 클라이언트의 IP 주소가 보인다.



(그림 1. 이벤트 뷰어에서 RDP 로그에 대한 상세 화면)






반응형
블로그 이미지

Bryan_

,
반응형

Host OS: Ubuntu 14.04.1 LTS (amd64)

Guest OS: Windows 10 (64-bit)


연구실 PC가 메모리가 넉넉한 편이라서(16GB) 가상 머신으로 윈도우를 시험삼아 돌려 보고 있는데, 이상하게 오랜만에 가상머신에 원격으로 접속하면 (원격 데스크탑 RDP 사용) 바탕화면이 뜨는데 상당히 오랜 시간이 걸린다. 정확히 재지 않았지만, 1분은 확실히 넘는 것 같다.


가상머신 구성은 다음과 같다:

  • 가상 머신 관리는 QEMU KVM을 사용
  • 윈도우 가상 머신에 CPU 2 Cores (물리적으로 2개, 쓰레드 기준으로 4개), 6GB 메모리, 180GB의 하드디스크를 할당
  • 평소에 항상 PC를 켜 두고, 리눅스를 주로 사용하다가 몇 시간에 한 번씩 윈도우 가상 머신에 RDP로 연결(리미너 원격 클라이언트 또는 FreeRDP 사용)

보통 맨 처음 가상 머신을 부팅시키고 나면 직접 Virtual Machine Manager 어플리케이션에서 확인하든 RDP로 원격접속하든 상관 없이 바로 바탕화면이 나오는데, 윈도우에서의 작업을 마치고 원격 접속 연결만 해제한 채 (즉, 켜진 상태로) 오랜 시간을 쓰지 않으면, 나중에 다시 접속할 때 위와 같이 상당히 오랜 시간이 걸린다. 그리고 그 때 PC의 물리적인 상태를 보면 HDD 램프가 빠르게 깜빡거리면서 하드디스크에 지속적으로 열심히 접근하고 있다.


확인해본 결과, 우분투는 기본적으로 물리적인 메모리에 상주하는 어플리케이션을 가급적이면 스왑 영역(가상 메모리 영역; 즉 하드디스크)에 옮겨 두려는 경향이 크다는 것을 알게 되었다. 그리고 그 경향을 조절하는 설정 변수가 Swappiness이다. 0부터 100 사이의 값 중에서 기본값이 60으로 되어 있다. 60이라는 숫자가 정량적으로 얼마만큼의 메모리 영역을 스왑 영역으로 보내는지는 확실하지 않지만, 경향성이 매우 높은 편에 속한다는 사실에는 이견이 없어 보인다.


인터넷에서 대부분의 우분투 사용자들이 개인 PC에서 우분투를 쓸 때 성능을 개선하기 위해서 가장 먼저 swappiness부터 조정한다는 것 또한 알 수 있었다. 설정 방법은 /etc/sysctl.conf 파일에 아래와 같이 한 줄을 추가하거나, 이미 있으면 숫자를 아래와 같이 조정한다:

vm.swappiness=10


인터넷에서는 보통 swappiness 값을 10 으로 권장하는 분위기이다. 실제로 나도 swappiness 값을 조정하고 나서 윈도우 가상 머신의 원격 데스크탑 접속 로딩 시간이 꽤 단축되는 것을 체감할 수 있었다. 하지만 여전히 몇 시간 후에 다시 접속하면 약 30초 가량의 딜레이가 발생하였다. 그래서 아예 vm.swappiness 값을 3으로 더욱 낮게 설정했더니, 그제서야 길어도 10초 이내로 바로 원격 데스크탑 화면이 나타났다.


개인적인 경험으로 볼 때, 물리적 메모리가 16GB이고 가상 머신을 한 개만 운용하고 있으며, 이외에 메모리를 많이 소비하는 다른 프로그램을 쓰지 않기 때문에 swappiness 값을 매우 낮게 줘도 앞으로 쓰는 데는 문제가 없을 것 같다.


하지만 근본적으로는 서버에서 가상 머신을 돌리는 것이 속도를 개선하는 가장 확실한 방법인 것 같다. 실제로 연구실에서 운용하는 24코어에 64GB 메모리, 5TB의 하드디스크를 갖고 있는 서버에서 동일한 스펙의 가상 머신을 돌리는 것이 개인 PC에서 돌릴 때에 비해 속도가 월등하게 빨랐다. 즉, 그래픽 측면의 이질감과 불편함(폰트 같은 것이 깔끔하게 표시되지 못하고, 게임을 실행하지 못하는 문제)만 감수할 수 있다면, 서버에서 가상 머신을 돌리는 것(결국 클라우드 환경)이 좋을 수밖에 없다.


아직 연구실에 오픈스택(OpenStack)을 적용하지는 못했는데 (당장 이 쪽으로 연구실 구성원 중에 연구주제가 있는 것은 아니고, 운영상의 목적만 있음), 서버 여러 대와 몇몇 잉여 데스크탑 본제들을 조합해서 클라우드 환경을 만들어서 돌려보고 싶다. 일단은 졸업이 급하니 졸업하고 나서 해 봐야겠다. ㅜㅜ


반응형
블로그 이미지

Bryan_

,