Embed Size (px)
Citation preview
Windows Server 2012 Remote Access A to D 회사 외부의 네트워크 상에서, 전통적인 VPN 연결 없이 회사
네트워크 자원을 연결할 수 있는 새로운 원격 접근 기능인
DirectAccess 는 Windows Server 2008 R2 에서
소개되었습니다. DirectAccess 기능을 사용할려면, 도메인에
죠인된 Windows 7 Enterprise 및 Ultimate 클라이언트가
필요합니다. 반면에, 전통적인 클라이언트, 도메인에 죠인되지
않은 클라이언트 및 third-party 클라이언트를 위해서, 여전히
Windows RRAS 기능이 전통적인 VPN 을 지원합니다. 또한,
RRAS 는 서버들 사이의 site-to-site 연결을 지원합니다.
Windows Server 2008 R2 의 RRAS 는 동일 edge 서버에
DirectAccess 기능과 공존할 수 없습니다. 반드시,
DirectAccess 와 RRAS 는 물리적으로 분리된 서버에
배포되어져야 합니다.Windows Server 2012 에서, 신규 통합
서버 역할에 DirectAccess 및 RRAS 역할 서비스가 결합되어
제공됩니다. 신규 Remote Access 서버 역할은 DirectAccess
및 VPN 기반 원격 접근 서비스의 중앙 관리, 구성 및
모니터링 기능을 지원합니다. 게다가, Windows Server 2012
DirectAccess 는 다중 업데이트 기능을 지원합니다.
이 동 철
2012-11-26
페이지 1 / 89
목차
데모 환경 ...................................................................................................................................................... 4
Remote Access (DirectAccess, Routing and Remote Access) 개요 .............................................................. 5
Remote Access ...................................................................................................................................... 5
DirectAccess 및 RRAS 통합 서버 역할 ................................................................................................. 5
DirectAccess 및 RRAS 공존 (共存)........................................................................................................ 6
DirectAccess 배포 단순화 .................................................................................................................... 7
DirectAccess 구성의 PKI 전제조건(前提條件) 제거 ........................................................................... 7
내부 IPv4-only 자원 접근을 위한 NAT64 및 DNS64 지원 ................................................................... 8
NAT 디바이스 배후 (背後)의 DirectAccess 서버 지원 ....................................................................... 9
단순화된 네트워크 보안 정책 ............................................................................................................ 9
부하 분산 (Load Balancing) 지원 ....................................................................................................... 10
다중 도메인 지원 ............................................................................................................................... 10
NAP 통합 ............................................................................................................................................. 11
OTP 지원 (Token Based Authentication) ............................................................................................ 11
터널링 강제를 위한 자동화된 지원 ................................................................................................. 12
IP-HTTPS 상호 운용 및 성능 향상 ...................................................................................................... 12
Manage-Out 지원 (단지 원격 관리 용도의 DirectAccess 배포 방법) .............................................. 14
Multisite 지원 ..................................................................................................................................... 14
페이지 2 / 89
Server Core 운영체제 지원 ................................................................................................................ 15
PowerShell 지원 ................................................................................................................................. 15
사용자 및 서버 상태 모니터링 (User 및 Server Health Monitoring) ............................................... 15
서버 운영 상태 ................................................................................................................................... 17
진단 (Diagnostics) ............................................................................................................................... 18
Accounting 및 Reporting ..................................................................................................................... 18
Site-to-Site IKEv2 IPsec 터널 모드 VPN .............................................................................................. 19
IPv4 only 네트워크 환경에서 DirectAccess 설치 및 구성 ........................................................................ 20
개요..................................................................................................................................................... 20
테스트 랩 개요 ........................................................................................................................... 20
하드웨어 및 소프트웨어 요구사항 .......................................................................................... 21
DirectAccess 테스트랩 구성 절차 (for Windows 8 Client) ........................................................ 22
Step 1 : 기본 테스트 랩 설정 ................................................................................................. 23
Step 2 : DC1 구성 .................................................................................................................... 24
Step 3 : EDGE1 구성 ................................................................................................................ 28
Step 4 : CLIENT1 구성 ............................................................................................................. 40
DirectAccess 클라이언트를 위한 DirectAccess 구성 절차 (for Windows 8 & Windows 7) 57
Step 1 : 기존 DirectAccess 구성 제거 .................................................................................. 58
Step 2 : Windows 7 클라이언트 준비 .................................................................................. 61
페이지 3 / 89
Step 3 : Windows 7 클라이언트를 위한 보안 그룹 생성 .................................................. 62
Step 4 : 기존 도메인에 Private CA 설치 확인 ..................................................................... 64
Step 5 : CA 의 CRL 외부 공개 구성 ....................................................................................... 67
Step 6 : DirectAccess 서버 및 DirectAccess 클라이언트의 인증서 확인 ........................ 69
Step 7 : DirectAccess 서버 구성 ............................................................................................ 73
Step 8 : Windows 7 및 Windows 8 DirectAccess 클라이언트 테스트 ........................... 84
참조자료 .................................................................................................................................................... 89
페이지 4 / 89
데모 환경
본 문서의 데모 환경은 아래와 같습니다. 본 데모 환경의 모든 서버는 오로지 IPv4 주소만 할당되어
있습니다. DirectAccess 클라이언트 역할을 수행하는 CLIENT1 및 CLIENT2W7 컴퓨터는 기본적으로 IPv4
주소만을 할당받았지만, EDGE1 서버에 DirectAccess 구성을 완료한 후, DirectAccess 클라이언트로
지정받게 되면, 네트워크 위치에 따라 IPv6 주소(ex, IPHTTPS 인터페이스)를 자동으로 할당 받습니다.
아래 데모 환경에서 CLIENT2W7 이라는 Windows 7 도메인 클라이언트가 빠져 있음을 미리
알려드립니다.
페이지 5 / 89
Remote Access (DirectAccess, Routing and Remote Access) 개요
( http://technet.microsoft.com/library/hh831416 )
Remote Access
Windows Server 2012 에서, Remote Access 는 하나의 통합된 서버 역할에 2 가지의 네트워크 서비스가
결합되어 있습니다.
DirectAccess 및 RRAS 통합 서버 역할
회사 외부의 네트워크 상에서, 전통적인 VPN 연결 없이 회사 네트워크 자원을 연결할 수 있는 새로운
원격 접근 기능인 DirectAccess 는 Windows Server 2008 R2 에서 소개되었습니다. DirectAccess 기능을
사용할려면, 도메인에 죠인된 Windows 7 Enterprise 및 Ultimate 클라이언트가 필요합니다. 반면에,
전통적인 클라이언트, 도메인에 죠인되지 않은 클라이언트 및 third-party 클라이언트를 위해서, 여전히
Windows RRAS 기능이 전통적인 VPN 을 지원합니다. 또한, RRAS 는 서버들 사이의 site-to-site 연결을
지원합니다. Windows Server 2008 R2 의 RRAS 는 동일 edge 서버에 DirectAccess 기능과 공존할 수
없습니다. 반드시, DirectAccess 와 RRAS 는 물리적으로 분리된 서버에 배포되어져야 합니다.
Windows Server 2012 에서, 신규 통합 서버 역할에 DirectAccess 및 RRAS 역할 서비스가 결합되어
제공됩니다. 신규 Remote Access 서버 역할은 DirectAccess 및 VPN 기반 원격 접근 서비스의 중앙 관리,
구성 및 모니터링 기능을 지원합니다. 게다가, Windows Server 2012 DirectAccess 는 다중 업데이트
기능을 지원합니다.(?)
Windows Server 2008 R2 와 달라진 점
DirectAccess 및 RRAS 를 위한 신규 통합 서버 역할은 Remote Access 서버 배포를 위한 구성 및 관리의
단일 환경을 제공합니다. Windows Server 2012 는 Windows 7 DirectAccess 및 RRAS 보다 다음과 같은
향상된 기능을 제공합니다.
DirectAccess and RRAS coexistence
Simplified DirectAccess management for small and medium organization administrators
Removal of PKI deployment as a DirectAccess prerequisite
Built-in NAT64 and DNS64 support for accessing IPv4-only resources
Support for DirectAccess server behind a NAT device
Simplified network security policy
Load balancing support
Support for multiple domains
페이지 6 / 89
NAP integration
Support for OTP (token based authentication)
Automated support for force tunneling
IP-HTTPS interoperability and performance improvements
Manage-out support
Multisite support
Support for Server Core
Windows PowerShell support
User and server health monitoring
Diagnostics
Accounting and reporting
Site-to-site IKEv2 IPsec tunnel mode VPN
DirectAccess 및 RRAS 공존 (共存)
DirectAccess 및 RRAS 는 적대적인 인바운드 트래픽으로 부터 서버를 보호하기 위한 보안 기능을 구현할
수 있습니다. Windows Server 2012 以前 버전에서는, DirectAccess 및 RRAS 가 동일 서버에 존재한다면,
각각의 보안 기능을 방해합니다. 그러므로, 동일 서버에 2 개의 서비스를 구성하게 되면, 각 서비스는
서로의 기능을 방해합니다.
DirectAccess 서버와 클라이언트 연결을 위해, IPv6 변환(變換, transition) 기술을 사용합니다. 반면에,
보안을 강화하기 위해, RRAS 는 IKEv2 (Internet Key Exchange v2) IPsec 을 사용합니다. IKEv2 IPsec
기술은 IPv6 변환(變換, transition) 기술을 사용하는 모든 패킷을 차단하도록 incoming 및 outgoing 패킷
필터를 구성합니다. 즉, DirectAccess 구현을 위해 반드시 필요한 IPv6 변환(變換, transition) 패킷은
RRAS 의 IKEv2 에 의해 차단됩니다. 그러므로, Windows Server 2012 以前 버전에서는, DirectAccess 와
RRAS 는 동일 서버에 공존할 수가 없습니다.
DirectAccess 는 회사 내부 네트워크의 자원을 보호하기 위해 IPsec DoSP (Denial of Service Proection)를
구현합니다. ICMPv6 패킷을 제외한, “IPsec 에 의해 보호되지 않은 IPv6 트래픽” 및 “모든 IPv4 트래픽”을
DoSP 는 차단합니다. 즉, RRAS 에 의해 전달되는 non-IPsec IPv6 트래픽 및 모든 IPv4 트래픽은
DirectAccess 에 의해 차단될 수 있습니다.
Windows Server 2012 의 DirectAccess 는 RRAS 트래픽을 허용하도록 IPsec DoSP 기능을
수정하였습니다. 또한, Windows Server 2012 RRAS 는 IPv6 변환(變換, transition) 기술을 허용하도록
IKEv2 정책을 수정하였습니다. 즉, 이러한 기능 및 정책의 변경을 통해, DirectAccess 및 RRAS 는 동일
서버에 공존할 수 있습니다.
페이지 7 / 89
DirectAccess 배포 단순화
Windows Server 2012 DirectAccess 는 특별히 소형 및 중형 조직에 적합한 배포 방식을 몇 가지 중요한
기능을 지원합니다. 중요한 기능은 “단순화된 사전 항목”, “전체 PKI 배포 필요성 제거”, “통합 인증서
배포” 및 “연속된 2 개의 IPv4 주소 필요성 제거” 입니다. 이러한 상세 기능은 추후 각각은 아래 부분에서
확인합니다.
관리자는 신규 “Getting Started” 마법사를 사용하여 DirectAccess 를 배포할 수 있습니다. 이 마법사는
DirectAccess 의 손 쉬운 구성 방법을 제공합니다. 또한, 신규 마법사는 DirectAccess 구성의 복잡성을
제거하고, 단순한 몇 단계의 자동화된 설치 방법을 제공합니다. IPv6 변환(變換, transition) 기술 및 NLS
배포와 같은 복잡한 기술을 습득하지 않아도, 관리자는 DirectAccess 를 손 쉽게 구성할 수 있습니다.
DirectAccess 구성의 PKI 전제조건(前提條件) 제거
Windows 7 DirectAccess 는 서버 및 클라이언트 인증서 기반 인증을 위해 반드시 PKI 환경이 필요합니다.
즉, PKI 환경이 Windows 7 DirectAccess 배포의 가장 큰 장애물이기도 했습니다. 인터넷 상의
DirectAccess 클라이언트로 부터 트래픽의 인증 및 보호를 위해, DirectAccess 기술은 IPsec AuthIP
정책을 사용합니다. Kerberos 사용하여 도메인 자원을 인증하기 위해, DirectAccess 클라이언트는 먼저,
DNS 서버 및 도메인 컨트롤러에 연결합니다.
AuthIP 정책에서 2 가지 인증 방법을 구현함으로써, Windows 7 DirectAccess 는 DNS 서버 및 도메인
컨트롤러 연결을 활성화할 수 있습니다. IPsec 터널 인프라는 첫 번째 인증은 “컴퓨터 인증서”, 두 번째
인증은 “사용자 NTLM”을 사용하여 구성됩니다. IPsec 터널이 연결되고, 도메인 컨트롤러가 가용하면,
클라이언트는 Kerberos 토큰을 획득할 수 있고, 첫 번째 및 두 번째 인증 방법으로써 “컴퓨터 인증서” 및
“사용자 Kerberos”를 사용하여 인트라넷 IPsec 터널을 구축할 수 있습니다.
이러한 구현 방식은 상호 인증을 위해 컴퓨터 인증서를 DirectAccess 서버 및 모든 클라이언트에
배포해야 하는 부담감이 있습니다. 그러나, 대형 조직 이외의 소형 및 중형 조직에서 내부 PKI 를
유지하는 것은 비용 및 관리적인 측면에서 어려움이 있습니다. Windows Server 2012 DirectAccess 에서,
관리 및 구성을 단순화 하기 위해 PKI 배포가 반드시 필요하지는 않습니다.
Windows Server 2012 DirectAccess 에서, Kerberos 프록시 기반의 HTTPS 를 구현함으로써 상호 인증
기능을 수행할 수 있습니다. 클라이언트 인증 요청은 DirectAccess 서버에서 수행되는 Kerberos 프록시
서비스에 보내집니다. Kerberos 프록시는 클라이언트 대신에 도메인 컨트롤러에 Kerberos 요청을
보냅니다.
Kerberos 프록시를 포함한 솔루션을 자동적으로 구성함으로써, 신규 Getting Started 마법사는 관리자를
위해 매끄러운 경험을 제공합니다. 단순화된 DirectAccess 배포 방법에서는, 터널링 강제화, NAP 통합 및
two-factor 인증과 같은 사용자 수준 구성은 사용할 수 없습니다. 이러한 단순 배포 방식은 오로지
하나의 IPsec 터널만 필요합니다. 또한, 다음과 같은 요구 사항이 필요합니다:
페이지 8 / 89
외부 인터넷 측면 방화벽에서 IPsec 포트(UDP 500/4500) 및 TCP 포트 443 이 open 되어야
합니다.
DirectAccess 서버 자체 개인 방화벽은 반드시 TCP 포트 443 을 open 해야 합니다.
DirectAccess 클라이언트에 의해 신뢰되는 CA 에 의해 발급된 TLS 용도의 서버 인증 인증서가
DirectAccess 서버에 설치되어야 합니다. DirectAccess 서버에 설치되는 서버 인증서를 위해
내부 PKI 배포가 필요하지 않고, 공개 CA 에 의해 발급된 서버 인증서를 사용해야 합니다.
이러한 서버 인증서가 준비되지 않았다면, DirectAccess 서버 설치 과정은 필수적인 IP-HTTPS
및 KDC 프록시 용도의 self-signed 인증서를 구성할 것입니다.
내부 IPv4-only 자원 접근을 위한 NAT64 및 DNS64 지원
내부 IPv4-only 자원에 접근하기 위해서, DirectAccess 클라이언트의 IPv6 통신을 IPv4 통신으로 변경하기
위하여 Windows Server 2012 DirectAccess 는 NAT64 및 DNS64 게이트웨이 기능을 지원합니다.
NAT64 를 사용한 프로토콜 변환은 단방향(unidirectional) 이기 때문에, IPv4-only 인트라넷 컴퓨터는
원격 관리를 위한 DirectAccess 클라이언트의 연결을 초기화 할 수 없습니다.
IPv6-only DirectAccess 환경은 주로 아래와 같은 3 가지 경우에 회사 내부 인트라넷 자원에 대한 전체
접근을 지원하지 않습니다.
Windows Server 2003 파일 서버 및 IIS 와 같이 IPv6 를 지원하지 않고, 오로지 IPv4 만을
지원하는 인트라넷 서버
관리적인 목적으로 네트워크 상에서 IPv6 를 지원하지 않는 환경
Windows Server 2008 과 같이 OS 수준에서 IPv6 를 지원하지만, IPv6 를 지원하지 않는
어플리케이션
DirectAccess 를 통해 위와 같은 자원에 대한 접근을 허용하기 위해, DirectAccess 서버와 내부 IPv4-only
지원을 사이에 프로토콜 변환(變換, transition) 기술이 필요합니다. NAT64 는 클라이언트로부터 IPv6
트래픽을 받아서, 내부 인트라넷에 IPv4 트래픽을 변환해서 보내주는 역할을 담당합니다. NAT64 는
DNS64 와 결합되어 사용됩니다. DNS64 는 DirectAccess 클라이언트부터의 DNS 질의를 가로채고,
NAT64 에 매핑된 IPv6 주소를 IPv4 주소로 변환한 후, 결과 값을 보냅니다.
Windows Server 2012 DirectAccess 以前에는, DirectAccess를 위한 프로토콜 변환 기술은 오로지
Microsoft Forefront Unified Access Gateway DirectAccess 를 통해 지원되었습니다.
관리자의 개입 없이, DirectAccess 설치 마법사는 매끄럽게 프로토콜 변환 구성요소를 구성할 것입니다.
관리자가 프로토콜 변환을 위해 구성해야 할 추가적인 작업이 필요 없습니다. DirectAccess 서버의 내부
인터페이스에 IPv4 주소가 할당되어 있다면, 설치 마법사는 자동적으로 NAT64 및 DNS64 를 활성화 할
페이지 9 / 89
것입니다. 이러한 기능을 지원하기 위해, 설치 마법사는 NAT64 를 위한 IPv6 네트워크 프리픽스를
구성할 것입니다. 설치 마법사는 자동적으로 NAT64 프리픽스를 할당하고, 이 프리픽스를 전체
네트워크의 모든 IPv4 주소 범위에 적용합니다.
NAT 디바이스 배후 (背後)의 DirectAccess 서버 지원
Windows Server 2008 R2 DirectAccess 는 2 개의 연속적인 공용 IPv4 주소 2 개가 할당된 외부
인터페이스는 필수 구성요소입니다. 이러한 요건은 IPv6 변환(變換, transition) 기술 중의 하나인 Teredo
서버를 위해 필요합니다. In order for clients behind a NAT to determine the Teredo server and the
type of NAT device, the Teredo server requires two consecutive IPv4 addresses. (?)
그러나, 연속적인 2 개의 공용 IPv4 주소를 구성하는 것은 소형 및 중형 조직에서는 비용 및 관리적인
부분에서 어려움이 많습니다. 또한, 최근 공용 IPv4 주소의 부족 현상으로 인해, DirectAccess 서버를 위해
2 개의 공용 IPv4 주소를 확보하는 것이 DirectAccess 서버 확산에 장애물로 인식되고 있는 현실입니다.
Windows Server 2012 DirectAccess 는 NAT 디바이스 배후에 DirectAccess 서버를 배포할 수 있는
기능을 지원합니다. DirectAccess 서버를 NAT 배후에 배포한다면, DirectAccess 서버는 단일 NIC 및 다중
NIC 환경 모두 지원 가능합니다. 즉, 이제 더 이상 DirectAccess 서버 배포를 위해 2 개의 연속된 공용
IPv4 주소가 필요하지 않습니다.
Getting Started 마법사 또는 Remote Access Setup 마법사가 수행될 때, DirectAccess 서버가 NAT
배후에 위치하는지 확인하기 위해 DirectAccess 서버 상의 네트워크 인터페이스 상태를 체크할 것입니다.
이러한 구성에서, 오로지 IP over HTTPS(IP-HTTPS)가 배포될 것입니다. IP-HTTPS 프로토콜은 안전한
HTTP 연결을 사용하여 설정된 보안 IP 터널을 이용할 수 있는 IPv6 변환(變換, transition) 기술입니다
단순화된 네트워크 보안 정책
Windows Server 2008 R2 DirectAccess 는 회사 내부 네트워크에 연결을 설정하기 위해 2 개의 IPsec
터널을 사용합니다. DirectAccess 클라이언트는 DNS, DC 및 관리 서버(ex, SCCM)와 같은
기반(Infrastructure) 자원에 접근하기 위해 인프라 터널이 필요합니다. 기반 터널 IPsec 정책의
끝점으로써 이러한 기반 서버들이 나열됩니다. 이러한 IPsec 정책을 통해 구성된 인트라넷 터널은 다른
모든 회사 인트라넷 자원을 접근할 수 있는 방법을 제공합니다.
DNS 서버 또는 도메인 컨트롤러가 추가 및 삭제되는 상황과 같은 변경 사항이 발생하게 될 때, 기반
터널 IPsec 정책에 나열된 끝점들은 정기적인 업데이트가 필요합니다. 현재 기반 서버 끝점을 반영하기
위한 IPsec 정책이 업데이트되지 않았을 때, 클라이언트는 도메인에 대한 연결이 손상될 수 있습니다.
이러한 손상된 연결은 오류를 수정하기 위한 그룹 정책 업데이트를 클라이언트가 받는 것을 방해할 수
있습니다.
페이지 10 / 89
Windows Server 2012 에서, 단순화된 DirectAccess 모델은 단일 IPsec 터널을 통해 DirectAccess 를
배포할 수 있는 방법을 제공합니다. 단일 IPsec 터널을 통한 DirectAccess 는 앞선 문제점을 제거할 수
있습니다. 그러나, 단순화된 DirectAccess 는 특정 기능을 지원하지 않고, 특정 기능은 인증서 기반 인증에
의지합니다. 특정 기능의 예는 스마트 카드를 사용한 2 단계 인증 및 NAP 통합과 같은 기능입니다.
이러한 전체 모든 DirectAccess 기능을 요구하는 회사는 결국 2-터널 모델을 배포해야 할 것입니다.
DirectAccess 전체 기능을 위해 2-터널 모델이 구성한다면, 기반 터널을 통해 접근될 수 있는 서버
항목들을 업데이트할 수 있는 기능을 관리자에게 부가적으로 제공합니다. 신규 도메인 컨트롤러 및
SCCM 서버들은 발견되고 기반 서버 항목에 추가됩니다. 더 이상 존재하지 않는 서버들은 기반 서버
항목으로부터 제거됩니다. 또한, 변경된 IP 주소를 소유한 서버 항목들도 업데이트됩니다.
부하 분산 (Load Balancing) 지원
Windows Server 2008 R2 DirectAccess 는 전체 고가용성 솔루션을 지원하지 않고, 단일-서버 배포
방법에서는 제한됩니다. 제한된 하드웨어 중복을 지원하기 위해, DirectAccess 는 Hyper-V 라이브
마이그레이션을 위해 구성된 Hyper-V 장애조치 클러스터 안에서 구성할 수 있습니다. However, only
one server node may be online at any time. (?)
단일 서버가 지원할 수 있는 적절한 프로세싱 능력을 벗어날 정도로 빠르게 DirectAccess 배포는 확장될
수 있습니다. 즉, 이러한 부하 요구사항 변경에 대처하기 위하여, 부가적인 서버를 빠르고 투명하게
배포할 수 있는 유연성이 반드시 필요합니다. 부가적으로, DirectAccess 클라이언트가 내부/외부
네트워크를 구분하기 위해 사용되는 NLS(Network Location Server)는 2 대 이상을 준비하여 고가용성을
구축해야 합니다.
내장된 Windows NLB 를 사용하여, DirectAccess 및 RRAS 의 고가용성 및 확장성을 해결할 수 있습니다.
NLB 구성은 신규 배포 마법사 인터페이스를 통하여 설치 및 자동화할 수 있습니다. 또한, third-party
외부 하드웨어 기반 부한 분산 룰루션을 위한 통합된 지원도 설치 과정에서 지원합니다.
중요
Windows Server 2012 DirectAccess 는 NLB 를 사용하여 최대 8 노드까지 기본 장애조치 솔루션을
지원합니다. 서버 부하가 모든 NLB 노드 사이에 공유될지라도, 한 서버가 가용하지 않았을 때, 기존
연결은 자동적으로 다른 서버로 전송되지 않을 것입니다.
다중 도메인 지원
Windows Server 2008 R2 DirectAccess 는 오로지 단일 도메인만 지원합니다. 즉, 다른 도메인의 원격
클라이언트는 다른 도메인 내의 DirectAccess 서버를 통해 연결할 수 없습니다. 게다가, 어플리케이션
서버가 다른 도메인에 존재한다면, 원격 클라이언트는 DirectAccess 를 통해 원격으로 어플리케이션
서버를 접근할 수 없습니다.
페이지 11 / 89
Windows Server 2008 R2 DirectAccess 에서 관리자가 수동으로 다중 도메인을 지원하도록 구성한다면,
설치가 완료된 후, DirectAccess 정책을 수동으로 수정해야 합니다. Windows Server 2012
DirectAccess 는 다른 도메인에 존재하는 회사 자원을 원격 클라이언트가 접근할 수 있도록 다중 도메인
구성을 지원합니다.
NAP 통합
인트라넷 터널의 IPsec 상호 인증을 위하여 “상태 인증서 (Health Certificate)”를 요구함으로써, Windows
Server 2008 R2 DirectAccess 는 NAP 통합을 지원합니다. 상태 인증서는 시스템 상태 OID 가 포함된
인증서입니다. NAP 상태 정책 서버 상에 구성된 시스템 상태 요구사항을 준수하도록 하기 위해서, NAP
클라이언트는 HRA(Health Registration Authority)로부터 발급된 상태 인증서가 필요합니다.
Windows Server 2008 R2 DirectAccess 와 NAP 을 통합하기 위하여, DirectAccess 가 배포된 후, 관리자는
DirectAccess 설치 마법사에 의해 생성된 GPO 및 정책을 수동으로 편집해야 합니다. 반면에, Windows
Server 2012 DirectAccess 는 설치 사용자 인터페이스를 통해 NAP 상태 체크를 직접적으로 구성할 수
있습니다. 즉, 이러한 기능은 NAP 통합을 위해 필요한 정책 및 GPO 수정을 자동적으로 수행합니다. NAP
상태 체크 강제화는 Remote Access 설치 마법사로부터 활성화 할 수 있습니다.
중요
신규 설치 마법사는 DirectAccess 와 NAP 통합을 단순화할 수 있어도, 실제 NAP 배포 자체를 자동활 할
수는 없습니다. 부가적으로, 관리자는 NAP IPsec 강제화 및 HRA 구조는 별도 구성을 해야 합니다.
OTP 지원 (Token Based Authentication)
로그인 보안을 강화하기 위해, 대부분 조직은 OTP(One-Time Password) 2 단계 인증을 구성합니다.
Windows Server 2008 R2 DirectAccess 는 스마트 카드와 통합된 2 단계 인증을 지원하지만, RSA
SecurID 와 같은 OTP 벤더 솔루션에 통합된 2 단계 인증은 지원한지 않습니다. 강화된 보안을 요구하는
조직에서, OTP 를 지원하지 않는 DirectAccess 는 사용이 제한적일 수 밖에 없습니다.
Windows Server 2012 DirectAccess 는 스마트 카드 또는 OTP 토큰 기반 솔루션 모두 지원합니다. 이러한
2 단계 인증을 사용하기 위해서는, PKI 인프라는 반드시 배포되어야 합니다. 스마트 카드 및 OTP 옵션을
DirectAccess 설치 마법사에서 선택한다면, User computer certificates 옵션은 자동적으로 선택되고,
반드시 구성해야 합니다.
표준 스마트 카드 인증 지원에 추가적으로, DirectAccess 는 Windows Server 2012 에서 지원되는 TPM
(Trusted Platform Module) 기반 가상 스마트 카드를 사용할 수 있습니다. 클라이언트 컴퓨터의
TPM은 2단계 인증을 위한 가상 스마트 카드로 사용될 수 있습니다. 그러므로, 스마트 카드 배포에
발생하는 오버헤드 및 비용을 TPM 을 통해 절약할 수 있습니다.
페이지 12 / 89
터널링 강제를 위한 자동화된 지원
기본적으로, DirectAccess 클라이언트는 인터넷, 회사 인트라넷 및 로컬 LAN 자원을 동시에 접근할 수
있습니다. 회사 인트라넷에 설정된 연결만이 DirectAccess IPsec 터널을 통해 전송되기 때문에, 이러한
기능을 “분리된-터널 (split-tunnel)” 구성이라고 합니다. 분리된 터널링은 인터넷 상의 자원 접근 시에
최적의 사용자 환경을 제공하고, 반면에, 인트라넷 상의 자원 접근 시에는 강한 보안을 제공합니다.
이렇게 분리된 터널링은 보안 상의 위험이 존재하므로, 대부분의 조직은 DirectAccess 클라이언트 자신의
ID 를 조사할 수 있도록 회사 프록시를 통해 모든 트래픽이 통과하도록 강제합니다. 기존 VPN 연결을
사용하면, 홈 네트워크 및 회사 네트워크 사이에 트래픽이 교환됨으로써 잠재적인 위험이 사용자에게
존재합니다. 즉, 클라이언트 컴퓨터는 라우터와 같이 작동할 수 있습니다. 이러한 기능 때문에, 대부분의
관리자는 보안 상의 이유는 VPN 연결에서 분리된 터널링을 비활성화합니다. 즉, VPN 클라이언트의
인터넷 및 인트라넷 통신은 모두 회사 VPN 연결을 통해 수행됩니다. 그러나, 이러한 분리된 터널링
비활성화는 불필요한 인터넷 트래픽도 회사 내부의 네트워크를 사용하게 됨으로써, 비용 및 성능적인
측면에서 비효율적입니다.
DirectAccess 가 활성화된 IPsec 규칙은 클라이언트를 검증하기 때문에, 분리된 터널링에 의해 발생되는
보안 위험은 DirectAccess 시나리오에서는 유효하지 않습니다. 다른 클라이언트가 DirectAccess
클라이언트를 통해 라우팅을 시도한다면, 다른 클라이언트 즉 트래픽 원본이 검증되지 않기 때문에,
IPsec 은 이러한 연결을 중단시킬 것입니다. 그러나, 대부분 조직은 트래픽을 조사할 수 있도록 회사
프록시를 통해 모든 트래픽이 통과하도록 강제화하기 위해, DirectAccess Force Tunneling 옵션은 이러한
기능을 지원합니다.
Force Tunneling 옵션은 Windows Server 2008 R2 DirectAccess 에서도 지원되었습니다. 그러나, Force
Tunneling 옵션을 활성화하기 위해 그룹 정책 설정을 통한 수동 설정이 필요합니다. Force Tunneling
옵션을 위해 필요한 설정을 자동화하기 위해 설치 마법사 및 관리 UI 는 Windows Server 2012
DirectAccess 와 통합되어 있습니다. Force Tunneling 옵션 활성화는 DirectAccess 클라이언트의 IP-
HTTPS 프로토콜 사용을 제약할 수 있습니다. 기본적으로, IPv4 프록시 서버에 보내질 IPv6 자원을
변환하기 위하여 DNS64/NAT64 서버로써 DirectAccess 서버를 사용합니다. (Enabling the Force
Tunneling option limits the DirectAccess client to using only the IP-HTTPS protocol for connectivity,
and by default uses the DirectAccess server as the NAT64/DNS64 server to translate IPv6 resources to
send to the IPv4 proxy server.) ?????
IP-HTTPS 상호 운용 및 성능 향상
특정 네트워크 상에서, 인터넷 방화벽 설정은 6to4 또는 Teredo IPv6 변환 기술을 사용하는 클라이언트
연결을 방해할 수 있습니다. 모든 IPv6 변환 기술이 연결에 실패할 때, 마지막으로 443 포트를 사용하여
DirectAccess 클라이언트가 회사 네트워크에 연결할 수 있는 방법이 바로 IP-HTTPS 입니다. IP-HTTPS
페이지 13 / 89
기술은 Windows 7 에서부터 지원됩니다. IP-HTTPS 는 IPv4 호스트에 unique, globally routable IPv6
주소를 할당합니다. 그 후, HTTP 터널 상의 전송을 위해 IPv4 내의 IPv6 패킷을 요약한 후, 호스트와 다른
globally routable IPv6 노드 사이에서 IPv6 트래픽을 라우팅합니다.
Windows Server 2012 는 IP-HTTPS 의 구현을 위한 여러 가지 향상된 기능을 제공합니다. IP-HTTPS
클라이언트가 프록시 구성 정보를 얻을 수 있도록 기술적인 변경이 있습니다. 인증이 요구되면 HTTP
프록시에 인증 요청을 보낸다. 각 IP-HTTPS 클라이언트에 클라이언트 인증서를 배포하는 Windows 7
환경의 요구사항이 더 이상 필요하지 않습니다.
IP-HTTPS 는 클라이언트와 서버 사이에 SSL/TLS 연결을 생성함으로써 작동하고, 그 후에 연결 사이에 IP
트래픽을 전달합니다. 전달되는 데이터는 IPsec 에 의해 암호화되고, 이것은 데이터가 두 번 암호화됨을
의미합니다. 첫 번째는 IPsec 에 의해 암호화되고, 두 번째는 SSL 에 의해 암호화됩니다. 이러한 암호화
방식은 6to4 및 Teredo 와 같은 다른 IPv6 변환 기술에 비교하여 성능 저하 및 사용자 환경에 부정적인
영향을 미칩니다. 또한, 이러한 암호화 방식은 DirectAccess 서버의 확장을 제약합니다.
DirectAccess 서버의 확장성을 증대시키고, 이러한 연결 방식에 연관된 오버헤드(ex. 두 번 암호화)를
제거하기 위해, Windows Server 2012 DirectAccess 는 IP-HTTPS 를 위한 여러 가지 성능 향상 방안을
포함합니다. “Send behavior 및 Receive buffers 를 동시에 묶는 기능”, “잠금 경쟁 최소화” 및 “NULL
암호화 방식의 SSL 구현 옵션” 과 같은 변경 사항이 바로 IP-HTTPS 향상된 기능입니다. (These
optimizations include changes to batched send behavior and receive buffers, reduced lock contention,
and the option to implement SSL with NULL encryption.)
IP-HTTPS 는 사용자 컨텍스트 보다는 시스템 컨텍스트 상에서 운영됩니다. 이러한 컨텍스트는 연결
문제를 발생시킬 수 있습니다. 예를 들어, DirectAccess 클라이언트 컴퓨터는 인터넷 접근을 위해
프록시를 사용하는 파트너 회사의 네트워크에 존재하고, WPAD 자동 검출이 사용되지 않는다면, 인터넷
접근을 위하여 사용자는 수동으로 프록시 설정을 구성해야만 합니다. 이러한 프록시 설정은 사용자 별로
IE 에서 구성되고, 프록시 설정은 IP-HTTPS 대신에 직관적인 방법으로 추출될 수 없습니다. 추가적으로,
프록시 사용에 인증이 필요하다면, 클라이언트는 인터넷 접근을 위해 credential 을 제공해야 합니다.
그러나, IP-HTTPS 는 DirectAccess 를 인증하기 위해 요구되는 credential 을 제공하지 않을 것입니다.
Windows Server 2012 에서, 새로운 기능이 이러한 문제점을 해결할 수 있습니다. Specifically, the user
can configure IP-HTTPS to work when behind a proxy that is not configured using WPAD and IP-
HTTPS will request and provide the proxy credentials needed to IP-HTTPS request authenticated, and
relay it to the DirectAccess server. (??)
DirectAccess 에서 IP-HTTPS 를 구성할 때, 관리자는 CA 에서 발급된 인증서를 사용하거나, DirectAccess
설치 시에 자동으로 설치된 self-signed 인증서를 사용할 수도 있습니다. PKI 사용을 원하지 않는다면,
self-signed 인증서가 효과적일 수 있습니다.
페이지 14 / 89
Manage-Out 지원 (단지 원격 관리 용도의 DirectAccess 배포 방법)
사용자가 로그인 되어 있지 않았음에도 불구하고, DirectAccess 클라이언트는 인터넷 연결이 가능할 때
언제든지 회사 인트라넷에 연결을 설정합니다. DirectAccess 클라이언트 컴퓨터가 사무실에 있지
않더라도, IT 관리자는 원격 컴퓨터에 보안 컴플라이언스 및 보안 패치에 대한 관리를 할 수 있습니다.
특정 고객들은 바로 이러한 기능이 DirectAccess 의 가장 중요한 장점이라고 평가합니다. 단지,
DirectAccess 를 원격 관리용으로 사용한다면, 기존 원격 접근 솔루션을 그대로 유지하는 것이 비용 및
관리적인 측면에서 나을 수 있습니다.
Windows Server 2008 R2 DirectAccess 는 manage-out only 용도로 제한하기 위한 자동화된 방법을
제공하지 않습니다. 즉, 관리자들은 설치 마법사에 의해 생성된 정책을 수동으로 편집하여 manage-out
only 용도를 지원할 수 있습니다. Windows Server 2012 DirectAccess 는 배포 마법사 옵션을 통해
manage-out only 구성 방법을 지원합니다. 클라이언트 컴퓨터의 원격 관리 용도만으로 정책 생성을
제한할 수 있는 방법이 manage-out only 배포 방식입니다. 이 배포 방법에서, Force Tunneling, NAP
통합 및 2 단계 인증과 같은 사용자 수준 구성 옵션은 사용할 수 없습니다.
Multisite 지원
인트라넷 자원을 위해 가장 근접한 “입구 지점 (Entry Points)”에 좀 더 효율적인 접근을 지원하고 용량을
증대시키기 위해, DirectAccess 서버는 다중 사이트에 배포할 수 있습니다. 클라이언트가 자신의 각
사이트에 존재하면서, 조직 내의 다른 사이트로 이동하지 않는다면, 가장 근접한 입구 지점에 접근하는
메커니즘은 잘 동작합니다. 그러나, 클라이언트가 사이트 사이에 이동할 예정이라면, 클라이언트들이
가장 효율적 라우팅을 통해 DirectAccess 서버에 연결하기 위해, 다중사이트 DirectAccess 설정은 좀 더
신중한 계획 및 설계가 필요합니다.
클라이언트가 가장 근접한 IP-HTTPS 서버, Teredo 서버, DNS 서버 및 도메인 컨트롤러를 찾을 수 있도록
하기 위해서, 다중사이트 환경에서는 많은 고려 사항이 존재합니다. Windows Server 2012
DirectAccess 는 지리적으로 분산된 다중 DirectAccess 입구 지점의 배포를 위한 솔루션을 제공합니다.
그리고, Windows Server 2012 DirectAccess 는 물리적인 위치에 무관하게 클라이언트가 가장 효율적인
방법으로 회사 내의 자원을 접근할 수 있는 기능을 제공합니다.
지리적으로 분산된 위치 내의 원격 사용자가 자신에게 가장 근접한 다중사이트 입구 지점에 연결할 수
있도록, Windows Server 2012 Remote Access 서버는 다중사이트 배포에서 구성될 수 있습니다.
Windows Server 2012 클라이언트 컴퓨터를 위해, 입구 지점은 자동적으로 할당되거나, 클라이언트에
의해 수동으로 선택될 수 있습니다. 또한, Windows 7 클라이언트 컴퓨터를 위해, 입구 지점은 통계적인
방식으로 할당될 것입니다. 다중사이트 사이의 트래픽은 외부 전역 부하 분산기를 사용하여 분배 및
분산될 것입니다.
페이지 15 / 89
Server Core 운영체제 지원
Server Core 는 디스크 공간, 서비스, 관리 요구사항을 줄이기 위해 설계된 최소 서버 설치 옵션입니다.
또한, Server Core 는 바이러스 공격 같은 보안 침해 사고를 감소시킬 수 있습니다. Server Core 시스템은
GUI 를 지원하지 않고, 관리자는 필요한 모든 구성 작업을 위해 원격 관리 도구 또는 명령어 라인를
사용해야 합니다.
Server Core 설치는 전체 Windows Server 전체 설치 버전에 비해 제한적인 기능을 제공합니다.
Windows Server 2008 R2 Server Core 는 DirectAccess 기능 또는 Remote Access 서버 역할을 지원하지
않습니다. 그러나, Windows Server 2012 Server Core 설치는 DirectAccess 및 RRAS 를 위한 단일 서버
역할을 지원합니다.
신규 Remote Access 서버 역할은 설치, 구성 및 관리를 위해 사용될 Windows Server 2012 에 완전한
Windows PowerShell 을 지원합니다. 또한, Remote Access 서버 역할은 네트워트 상의 다른 서버에서
원격 서버 관리 기능을 통해 구성될 수 있습니다.
PowerShell 지원
Windows Server 2008 R2 DirectAccess 는 구성 옵션을 위한 명령어 라인 인터페이스 및 완벽한
스크립팅이 부족했습니다. Windows Server 2012 는 Remote Access 서버 역할의 설치, 구성, 관리,
모니터링 및 트러블슈팅을 위한 완전한 Windows PowerShell 을 지원합니다.
사용자 및 서버 상태 모니터링 (User 및 Server Health Monitoring)
RRAS 및 DirectAccess 의 모니터링 및 진단 기능은 Windows Server 2008 R2 에서는 극히
제약적이었습니다. DirectAccess 를 위한 모니터링 기능은 DirectAccess 및 구성요소의 기본적인 상태
모니터링을 포함합니다. 가용한 모니터링 데이터 및 통계 정보는 관리자에게 약간 부족하고 분명하지
않습니다.
Windows Server 2012 에 소개된 사용자 및 서버 상태 모니터링 기능을 사용하여, 관리자는 DirectAccess
클라이언트 및 연결의 모든 상태 및 동작을 확인할 수 있습니다. 모니터링 콘솔은 DirectAccess 서버의
부하, 사용자 행위 및 현재 자원 사용률을 추적하기 위해 사용됩니다. 관리자는 이러한 정보를 사용하여
잠재적으로 원하지 않는 또는 적절하지 않은 사용 행태를 구분합니다. 진단 추적은 모니터링 콘솔에서
활성화할 수 있습니다.
사용자 모니터링
원격 접근 솔루션의 관리자는 원격 서버에 연결한 사용자 뿐만 아니라 사용자들이 접근한 자원들에 대한
모니터링이 기능이 필요합니다. 원격 사용자가 특정 서버 및 파일 공유에 접근할 수 없는 반면에 다른
페이지 16 / 89
사용자는 동일 자원에 대해서 성공적으로 접근할 수 있다면, 관리자는 현재 이러한 문제에 대해서 추적할
수 있는 방법이 없습니다. 특정 사용자가 과도하게 대역폭을 점유하는 것과 같은 문제를 트러블슈팅하기
위해 전통적으로 여러 도구 및 어플리케이션이 필요합니다.
내비게이션 창내의 Dashboard 탭을 선택함으로써, 신규 Remote Access 서버 관리 콘솔에서
Dashboard 를 접근할 수 있습니다. Dashboard 는 전체적인 운영 상태 및 원격 클라이언트 상태 및
행위를 보여줍니다. 또한 관리자는 dashboard 로부터 직접적인 빠른 보고서를 볼 수 있습니다.
모니터링 dashboard 는 다음 항목을 위한 원격 클라이언트 연결 상태의 요약을 보여줍니다. 다음 정보는
성능 모니터 카운터 및 accounting 데이터로부터 생성됩니다.
Total number of active remote clients connected – DirectAccess 및 VPN 서버 모두 연결된
원격 클라이언트 전체 숫자
Total number of active DirectAccess clients connected – 오로지, DirectAccess 서버에 연결된
전체 클라이언트 숫자
Total number of active VPN clients connected – 오로지, VPN 서버에 연결된 전체 클라이언트
숫자
Total unique users connected – includes both DirectAccess and VPN users, based on the
active connections
Total number of cumulative connections – the total number of connections serviced by the
Remote Access Server since the last server restart
Maximum number of remote clients connected – the maximum concurrent remote users
connected to the Remote Access Server since the last server restart
Total data transferred – the total inbound and outbound traffic from the Remote Access
Server for both DirectAccess and VPN since the last server restart
Inbound traffic – Total bytes/traffic into the remote access server/gateway
Outbound traffic – Total bytes/traffic out of the remote access server/gateway
클러스터 배포에서, Remote Access Dashboard 상의 원격 클라이언트 행위 및 상태 요약은 클러스터
내의 모든 노드의 총합입니다.
관리자는 현재 연결된 모든 원격 사용자들을 확인할 수 있고, 특정 원격 사용자를 클릭함으로써 특정
사용자가 접근할 수 있는 모든 자원 항목도 볼 수 있습니다. Remote Access 관리 콘솔 내의 “Remote
Client Status” 링크를 선택함으로써, 관리자는 원격 사용자 통계정보를 볼 수 있습니다. 사용자 통계
정보는 아래 필드를 통해 필터링할 수 있습니다:
Field Name Value
Username The user name or alias of the remote user. Wildcards may be used to select a group
페이지 17 / 89
of users, such as contoso\* or *\administrator. If no domain is specified, then
*\username is assumed.
Usergroup All the users in the specified AD security group.
Hostname The computer account name of the remote user. An IPv4 or IPv6 address can be
specified as well.
Type
Either DirectAccess or VPN. If DirectAccess is selected, then all remote users
connecting using DirectAccess are listed. If VPN is selected, then all remote users
connecting using VPN are listed.
ISP address The IPv4 or IPv6 address of the remote user
IPv4 address The inner IPv4 address of the tunnel connecting the remote user to the corporate
network
IPv6 address The inner IPv6 address of the tunnel connecting the remote user to the corporate
network
Protocol/Tunnel The transitioning technology used by the remote client – Teredo, 6to4 or IP-HTTPS
in case of DirectAccess users, and PPTP, L2TP, SSTP or IKEv2 in case of VPN users
Accessing All users accessing a particular corporate resource or an endpoint. The value
corresponding to this field is the hostname/IP address of the server/endpoint
서버 운영 상태
관리자가 중앙화된 모니터링 콘솔에서 원격 접근 배포의 상태를 관리 및 모니터링 할 수 기능이 “서버
운영 상태 (Server Operational Status)” 입니다. 주의가 요구되는 문제가 검출될 때마다, 이 기능은
관리자에게 경보를 알려줍니다. 이 기능은 문제 해결 단계를 포함한 상세 진단 정보를 보여줍니다.
컨솔 트리의 Dashboard 노드는 Remote Access Server 의 상태를 보여줍니다. 콘솔 트리의 서버
Operations Status 노드는 Remote Access Server 의 상태를 보여줍니다. 특정 구성 요소를
클릭함으로써, 관리자는 해당 구성요소의 상세 상태, 변경 기록 및 모니터링 정보를 볼 수 있습니다.
Remote Access Server 가 클러스터 또는 다중사이트에서 배포되었다면, 클러스터 또는 다중사이트 내의
모든 서버들은 비동기적으로 평가되고, 서버들의 전반적인 상태를 볼 수 있습니다. 관리자는 서버
항목들을 스크롤 할 수 있고, DirectAccess 및 VPN 서버 구성요소들을 확장 및 축소하여 확인할 수
있습니다.
Server Operational Status 에서 확인할 수 있는 Remote Access 구성 요소는 아래와 같습니다:
6to4
DNS
페이지 18 / 89
DNS64
Domain controller
IP-HTTPS
IPsec
ISATAP
Kerberos
Management Servers
NAT64
Network Adapters
Network Location Server
Network Security (IPsec DoSP)
Services
Teredo
Load Balancing
VPN addressing
VPN connectivity
진단 (Diagnostics)
RRAS 및 DirectAccess 서버에 대한 원격 접근 연결 실패 원인 분석은 현재 제공되는 제한된 로깅 때문에
상당히 복잡합니다. 전형적으로, 관리자는 원인 분석을 위해 네트워크 모니터 캡처 및 RRAS 추적을
사용합니다. 특히, 이벤트 뷰어 로그는 원인 분석을 위해 필요한 정보를 제공하지 못 합니다.
Windows Server 2012 는 원격 접근 원인 분석을 위해 향상된 진단 기능을 제공합니다.
DirectAccess 를 위한 상세 이벤트 로깅 (Detailed event logging for DirectAccess)
추적 및 패킷 캡처 (Tracing and Packet Capture) : Start tracing 태스크
로그 상관관계 (Log Correlaton)
로그 활성화 및 보기 (Enabling/Viewing Logs)
Accounting 및 Reporting
A Windows Server 2012 remote access server can leverage an existing RADIUS server deployment or
Windows Internal Database (WID) for accounting purposes. The NPS accounting store only contains
user statistics, and server statistics and configuration changes are not stored in the remote
accounting store. Information and historical data for load and server status are available through
system Performance Monitor counters, and are stored in the WID accounting store. Whenever any
페이지 19 / 89
connection is received or disconnected on the remote access server, all the remote user statistics
(including the endpoints accessed) is saved in the accounting store as one user session. This allows
session details to later be accessed for reporting and auditing purposes.
The accounting and reporting functionality provided in the Remote Access Server Role includes the
ability to measure specific metrics. Available metrics include the number of users connected to a
particular DirectAccess server, access status, and total bytes transferred. Administrators can create
custom reports to identify traffic and usage patterns, including a history of these patterns.
DirectAccess and RRAS reporting capabilities enable administrators to generate rich usage reports on
various user and server statistics such as remote user statistics, server availability and load. The inbox
accounting store is leveraged to generate the usage report. Inbox accounting to a local WID database
must be enabled in order to generate usage reports. NPS/RADIUS accounting is not used for
generating reports.
The usage report provides a display of usage history including which users established remote
connections, what resources they accessed, the total number of unique users, and maximum server
load generated. The administrator can select a specific timeframe from which to generate the data.
Site-to-Site IKEv2 IPsec 터널 모드 VPN
서비스 호스팅 제공자가 고객 어플리케이션 및 인프라를 클라우드 쪽으로 마이그레이션 할 수 있도록,
Windows Server 2012 는 Cross Premise 연결을 제공합니다. Cross Premise 연결 기능은 site-to-site
IKEv2 터널 모드 VPN 연결 솔루션 및 관리 인터페이스를 포함합니다. IKEv2 를 지원하는 RRAS VPN
연결은 Windows Server 2008 R2 에서 지원되었습니다. 클라이언트가 특정 네트워크에서 다른
네트워크로 이동할 때 또는 클라이언트의 네트워크 환경이 유선에서 무선으로 변경될 때, 이러한 다양한
네트워크 환경 변화에도 탄력적으로 VPN 서버에 VPN 클라이언트가 연결할 수 있는 기능을 IKEv2 가
지원합니다. IKEv2 및 IPsec 사용하여, 강한 인증 및 보안 방법을 구현할 수 있습니다. Windows Server
2012 RRAS 는 site-to-site VPN 연결에서 IKEv2 를 사용할 수 있는 부가적인 향상된 기능을 지원합니다.
페이지 20 / 89
IPv4 only 네트워크 환경에서 DirectAccess 설치 및 구성
개요
테스트 랩 개요
아래와 같이 총 4 대의 서버 컴퓨터와 2 대의 클라이언트 컴퓨터를 사용하여, 단일 DirectAccess 서버를
구축하기 위해 방법을 테스트합니다. 각 컴퓨터의 역할은 아래와 같습니다:
DC1 : Windows Server 2012, Domain Controller, Domain Name System (DNS), 및 Dynamic
Host Configuration Protocol (DHCP)
EDGE1 : Windows Server 2012, DirectAccess 서버
APP1 : Windows Server 2012, 일반 어플리케이션 서버, 웹 서버
INET1 : Windows Server 2012, 인터넷 DHCP 서버, DNS 서버 및 웹 서버
CLIENT1 : Windows 8, DirectAccess 클라이언트
NAT1 : Windows XP , Internet Connection 공유를 사용한 NAT 디바이스 역할
Direct Access 서버 구축 테스트 환경을 위해 아래와 같이 총 3 개의 네트워크를 구성합니다:
인터넷 영역 : Internet (131.107.0.0/24).
EDGE1 서버의 인터넷 네트워크 영역과 구분되는 인트라넷 영역 : Corpnet (10.0.0.0/24).
인터넷과 연결된 NAT에 의해 구분되는 홈 네트워크 영역 : Homenet (192.168.137.0/24)
컴퓨터들은 아래 그림과 같이 허브 또는 스위치를 사용하여 연결된 각 서브넷에 존재합니다
페이지 21 / 89
Windows Server 2012 DirectAccess 는 단순화된 원격 접근 솔루션을 배포하기 위해 IPv6 배포 또는 PKI
인프라가 더 이상 필수 조건이 아닙니다. 본 테스트 환경에서, 인증서가 필요하지 않은 IPv4 환경에서만
DirectAccess 를 구축하는 방법을 소개합니다.
하드웨어 및 소프트웨어 요구사항
이번 테스트 랩에 필요한 하드웨어 및 소프트웨어 구성 요소는 아래와 같습니다.
The product disc or files for Windows Server 2012.
The product disc or files for Windows 8.
Five computers or virtual machines that meet the minimum hardware requirements for
Windows Server 2012.
페이지 22 / 89
DirectAccess 테스트랩 구성 절차 (for Windows 8 Client)
“Remote Access express 설정”을 사용하여 “DirectAccess” 서버의 배포를 설정하기 위해서는 아래 총
4 단계를 수행해야 합니다.
Note
이 과정을 수행하기 위해서는 반드시 Domain Admins 그룹 구성원으로 각 서버를 로그인해야 합니다.
Step 1: Complete the Base Configuration Test Lab - 기본 구성 테스트 랩을 구성합니다.
기본 테스트 랩 구성 및 Homenet 기본 테스트 랩 구성은 다음 링크를 참조합니다. Test Lab
Guide: Windows Server "8" Beta Base Configuration with Optional mini-module: Homenet
subnet
Step 2: Configure DC1. DC1 은 사전에 도메인 컨트롤러 구성되어 있어야 합니다. 또한,
추가적으로 DNS 및 DHCP 서비스가 구성되어야 합니다. DirectAccess 클라이언트를 구성원으로
지정할 수 있도록 Active Directory 에 보안 그룹을 생성합니다.
Step 3: Configure EDGE1. EDGE1 은 사전에 도메인 멤버 서버를 구성되어 있어야 합니다.
EDGE1 서버는 DirectAccess 서버로 구성됩니다.
Step 4: Configure CLIENT1. CLIENT1 컴퓨터는 사전에 도메인 멤버 클라이언트로 구성되어
있어야 합니다. 이 컴퓨터는 추후 DirectAccess 클라이언트 역할을 수행합니다.
페이지 23 / 89
Step 1 : 기본 테스트 랩 설정
이번 단계에서는 Test Lab Guide: Windows Server "8" Beta Base Configuration 링크의 “Steps for
Configuring the Corpnet Subnet” 및 “Steps for Configuring the Internet Subnet” 부분을 참조하여
Corpnet 및 Internet 서브넷 테스트 환경 구축을 완료합니다. 또한, Optional mini-module: Homenet
subnet 링크를 참조하여 Homenet 서브넷 구성도 완료합니다.
본 테스트 환경에서는 PKI 인프라가 필요치 않으므로, 다음 링크는 Optional mini-module: Basic PKI
수행하지 않습니다.
페이지 24 / 89
Step 2 : DC1 구성
이번 단계에서는 DirectAccess 클라이언트 역할을 수행하는 도메인 클라이언트 컴퓨터들을 구성하는
보안 그룹을 Active Directory 에 생성합니다. DirectAccess 를 구성할 때, DirectAccess 설정을 포함하는
GPO 를 자동으로 생성합니다. 이러한 GPO 설정은 DirectAccess 서버 및 클라이언트에 적용됩니다. 아래
단계는 자동적으로 생성되는 DirectAccess 클라이언트를 위한 GPO 설정이 적용될 보안 그룹을
생성합니다.
1. 도메인 관리자 계정으로 DC1 서버에 로그인합니다.
2. 도메인 컨트롤러에서, Active Directory Administrative Center 도구를 수행합니다. Start 를
클릭한 후, Active Directory Administrative Center 를 클릭합니다.
3. 콘솔 트리에서, “CORP (local)” 를 확장하기 위해 화살표를 클릭한 후, Users를 클릭합니다.
4. Tasks 창에서, New -> Group 를 클릭합니다.
페이지 25 / 89
5. Create Group 다이얼로그에서, Group name 부분에 DirectAccessClients 를 입력합니다.
6. Create Group 다이얼로그의 Members 부분에 접근하기 위해 마우스를 스크롤 다운 한 후,
Add를 클릭합니다.
페이지 26 / 89
7. Object Types를 클릭한 후, Computers를 선택한 후, OK를 클릭합니다.
8. CLIENT1를 입력한 후, OK를 클릭합니다.
페이지 27 / 89
9. Create Group 다이얼로그를 닫기 위해 OK를 클릭합니다.
위와 같이 DirectAccessClients 보안 그룹을 생성한 후, 아래와 같이 Active Directory Users and
Computers 도구에서 확인할 수 있습니다.
10. Active Directory Administrative Center 를 닫습니다.
위 전체 과정은 아래와 같은 Windows PowerShell 을 사용하여 구성할 수도 있습니다.
New-ADGroup -GroupScope global -Name DirectAccessClients
Add-ADGroupMember -Identity DirectAccessClients -Members CLIENT1$
페이지 28 / 89
Step 3 : EDGE1 구성
이번 단계에서는, IPv4-only 환경에서 DirectAccess 서버 구축을 위해 EDGE1 서버에 Remote Access
서버 역할 설치 및 구성하는 방법을 확인합니다. 아래와 같이 2 가지 단계를 통해 설치 및 구성을
진행합니다.
EDGE1 서버에 Remote Access 서버 역할 설치
Getting Started 마법사를 사용하여 단순화된 DirectAccess 배포
위 2 가지 단계의 상세 절차는 아래와 같습니다.
EDGE1 서버에 Remote Access 서버 역할 설치
Windows Server 2012 Remote Access 서버 역할은 DirectAccess 기능과 RRAS 역할 서비스가 결합된
형태로 제공됩니다. 신규 Remote Access 서버 역할은 DirectAccess 및 VPN 의 관리, 구성 및 모니터링을
수행하기 위한 중앙화된 단일 관리 도구를 제공합니다.
1. 도메인 관리자 계정으로 EDGE1 서버에 로그인합니다.
2. 서버 관리자가 자동으로 시작될 것 입니다. 만약, 서버 관리자가 자동으로 시작되지 않는다면,
Start를 클릭한 후, servermanager.exe를 입력하고, Server Manager를 클릭합니다.
3. QUICK START 부분에서, Add roles and features를 클릭합니다.
4. 서버 역할 선택 페이지로 진행하기 위해, Next 를 3번 연속 클릭합니다.
5. 서버 역할 선택 페이지에서, Remote Access 를 선택한 후, Add Features를 선택한 후, Next 를
클릭합니다.
페이지 29 / 89
6. 기능, Remote Access 역할 서비스 및 Web 서버 역할 서비스의 기본을 그대로 유지하기 위해,
Next 를 5번 연속 클릭합니다.
7. Confirmation 페이지에서, Install 을 클릭합니다.
페이지 30 / 89
8. 기능 설치가 완료된 후, Close 를 클릭합니다.
페이지 31 / 89
위 전체 과정은 아래와 같은 Windows PowerShell 을 사용하여 구성할 수도 있습니다.
Install-WindowsFeature RemoteAccess -IncludeManagementTools
Getting Started 마법사를 사용하여 단순화된 DirectAccess 배포
신규 Getting Started 마법사는 DirectAccess 구성을 아주 단순하게 처리할 수 있는 방법을 제공합니다.
마법사는 DirectAccess 구성의 복잡성을 제거하고, 몇 개의 단순 단계는 자동화된 설정 방법을
제공합니다. 또한, Windows Server 2008 R2 DirectAccess 구성 시에 필수적인 요소인 내부 PKI 배포는
이제 Windows Server 2012 DirectAccess 구성 시에는 필수적인 요소가 아닙니다. 즉, Windows Server
2012 DirectAccess 구성에서 Kerberos Proxy 를 자동적으로 구성함으로써 내부 PKI 배포를 대체할 수
있습니다.
1. 도메인 관리자 계정으로 EDGE1 서버에 로그인합니다.
2. EDGE1 서버에서, Remote Access Management 도구를 수행합니다. Start 를 클릭한 후,
Remote Access Management 를 클릭합니다.
페이지 32 / 89
3. Remote Access Management 콘솔에서, Run the Getting Started 마법사를 클릭합니다.
4. Deploy DirectAccess Only 를 클릭합니다.
페이지 33 / 89
5. 네트워크 토폴로지로써 Edge 방식이 선택되어 있음을 확인합니다. Remote Access
클라이언트가 연결할 공개 이름으로써 EDGE1.CONTOSO.com을 입력한 후, Next 를
클릭합니다.
6. 마지막 마법사 페이지에서, 마법사 설정을 편집하기 위해 제공되는 Here 링크를 클릭합니다.
7. Remote Access Review 다이얼로그에서, Remote Clients 옆의 Change를 클릭합니다.
페이지 34 / 89
8. Select Groups 페이지에서, Enable DirectAccess for the mobile computers only 체크 상자를
비활성화합니다.
페이지 35 / 89
9. Domain Computers (CORP\Domain Computers) 를 클릭한 후, Remove 를 클릭합니다.
10. Add를 클릭한 후, DirectAccessClients 를 입력한 후, OK를 클릭합니다.
11. Next를 클릭한 후, Finish를 클릭합니다. 추후, DirectAccess 클라이언트가 Internet 영역이나
Homenet 영역에서 DirectAccess 서버에 정상적으로 연결되면, “Workplace Connection” 으로
네트워크 연결 이름이 보여짐을 확인할 수 있습니다.
페이지 36 / 89
12. Remote Access Review 페이지에서 OK를 클릭한 후, Finish를 클릭합니다.
페이지 37 / 89
13. 본 테스트 환경에서 PKI 환경이 없으므로, 마법사는 IP-HTTPS 및 Network Location Server
용도의 self-signed 인증서를 자동으로 생성합니다. 또한, 마법사는 자동적으로 Kerberos
Proxy를 활성화합니다. 또한, 마법사는 IPv4-only 환경을 위해 프로토콜 전환을 위한 NAT64 및
DNS64도 자동적으로 구성합니다. 마법사가 성공적으로 구성을 완료한 후, Close를 클릭합니다.
페이지 38 / 89
14. Remote Access Management 콘솔의 콘솔 트리에서, Operation Status를 선택합니다. 모든
모니터 항목의 상태가 “Working”로 보여질 때까지 기다립니다. Monitoring -> Task 창에서,
디스플레이를 정기적으로 업데이트하기 위해 Refresh를 클릭합니다.
15. 위와 같이 DirectAccess 구성이 성공적으로 완료된 후, GPMC 도구에서 아래와 같이
DirectAccess 구성에 연관된 “DirectAccess Clients Setting” 및 “DirectAccess Servers Setting”
2 개의 GPO 가 자동적으로 생성되어 있음을 확인할 수 있습니다.
페이지 39 / 89
16. 또한, 아래와 같이 DNS 에 자동적으로 DirectAccess 서버 구성과 관련된 HOST 항목들이
등록되어 있음을 확인할 수 있습니다.
17. 또한, EDGE1 서버의 “인증서 -> Local Computer -> Personal -> Certificates” 에서 총 3 개의
Self-Signed 인증서가 자동적으로 생성되어 있음도 확인할 수 있습니다.
페이지 40 / 89
Step 4 : CLIENT1 구성
CLIENT1 컴퓨터의 Remote Access 연결성에 대한 검증을 위해 아래와 같이 총 4 단계를 수행합니다:
CLIENT1 컴퓨터를 Corpnet 서브넷에 연결한 후, 그룹정책 업데이트
CLIENT1 컴퓨터를 Internet 서브넷에 연결한 후, 원격 연결 테스트
CLIENT1 컴퓨터를 Homenet 서브넷에 연결한 후, 원격 연결 테스트
EDGE1 DirectAccess 서버 상에서 클라이언트 연결 모니터
CLIENT1 컴퓨터를 Corpnet 서브넷에 연결한 후, 그룹정책 업데이트
1. CLIENT1 컴퓨터를 Corpnet 서브넷에 연결한 후, 명령어 창에서 gpupdate /force 를
수행합니다.
2. CLIENT1 컴퓨터에서, Windows PowerShell 도구를 관리자 권한으로 수행합니다. Start 를
클릭한 후, PowerShell 을 입력한 후, Windows PowerShell 를 오른쪽 마우스 클릭 한 후, Run
as Administrator 를 클릭합니다.
페이지 41 / 89
3. Get-DnsClientNrptPolicy 를 입력한 후, Enter 를 누릅니다. DirectAccess 를 위한 NRPT(Name
Resolution Policy Table) 항목이 보여집니다. 이 항목에서, NLS 서버 배제 항목이 DirectAccess-
NLS.corp.contoso.com 으로 보여짐을 확인할 수 있습니다. DirectAccess-
NLS.corp.contoso.com FQDN 은 Getting Started 마법사에서 자동적으로 생성된 DirectAccess
서버를 위한 DNS 항목입니다. 또한, DirectAccess 서버가 NLS(Network Location Server) 역할을
수행할 수 있도록, DirectAccess-NLS.corp.contoso.com 라는 Self-Signed 인증서도 자동으로
구성되어 있습니다.
4. Get-NCSIPolicyConfiguration 를 입력한 후, Enter 를 누릅니다. 마법사에 의해 배포된
“네트워크 연결성 상태 지시자 (Network Connectivity Status Indicator)”의 항목을 확인할 수
있습니다. DomainLocationDeterminationURL 값이 https://DirectAccess-
NLS.corp.contoso.com:443/insideoutside 임을 확인합니다. NLS URL 을 클라이언트에서 연결
가능하다면, 클라이언트는 Corp 서브넷에 존재함을 의미하고, 결론적으로 NRPT 설정은
적용되지 않습니다.
페이지 42 / 89
5. Get-DAConnectionStatus 를 입력한 후, Enter 를 누릅니다. 클라이언트가 NLS URL 에 접근할
수 있기 때문에, 상태는 “ConnectedLocally” 임을 확인할 수 있습니다.
CLIENT1 컴퓨터를 Internet 서브넷에 연결한 후, 원격 연결 테스트
1. CLIENT1 컴퓨터를 Internet 서브넷에 연결합니다. 네트워크 위치 결정 프로세스 과정이 완료된
후, 네트워크 아이콘이 인터넷 영역을 지시함을 확인합니다.
2. CLIENT1 컴퓨터에서, Windows PowerShell 도구를 관리자 권한으로 수행합니다. Start 를
클릭한 후, PowerShell 을 입력한 후, Windows PowerShell 를 오른쪽 마우스 클릭 한 후, Run
페이지 43 / 89
as Administrator 를 클릭합니다. Get-DAConnectionStatus 를 입력한 후, Enter 를 누릅니다.
상태는 “ConnectedRemotely” 임을 확인할 수 있습니다.
3. 시스템 알림 영역 내의 네트워크 아이콘을 클릭합니다. Workplace Connection 항목이
Connected 상태임을 확인합니다. 이 네트워크 연결 항목 이름은 앞서 DirectAccess 마법사를
사용하여 자동으로 제공된 이름입니다.
(주의) Windows 8 클라이언트의 경우, 위 화면에서 “Workplace Connection” 부분이 “연결 중” 상태가
유지되는 경우가 있을 수 있습니다. 이때, 아래 명령어를 사용하여 6to4 인터페이스를 “비활성화” 합니다.
Netsh interface 6to4 set state state=disabled
4. Workplace Connection 을 오른쪽 마우스 클릭한 후, Properties 를 클릭합니다. 상태가
Connected 임을 확인할 수 있습니다.
페이지 44 / 89
5. PowerShell 에서, ping inet1.isp.example.com 을 수행하여 본 테스트 환경에서의 인터넷 연결
및 이름 해결이 정상적임을 확인합니다. 아래와 같이 131.107.0.1 로부터 총 4 번의 응답을
확인할 수 있습니다.
6. 또한, 현재 CLIENT1 이 인터넷 영역에 있음에도 불구하고, DirectAccess 클라이언트 기능을
이용하여, 인트라넷 영역의 이름 해결 및 연결이 정상적임을 확인하기 위하여 ping
app1.corp.contoso.com 을 수행합니다. 응답이 IPv6 형식으로 반환됨을 확인합니다. 본 테스트
랩 환경에서 어떠한 IPv6 인프라도 없기 때문에, 자동으로 생성된 APP1 서버의 NAT64 주소가
반환됨을 확인합니다. NAT64 를 위해 DirectAccess 에 의해 자동으로 할당된 Prefix 는
fdxx:xxxx:xxxx:7777::/96 형식임을 반드시 확인합니다.
페이지 45 / 89
7. CLIENT1 에서 IE 를 수행합니다. 다음 2 개의 웹사이트를 접근하여 정상적으로 수행됨을
확인합니다. http://inet1.isp.example.com 및 http://app1.corp.contoso.com 서버의 IE
결과를 확인합니다.
페이지 46 / 89
8. CLIENT1 에서 윈도우 탐색기를 수행한 후, 주소 창에서 \\app1\Files 라는 공유 폴더를
접근하여 정상적으로 공유 폴더가 접근됨을 확인합니다.
9. PowerShell 에서, Get-NetIPAddress 를 입력한 후, ENTER 를 누립니다. CLIENT1 컴퓨터의 IPv6
주소 구성을 확인합니다. “터널 어댑터 iphttpsinterface”에 유효한 IP-HTTPS 주소가
활성화되어 있음을 확인합니다. CLIENT1 은 EDGE1 서버로의 IPv6 트래픽을 터널링하기 위해
IP-HTTPS 를 사용합니다.
페이지 47 / 89
페이지 48 / 89
10. 또한, PowerShell 에서, Get-NetIPHTTPSConfiguration 를 입력한 후, ENTER 를 누립니다.
DirectAccess 클라이언트가 https://edge1.contoso.com/IPHTTPS 를 연결하기 위해 그룹
정책에 의해 적용된 설정 사항을 확인합니다.
11. CLIENT1 에서 Windows Firewall with Advanced Security 콘솔을 수행하기 위해, wf.msc 를
명령어 창에서 수행합니다. Monitoring 항목에서, 연결된 IPsec SA 를 확인하기 위해 Security
Association 를 클릭합니다. 사용된 인증 방법이 컴퓨터 Kerberos 및 사용자 Kerberos 임을
확인할 수 있습니다. 즉, 어떠한 인증서 기반의 인증 방법이 사용되지 않았음을 확인할 수
있습니다. 즉, 앞서 초기에 언급한 것처럼, Windows Server 2012 DirectAccess 단순 구성
방법에서 자동으로 구성한 Kerberos Proxy 방법이 사용되었음을 다시 한 번 확인할 수
있습니다. 그러나, Enterprise 환경에서 DirectAccess 서버를 2 대 이상 운영하기 위해서는,
인증서 기반의 인증 방법을 별도로 구성해야 함을 유념해야 합니다. 또한, DirectAccess 연결을
위해 사용된 정책은 Connection Security Rules 항목에서 확인할 수 있습니다.
페이지 49 / 89
12. Windows Firewall with Advanced Security 콘솔을 닫습니다.
13. 마지막으로, EDGE1 서버의 Remote Access Management 콘솔의 REMOTE CLIENT STATUS
부분에서 연결된 CLIENT1 컴퓨터를 확인할 수 있습니다.
페이지 50 / 89
CLIENT1 컴퓨터를 Homenet 서브넷에 연결한 후, 원격 연결 테스트
1. CLIENT1 컴퓨터를 Homenet 서브넷에 연결합니다. 네트워크 위치 결정 프로세스 과정이
완료된 후, 네트워크 아이콘이 인터넷 영역을 지시함을 확인합니다.
2. CLIENT1 컴퓨터에서, Windows PowerShell 도구를 관리자 권한으로 수행합니다. Start 를
클릭한 후, PowerShell 을 입력한 후, Windows PowerShell 를 오른쪽 마우스 클릭 한 후, Run
as Administrator 를 클릭합니다. Get-DAConnectionStatus 를 입력한 후, Enter 를 누릅니다.
상태는 “ConnectedRemotely” 임을 확인할 수 있습니다.
3. 시스템 알림 영역 내의 네트워크 아이콘을 클릭합니다. Workplace Connection 항목이
Connected 상태임을 확인합니다. 이 네트워크 연결 항목 이름은 앞서 DirectAccess 마법사를
사용하여 자동으로 제공된 이름입니다.
페이지 51 / 89
4. Workplace Connection 을 오른쪽 마우스 클릭한 후, Properties 를 클릭합니다. 상태가
Connected 임을 확인할 수 있습니다.
5. 현재 CLIENT1 이 Homenet 영역에 있음에도 불구하고, DirectAccess 클라이언트 기능을
이용하여, 인트라넷 영역의 이름 해결 및 연결이 정상적임을 확인하기 위하여 ping
app1.corp.contoso.com 을 수행합니다. 응답이 IPv6 형식으로 반환됨을 확인합니다. 본 테스트
랩 환경에서 어떠한 IPv6 인프라도 없기 때문에, 자동으로 생성된 APP1 서버의 NAT64 주소가
반환됨을 확인합니다. NAT64 를 위해 DirectAccess 에 의해 자동으로 할당된 Prefix 는
fdxx:xxxx:xxxx:7777::/96 형식임을 반드시 확인합니다.
페이지 52 / 89
6. CLIENT1 에서 IE 를 수행합니다. 다음 2 개의 웹사이트를 접근하여 정상적으로 수행됨을
확인합니다. http://inet1.isp.example.com 및 http://app1.corp.contoso.com 서버의 IE
결과를 확인합니다.
페이지 53 / 89
7. CLIENT1 에서 윈도우 탐색기를 수행한 후, 주소 창에서 \\app1\Files 라는 공유 폴더를
접근하여 정상적으로 공유 폴더가 접근됨을 확인합니다.
8. PowerShell 에서, Get-NetIPAddress 를 입력한 후, ENTER 를 누립니다. CLIENT1 컴퓨터의 IPv6
주소 구성을 확인합니다. “터널 어댑터 iphttpsinterface”에 유효한 IP-HTTPS 주소가
활성화되어 있음을 확인합니다. CLIENT1 은 EDGE1 서버로의 IPv6 트래픽을 터널링하기 위해
IP-HTTPS 를 사용합니다. 以前 DirectAccess 버전에서, 본 테스트 환경과 같은 NAT 후면에
위치한 사설 IPv4 주소를 가진 클라이언트는 Teredo IPv6 주소 변환 기술을 사용하여 내부
인트라넷 자원에 연결했었습니다. 그러나, Windows Server 2012 DirectAccess 는 오로지 IP-
HTTPS 기술만을 사용하여 내부 인트라넷 자원에 연결합니다.
페이지 54 / 89
9. 또한, PowerShell 에서, Get-NetIPHTTPSConfiguration 를 입력한 후, ENTER 를 누립니다.
DirectAccess 클라이언트가 https://edge1.contoso.com/IPHTTPS 를 연결하기 위해 그룹
정책에 의해 적용된 설정 사항을 확인합니다.
10. CLIENT1 에서 Windows Firewall with Advanced Security 콘솔을 수행하기 위해, wf.msc 를
명령어 창에서 수행합니다. Monitoring 항목에서, 연결된 IPsec SA 를 확인하기 위해 Security
Association 를 클릭합니다. 사용된 인증 방법이 컴퓨터 Kerberos 및 사용자 Kerberos 임을
페이지 55 / 89
확인할 수 있습니다. 즉, 어떠한 인증서 기반의 인증 방법이 사용되지 않았음을 확인할 수
있습니다. 즉, 앞서 초기에 언급한 것처럼, Windows Server 2012 DirectAccess 단순 구성
방법에서 자동으로 구성한 Kerberos Proxy 방법이 사용되었음을 다시 한 번 확인할 수
있습니다. 그러나, Enterprise 환경에서 DirectAccess 서버를 2 대 이상 운영하기 위해서는,
인증서 기반의 인증 방법을 별도로 구성해야 함을 유념해야 합니다. 또한, DirectAccess 연결을
위해 사용된 정책은 Connection Security Rules 항목에서 확인할 수 있습니다.
11. Windows Firewall with Advanced Security 콘솔을 닫습니다.
12. 마지막으로, EDGE1 서버의 Remote Access Management 콘솔의 REMOTE CLIENT STATUS
부분에서 연결된 CLIENT1 컴퓨터를 확인할 수 있습니다.
페이지 56 / 89
페이지 57 / 89
DirectAccess 클라이언트를 위한 DirectAccess 구성 절차 (for Windows 8 &
Windows 7)
앞서 Getting Started 마법사를 사용하여 구성한 Windows Server 2012 DirectAccess 서버는 오로지
Windows 8 클라이언트만 지원 가능합니다. Windows Server 2012 DirectAccess 서버에서 Windows 7
클라이언트를 DirectAccess 클라이언트로 지원하기 위해서는 별도의 설정이 필요합니다. 기본적으로
앞서 Getting Started 마법사를 사용하여 생성한 DirectAccess 구성은 제거한 후, 별도의 구성 방법을
사용해야 하고, 事前에 DirectAccess 클라이언트에게 필요한 “컴퓨터 인증서” 발급을 위한 PKI 인프라도
필요합니다.
페이지 58 / 89
Step 1 : 기존 DirectAccess 구성 제거
이번 단계에서는 앞서 구성한 기존 DirectAccess 구성을 제거합니다.
1. 도메인 관리자 계정으로 EDGE1 서버에 로그인합니다.
2. EDGE1 서버에서, Remote Access Management 도구를 수행합니다. Start 를 클릭한 후,
Remote Access Management 를 클릭합니다.
3. 원격 액세스 관리 콘솔의 작업 -> 일반 -> 구성 설정 제거 링크를 클릭하여, 기존 구성을
제거합니다.
4. 제거 구성 확인 다이얼로그 상자에서 확인 버튼을 클릭하여 제거 작업을 진행합니다.
페이지 59 / 89
5. 구성 설정 제거 작업이 아래와 같이 완료된 후, 닫기 버튼을 클릭합니다.
6. 원격 액세스 관리 콘솔의 구성 부분에서 아래와 같이 “원격 액세스 구성” 부분이 보여짐을
확인할 수 있습니다.
페이지 60 / 89
이상과 같이 기존 DirectAccess 구성이 성공적으로 제거되었음을 반드시 확인합니다.
페이지 61 / 89
Step 2 : Windows 7 클라이언트 준비
Windows Server 2012 DirectAcces 의 Windows 7 클라이언트 지원을 위한 데모용 Windows 7 컴퓨터를
준비합니다. 기존 CORP 도메인에 죠인된 Windows 7 Enterprise 버전 이상의 컴퓨터를 준비합니다.
아래와 같이 데모용 Windows 7 컴퓨터를 확인합니다.
페이지 62 / 89
Step 3 : Windows 7 클라이언트를 위한 보안 그룹 생성
이제 앞서 구성한 Windows 8 클라이언트를 위한 DirectAccess 보안 그룹을 생성했습니다. 이번
단계에서는 Windows 7 클라이언트를 위한 DirectAccess 보안 그룹을 생성합니다.
1. 도메인 관리자 계정으로 DC1 서버에 로그인합니다.
2. 도메인 컨트롤러에서, Active Directory 사용자 및 컴퓨터 도구를 수행합니다. Start 를 클릭한
후, Active Directory 사용자 및 컴퓨터 를 클릭합니다.
3. Users 컨테이너를 오른쪽 마우스 클릭한 후, 새로 만들기 -> 그룹 순서로 클릭합니다.
4. 그룹 이름 부분에 “DirectAccessClientsWindows7”을 입력한 후, 확인 버튼을 클릭하여, 그룹을
생성합니다.
페이지 63 / 89
5. “DirectAccessClientsWindows7” 그룹의 구성원으로써 앞서 준비한 CLIENT2W7 컴퓨터를
추가합니다.
이상과 같이 Windows7 클라이언트를 위한 보안 그룹의 생성을 완료합니다.
페이지 64 / 89
Step 4 : 기존 도메인에 Private CA 설치 확인
Windows 7 클라이언트를 DirectAccess 2012 에서 지원하기 위해서는, 반드시 PKI 인프라가 필요합니다.
기존 CORP 도메인에 아래 링크를 참조하여 Private CA 설치 및 인증서 자동 발급을 위한 구성을
완료합니다.
Optional mini-module: Basic PKI ( http://go.microsoft.com/fwlink/p/?LinkId=244229 )
위 구성을 완료한 후, 아래와 같이 설치되었음을 확인합니다. 본 테스트 환경에서는 위 링크와는 다르게
DC1 서버에 Private CA 를 구성했습니다.
또한, DirectAccess 서버 및 DirectAccess 클라이언트의 인증서를 위한 인증서 템플릿은 위 링크와는
다르게 “컴퓨터 for MMC” 로 생성했습니다. 아래 그림과 같이 “컴퓨터 for MMC” 인증서 템플릿이
CORP-DC1-CA 인증 기관의 인증서 템플릿에 추가되어 있음을 확인합니다.
페이지 65 / 89
“컴퓨터 for MMC” 인증서 템플릿의 자동 발급을 위해 보안 설정을 확인합니다. “인증서 템플릿” 스냅-인
관리 도구에서 “컴퓨터 for MMC” 인증서 템플릿의 속성 -> 보안 설정을 확인합니다. “Domain
Computers” 그룹의 권한이 “읽기, 등록, 자동 등록” 으로 설정되어 있음을 확인합니다.
“컴퓨터 for MMC” 인증서 템플릿을 사용하여 “Domain Computers” 그룹의 모든 컴퓨터들에게
인증서를 자동 발급할 수 있도록, “Default Domain Policy” 의 “컴퓨터 구성 -> 정책 -> Windows 설정
-> 보안 설정 -> 공개 키 정책 -> 인증서 서비스 클라이언트 – 자동 등록” 의 속성이 아래와 같이
설정되어 있음을 확인합니다.
페이지 66 / 89
페이지 67 / 89
Step 5 : CA 의 CRL 외부 공개 구성
DirectAccess 클라이언트는 기본적으로 외부 네트워크 상에서 내부 네트워크로 접근하기 위해서는
DirectAccess 서버를 반드시 경유해야 합니다. 이때, DirectAccess 클라이언트와 DirectAccess 서버
사이의 통신을 위해서 사용되는 네트워크 인터페이스는 IPHTTPS 입니다. IPHTTPS 네트워크
인터페이스를 사용하기 위해서는 DirectAccess 클라이언트 및 서버는 반드시 앞서 구성한 인증서가
필요합니다. 여기에서 중요한 점은, DirectAccess 클라이언트 및 서버에 발급된 인증서에 포함된
CRL(Certificate Revocation List) 이 외부에서 접근 가능해야 합니다. CRL 은 기본적으로 LDAP 경로를
정의되어 있습니다.
1. 인증 기관 -> 속성 -> 확장 순서로 클릭하여, CRL 의 ldap 경로가 있음을 확인할 수 있습니다.
페이지 68 / 89
2. DirectAccess 클라이언트가 외부에서 CRL 경로를 접근하기 위해서는, 아래와 같이 http 경로를
활성화해야 합니다. http 경로를 선택한 후, 아래 옵션을 모두 선택합니다.
CRL 에 포함. 클라이언트에서 델타 CRL 위치를 찾도록 해줍니다(N).
발급된 인증서의 CDP 확장에 포함(I)
발급된 CRL 의 IDP 확장에 포함(L)
3. 추가적인 CRL 의 http 경로를 구성한 후, CA 서비스를 반드시 재시작합니다.
페이지 69 / 89
Step 6 : DirectAccess 서버 및 DirectAccess 클라이언트의 인증서 확인
앞서 “컴퓨터 for MMC” 인증서 템플릿의 자동 발급을 구성했으므로, DirectAccess 서버 및 DirectAccess
클라이언트의 인증서 발급 여부를 확인합니다. 각 컴퓨터의 “인증서 -> 로컬 컴퓨터” 스냅-인 관리
도구의 “인증서(로컬 컴퓨터) -> 개인용 -> 인증서” 폴더를 확인합니다.
EDGE1.CORP.CONTOSO.com (DirectAccess 서버)
인증서 속성의 “CRL 배포 지점”의 값에 아래와 같이 LDAP 및 HTTP 경로가 있음을 확인할 수 있습니다.
페이지 70 / 89
자동 등록으로 발급된 인증서가 아닌 EDGE1.CONTOSO.com 인증서가 존재함을 확인할 수 있습니다. 이
인증서는 별도로 발급받아야 합니다. 즉, 이 인증서는 DirectAccess 클라이언트가 외부에서 DirectAccess
서버를 접근할 때, 사용하는 Common Name (중요 : Public FQDN 과 반드시 동일해야 함) 을 포함한
인증서입니다. 또한, 이 인증서 역시 CRL 배포 지점에 HTTP 경로가 존재함을 확인할 수 있습니다.
페이지 71 / 89
CLIENT1.CORP.CONTOSO.com (DirectAccess 클라이언트 Windows 8)
아래와 같이 CLIENT1.CORP.CONTOSO.com 인증서를 확인합니다.
페이지 72 / 89
CLIENT2W7.CORP.CONTOSO.com (DirectAccess 클라이언트 Windows 7)
아래와 같이 CLIENT2W7.CORP.CONTOSO.com 인증서를 확인합니다.
페이지 73 / 89
Step 7 : DirectAccess 서버 구성
이미 Windows 8 클라이어트의 DirectAccess 지원을 위해 DirectAccess 서비스의 설치를 완료했습니다.
이제 Windows 7 및 Windows 8 의 DirectAccess 서비스 지원을 위한 DirectAccess 서버의 구성을
진행합니다.
1. 도메인 관리자 계정으로 EDGE1 서버에 로그인합니다.
2. EDGE1 서버에서, Remote Access Management 도구를 수행합니다. Start 를 클릭한 후,
Remote Access Management 를 클릭합니다.
3. Remote Access Management 콘솔에서, 원격 액세스 설정 마법사 실행을 클릭합니다.
4. Deploy DirectAccess 만 배포를 클릭합니다.
페이지 74 / 89
5. 원격 액세스 설정 부분의 단계 1 의 “구성” 버튼을 클릭합니다.
6. DirectAccess 클라이언트 설정 부분의 배포 시나리오 페이지에서, 배포 시나리오 선택에서
“클라이언트 액세스 및 원격 관리용으로 전체 DirectAccess 배포(U)” 를 선택한 후, 다음을
진행합니다.
7. DirectAccess 클라이언트 설정 부분의 그룹 선택 페이지에서, “DirectAccessClients” 및
“DirectAccessClientsWindows7” 그룹을 선택하여 DirectAccess 클라이언트로 적용될
클라이언트를 선택합니다. 나머지 옵션은 선택하지 않고 다음을 진행합니다.
페이지 75 / 89
8. DirectAccess 클라이언트 설정 부분의 네트워크 연결 길잡이 페이지에서, 기본 설정을 변경하지
않고, 마침을 진행합니다. “DirectAccess 연결 이름” 부분에서, “작업 공간 연결” 이라는 이름은
추후 DirectAccess 클라이언트가 DirectAccess 연결할 때, 클라이언트의 네트워크 연결 부분에
표시되는 이름입니다.
페이지 76 / 89
9. 원격 액세스 설정 부분의 단계 2 의 “구성” 버튼을 클릭합니다.
10. Remote Access 서버 설정 부분의 네트워크 토폴로지 페이지에서, “에지(E)” 를 선택한 후,
“클라이언트가 원격 액세스 서버에 연결하는 데 사용할 공개 이름 또는 IPv4 주소 입력(T):”
부분에 “EDGE1.CONTOSO.com” 을 입력한 후, 다음을 진행합니다. 실제 환경에서는
EDGE1.CONTOSO.com FQDN 과 해당 공인 IP 를 공인 DNS 에 등록해야 합니다.
11. Remote Access 서버 설정 부분의 네트워크 어댑터 페이지에서, 기본적으로 구성된 사항을
확인한 후, 다음을 진행합니다. 외부 네트워크 및 내부 네트워크에 연결된 어댑터가 정상적인
확인한 후, 앞서 구성한 EDGE1.CONTOSO.com 외부 공개 FQDN 에서 사용될 인증서가
정상적인지 확인합니다.
페이지 77 / 89
12. Remote Access 서버 설정 부분의 인증 페이지에서, “Windows 7 클라이언트 컴퓨터에서
DirectAccess를 통한 연결 사용(A)”를 선택하게 되면, 자동적으로 “컴퓨터 인증서 사용” 부분이
선택이 되고, “찾아보기” 버튼을 클릭하여, DirectAccess 클라이언트가 사용하는 인증서를
발급했던 “CA 루트 인증서 (CORP-DC1-CA)”를 선택한 후, 마침을 진행합니다.
페이지 78 / 89
13. 원격 액세스 설정 부분의 단계 3 의 “구성” 버튼을 클릭합니다.
14. 인프라 서버 설정 부분의 네트워크 위치 서버 페이지에서, “원격 액세스 서버에 네트워크 위치
서버 배포(D)”를 선택하게 되면, 자동적으로 “네트워크 위치 서버 인증에 사용할 인증서
선택(S):” 부분에 “CN=EDGE1.CORP.CONTOSO.com” 이라는 서버 인증서가 할당됩니다. 즉, 본
테스트 환경에서는 DirectAccess 를 위한 네트워크 위치 서버를 별도 서버에 구성하지 않고,
DirectAccess 서버에 구성합니다. 실제 환경에서는, 네트워크 위치 서버를 다른 별도에 위치
시킬 수도 있습니다. 다음을 진행합니다.
15. 인프라 서버 설정 부분의 DNS 페이지에서, 기본 설정 사항을 변경하지 않고, 다음을 진행합니다.
페이지 79 / 89
16. 인프라 서버 설정 부분의 DNS 접미사 검색 목록 페이지에서, 기본 설정 사항을 변경하지 않고,
다음을 진행합니다.
17. 인프라 서버 설정 부분의 관리 페이지에서, 기본 설정 사항을 변경하지 않고, 마침을 진행합니다.
페이지 80 / 89
18. 원격 액세스 설정 부분의 단계 4 의 별도 구성을 하지 않습니다.
19. 원격 액세스 설정 부분의 하단에서 “마침” 버튼을 클릭합니다.
20. 원격 액세스 검토 부분에서, “적용” 버튼을 클릭하여, DirectAccess 서버 구성을 완료합니다.
페이지 81 / 89
페이지 82 / 89
21. Remote Access 설정 마법사 설정 적용 부분에서, DirectAccess 부하 분산을 위한 대표 인증서
부분에 경고가 발생하지만, 이 부분은 무시하고 “닫기” 버튼을 클릭하여, 구성을 완료합니다.
22. 원격 액세스 관리 콘솔의 “작동 상태” 부분에서 EDGE1.CORP.CONTOSO.com 의 DirectAccess
서비스가 정상적으로 작동함을 확인합니다.
페이지 83 / 89
페이지 84 / 89
Step 8 : Windows 7 및 Windows 8 DirectAccess 클라이언트 테스트
일반적인 테스트는 앞서 “DirectAccess 테스트랩 구성 절차 (for Windows 8 Client)” 부분의 “Step 4 :
CLIENT1 구성” 의 절차를 그대로 진행합니다. 이 단계에서는, 인터넷 영역 및 Homenet 영역에
클라이언트가 연결되었을 때, 각 클라이언트 컴퓨터의 IPCONFIG 부분만 확인해 봅니다.
인터넷 영역의 CLIENT2W7.CORP.CONTOSO.com 의 IPCONFIG
Iphttpsinterface 터널 어댑터 부분에 정상적으로 IPv6 주소가 할당되어 있음을 알 수 있습니다.
Homenet 영역의 CLIENT2W7.CORP.CONTOSO.com 의 IPCONFIG
Iphttpsinterface 터널 어댑터 부분에 정상적으로 IPv6 주소가 할당되어 있음을 알 수 있습니다.
페이지 85 / 89
인터넷 영역의 CLIENT1.CORP.CONTOSO.com 의 IPCONFIG
Iphttpsinterface 터널 어댑터 부분에 정상적으로 IPv6 주소가 할당되어 있음을 알 수 있습니다.
페이지 86 / 89
Homenet 영역의 CLIENT1.CORP.CONTOSO.com 의 IPCONFIG
Iphttpsinterface 터널 어댑터 부분에 정상적으로 IPv6 주소가 할당되어 있음을 알 수 있습니다.
페이지 87 / 89
DirectAccess 서버의 원격 클라이언트 상태 확인
원격 액세스 관리 콘솔의 원격 클라이언트 상태 부분에서 아래와 같이 정상적으로 연결된 Windows 8 및
Windows 7 클라이언트를 확인할 수 있습니다.
페이지 88 / 89
페이지 89 / 89
참조자료
Deploy Remote Access in an Enterprise ( http://technet.microsoft.com/en-us/library/jj134200.aspx )
'Real World' Direct Access installation using Windows Server 2012
( http://blogs.msdn.com/b/canberrapfe/archive/2012/07/12/simple-direct-access-setup-with-windows-
server-2012-rp.aspx )
