VPN 클라이언트를 위한 AD 사이트 매핑과 도메인 컨트롤러 고정 비교

VPN 풀의 원격 액세스 클라이언트가 지구 반대편의 도메인 컨트롤러와 통신하게 되는 경우가 있습니다. 이를 고치는 방법은 두 가지입니다. 풀을 올바른 컨트롤러가 있는 사이트에 연결된 Active Directory 서브넷으로 기술하거나, 클라이언트나 애플리케이션을 특정 컨트롤러 하나에 고정하는 것입니다. 전자는 DC Locator가 판단에 사용할 수 있는 토폴로지 선언입니다. 후자는 토폴로지를 완전히 무시하는 애플리케이션별 재정의입니다. 둘의 비용은 다르며, 당장 빠른 쪽을 택하는 것이 결국 디렉터리 팀이 둘 다 유지보수하게 되는 이유입니다.

각 접근 방식이 실제로 바꾸는 것

서브넷 개체는 어떤 주소 범위가 어느 사이트에 속하는지 알려 주는 디렉터리 레코드입니다. Active Directory 모듈과 기존 사이트가 있으면 이 작업은 미리 볼 수 있을 만큼 작습니다.

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf 은 디렉터리 쓰기를 미리 보여 줍니다. 개체를 만들지 않고 해당 범위의 클라이언트가 무언가에 도달할 수 있는지도 검사하지 않습니다. 그러나 사람들이 기대하는 부분이 바로 그것입니다. DC Locator는 서비스 레코드를 확인할 때 사이트 모델을 읽으므로, 정확한 서브넷 개체는 클라이언트에 제시되는 내용을 바꿉니다.

고정은 다른 계층에서 동작합니다. 애플리케이션 설정에 적힌 고정 컨트롤러 이름, 호스트를 포함한 LDAP 문자열, 선호 서버를 지정하는 레지스트리 값은 모두 검색을 경로에서 제거합니다. 애플리케이션은 누군가 설정을 바꿀 때까지 그 컨트롤러와 통신하며, 장애 시 전환은 그 애플리케이션이 구현한 방식에 따릅니다.

서브넷 매핑이 이기는 경우

풀을 매핑하면 DC Locator를 사용하는 모든 클라이언트에 대해 네트워크 위치를 한 번만 기술합니다. 풀이 하나의 /24에서 셋으로 늘어나도 모델은 애플리케이션 목록이 아니라 두세 개의 개체에서 바뀝니다. 그것이 장점의 전부이며, 클라이언트 집단이 통제 밖에 있을 때 그 장점은 큽니다.

함정은 개체가 컨트롤러가 실제로 보는 주소와 일치해야 한다는 점입니다. VPN 게이트웨이가 모든 클라이언트를 허브 주소로 변환한다면, 변환되지 않은 풀을 추가하는 것은 어떤 컨트롤러도 관찰하지 않는 네트워크 위치를 기술하는 셈입니다. 설계가 클라이언트 원본 주소를 유지하는지 일찍 결정하고, 유지하지 않는다면 VPN 서버에 구성한 풀이 아니라 변환된 범위를 매핑해야 합니다.

두 번째 한계: 사이트 모델은 선호이자 토폴로지 선언입니다. 컨트롤러를 도달 가능하게 만들지 않고 사용자에게 무엇도 부여하지 않습니다. 도달성은 경로와 방화벽 정책이 담당하고, 권한 부여는 계정 정책이 담당합니다.

고정이 이기는 경우

검색이 동작할 수 없을 때 고정이 정답입니다. 바꿀 수 없는 이름으로 컨트롤러를 확인하는 오래된 애플리케이션, 컨트롤러 주소 하나만 허용하는 필터, 컨트롤러가 애플리케이션 설계의 일부인 고정 서버 집합이 그렇습니다. 그런 경우의 고정은 요령이 아니라 실제 제약을 문서화한 것입니다.

그 비용은 매핑의 반대입니다. 고정된 이름은 풀을 따르지 않고, 애플리케이션이 방법을 모르면 장애 시 전환하지 않으며, 자산 조사 없이 컨트롤러의 이름 변경이나 폐기를 견디지 못합니다. 또한 토폴로지 문제를 숨깁니다. 고정한 클라이언트는 모두 건강해 보이지만 사이트 모델은 조용히 썩어 가기 때문입니다.

도메인의 일반 주소 레코드를 선호 서버 하나로 바꾸는 것은 세 번째 선택지가 아닙니다. 일반 검색 집합을 기대하는 모든 소비자를 깨뜨리며, 디렉터리를 인식하는 클라이언트가 사이트를 고르는 방식은 여전히 통제하지 못합니다.

세 가지 조건으로 선택하십시오

이 순서로 물으면 결정은 대개 스스로 내려집니다. 첫째, 애플리케이션이 DC Locator를 쓰는가, 아니면 이미 컨트롤러 주소를 가지고 있는가. 둘째, 컨트롤러가 보는 것은 풀 주소인가, 변환된 주소인가. 셋째, 고정을 갱신해야 할 지점 수에 비해 풀이 얼마나 자주 바뀌는가.

디렉터리를 인식하는 애플리케이션과 원본을 유지하는 라우팅, 그리고 변하는 풀이라면 서브넷을 매핑합니다. 검색할 수 없는 애플리케이션이나 주소 하나만 허용하는 필터라면 고정하고 이유를 적어 두십시오. 나머지는 또 하나의 재정의를 추가할 일이 아니라 토폴로지를 고칠 일입니다.

VPN 클라이언트에서 검증하고 계약은 분리해 두십시오

이미 사이트에 있는 LAN 워크스테이션이 아니라 실제 원격 경로에서 시험하십시오. 의미가 있는 것은 클라이언트 자신의 시각뿐입니다.

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

보고된 사이트가 매핑한 사이트라면 개체가 일치합니다. 클라이언트가 사이트를 보고하지 않는다면 제시하는 주소가 어떤 서브넷 개체에도 들어가지 않는다는 뜻이며, 보통 변환 또는 오래된 접두사를 의미합니다. 그다음에는 매핑이 실패했다고 가정하기 전에 선택된 컨트롤러가 의도한 것인지 확인하십시오. 클라이언트는 검색 결과를 캐시하며 장애 시 전환이 정당하게 다른 컨트롤러를 고를 수 있기 때문입니다.

세 가지 계약을 한 문서에 유지하십시오. 풀과 그 서브넷 개체, VPN 경로에서 도달 가능한 컨트롤러, 그리고 로그인한 사용자가 무엇을 할 수 있는지 정하는 정책입니다. 사이트는 방화벽 규칙도 격리 경계도 아니며, 매핑과 경로와 문서화된 대안이 함께 움직이지 않으면 다음 풀 변경이 원격 사용자를 디렉터리의 네트워크 모델에서 조용히 떼어 놓을 것입니다.