멀티 홈 서버의 Active Directory 디자인에 대한 조언

고객이 다음 요구 사항을 충족하는 시나리오를 위해 작동하는 Active Directory 디자인을 생각해 냈습니다.

• 클라이언트 시스템의 서브넷이 있습니다.
• 서버 시스템의 서브넷이 있습니다.
• 두 네트워크가 연결되어 있지 않습니다.
• 각 서버에는 두 개의 네트워크 카드가 있어야합니다. 하나는 서버 네트워크에 있고 다른 하나는 클라이언트 네트워크에 있습니다.
• 클라이언트와 서버 간의 트래픽은 클라이언트 네트워크에서만 흐릅니다.
• 서버 간의 트래픽은 서버의 네트워크를 통해서만 흐릅니다.
• 이것은 도메인 컨트롤러에도 적용됩니다.

말할 필요도없이 이것은 Active Directory가 DNS를 사용하여 도메인 컨트롤러를 찾는 방법과는 잘 어울리지 않습니다. 가능한 모든 접근 방식은 다음 시나리오 중 하나를 초래합니다.

• DC는 "클라이언트 측"IP 주소를 도메인 DNS에 등록합니다. 클라이언트는 해당 주소를 사용하여 클라이언트와 대화하지만 서버 및 AD 복제 트래픽도 대화합니다.
• DC는 "서버 측"IP 주소를 도메인 DNS에 등록합니다. 서버는 해당 주소를 사용하여 서버와 통신하며 복제 트래픽은 해당 네트워크를 통해 흐르지 만 클라이언트는 서버에 연결할 수 없습니다.
• DC는 도메인 DNS에 두 IP 주소를 모두 등록 합니다 . 어떤 시스템이 그들에게 도달하기 위해 무엇을 할 것인지는 누구나 추측합니다.

물론 두 네트워크에서 DNS 서비스를 분할하고 SRV 레코드를 수동으로 채우거나 (argh) 서버를 찾도록하는 등의 미친 솔루션을 사용하지 않는 한 이러한 요구 사항은 완전히 열악하며 동시에 모든 요구 사항을 충족 할 수 없습니다. DNS를 사용하는 DC와 클라이언트는 WINS (double-argh)를 사용하여 DC를 찾습니다.

내가 찾은 솔루션은 "서버"네트워크에 2 개의 DC가 있고 "클라이언트"1에 2 개의 DC가 있고, 두 개의 AD 사이트를 정의하고 두 네트워크 사이의 경계를 DC 복제 트래픽으로 교차시키는 것입니다. 이것은 것입니다 여전히 각 서버가 있기 때문에, 일부 DNS 맹 글링을 필요로 여전히 (두 개의 서버 측 DC의 차별화 및 순수 백 엔드 서버) 두 개의 네트워크 카드를 가지고 있지만, 일에 적어도 몇 가지 가능성이있다.

가능한 빨리 도망 치는 것 이외의 조언이 있습니까?

나는 다른 많은 사람들과 동의한다고 말하면서 시작한다. 클라이언트를 달리 설득 시키거나 달리는 것이다.

그러나 나열된 요구 사항 (비공개가 많음)이 주어지면 적어도 이것을 실현하기위한 기초를 생각할 수 있습니다 (부분적으로 테스트).

고려해야 할 몇 가지 특정 측면이 있습니다.

1. Active Directory 도메인 서비스 복제
2. 클라이언트 / 회원 서버의 DC 로케이터 프로세스
3. 비 AD DS 서비스의 이름 확인 및 트래픽

하나와 둘은 공통점이 많습니다. 일반적으로 우리는이 문제에 대해 Microsoft의 책임이며 Microsoft의 AD DS 프로세스 범위 내에서 작업해야합니다.

세 번째로 작업 할 공간이 조금 있습니다. 서비스 액세스에 사용되는 레이블 (파일, 데이터베이스 인스턴스 등)을 선택할 수 있습니다.

여기 내가 제안하는 것이 있습니다.

도메인 컨트롤러 (DC) 구축

• 아마 적어도 두 사람.
• 각 DC에는 각 IP 네트워크 / AD DS 사이트에 하나씩 두 개의 NIC가 있습니다 (현재는 clt 및 srv라고 함).
• 지금은 srv 네트워크에서 각 DC에 하나의 NIC 만 구성하십시오.

AD 사이트 및 서비스를 올바르게 구성

• srv 사이트 및 서브넷
• clt 사이트 및 서브넷
• 사이트-> 사이트 간 전송-> "IP"를 마우스 오른쪽 단추로 클릭하여 "모든 사이트 링크 브리지"를 선택 취소 하십시오.
• DEFAULTIPSITELINK가 존재하거나 이름을 변경 한 경우 DEFAULTIPSITELINK를 삭제하여 구성된 사이트 링크가 없습니다. KCC는 두 사이트 (srv 및 clt)가 서로 다른 간격으로 연결되어 있지 않다는 오류를 디렉토리 서비스 이벤트 로그에 덤프 할 가능성이 있습니다. 그러나 두 DC간에 동일한 사이트의 IP를 사용하여 서로 연락 할 수 있으므로 복제는 계속 진행됩니다.

AD DS 통합 DNS에서 추가 영역 구성

• AD DS 도메인이 acme.local 인 경우 clt.acme.local 이라는 동적 업데이트가 활성화 된 두 번째 주 AD 통합 영역을 만듭니다 .

DC에 두 번째 NIC를 구성하십시오.

• 이 NIC는 clt 네트워크 / 사이트에서 NIC가됩니다.
• 그들의 IP를 설정
• 마술 부분은 다음과 같습니다 -어댑터 속성-> IPv4 속성-> 고급-> DNS 탭->이 연결의 DNS 접미사를 clt.acme.local로 설정 -> 확인이 연결 등록 ...- > 확인이 연결 사용 DNS 접미사 ...-> OK.
• ipconfig / registerdns
• clt.acme.local 영역에 clt NIC IP를 등록하여 나중에 사용할 IP / 네트워크를 제어 할 수있는 방법을 제공합니다.

구성원 서버 NIC 구성

• clt 사이트의 구성원 서버 NIC에는 DNS 접미사와 확인란이 위와 같이 적절히 설정되어 있어야합니다.
• 이 설정은 정적 및 DHCP와 함께 사용할 수 있으며 중요하지 않습니다.

사이트에서 DNS [스텁] 확인자 동작 구성

• DC-> 자체 및 다른 DC srv NIC IP를 사용하도록 DC srv NIC를 구성하십시오. DC clt NIC DNS를 비워 두십시오 (고정 IP가 필요함). (DC DNS 서버는 기본적으로 모든 IP를 계속 수신 합니다).
• 구성원 서버-> 구성원 서버 srv NIC가 DC srv 사이트 IP를 사용하도록 구성하십시오. 구성원 서버 clt NIC DNS를 비워 두십시오 (정적 IP를 사용할 수 있음).
• 클라이언트 / 워크 스테이션-> DC의 clt NIC IP를 사용하도록 DNS (DHCP 또는 정적을 통해)를 구성하십시오.

매핑 / 리소스를 적절하게 구성

• 서버가 서로 통신 할 때는 반드시 .acme.local을 사용하십시오->는 srv 네트워크 IP로 해석됩니다.
• 클라이언트가 서버와 대화 할 때는 반드시 .clt.acme.local을 사용해야합니다.-> 네트워크 IP를 파악합니다.

내가 무슨 소리 야?

• DC가 서로를 해결하고 서로 연결할 수 있으므로 AD DS 복제가 계속 발생합니다. acme.local 및 _msdcs.acme.local 영역에는 DC srv NIC IP의 AD DS 복제 만 포함되며 srv 네트워크에서만 발생합니다.
• 구성원 서버 및 워크 스테이션 용 DC 로케이터 프로세스는 작동합니다. 사이트를 알 수 없을 때 다양한 AD DS 프로세스의 여러 부분에서 지연 될 가능성이 있지만 여러 DC IP가 반환되면 시도, 실패 및 계속 될 것입니다. 하나가 작동 할 때까지 DFS-N에 대한 영향도 완전히 평가되지 않았지만 여전히 작동합니다.
• 앞에서 설명한 .acme.local 및 .clt.acme.local 레이블을 사용하면 비 AD DS 서비스가 제대로 작동합니다.

나는 그것이 다소 어리석기 때문에 이것을 완전히 테스트하지는 않았습니다. 그러나이 (와우, 긴) 답변의 요점은 그것이 수행되어야하는지 아닌가에 대한 평가를 시작하는 것입니다.

@코멘트

@Massimo 1/2 acme.local 영역의 여러 AD DS 사이트를 혼동하지 마십시오. 따라서 clt.acme.local 영역의 SRV 레코드가 필요한 acme.local 영역의 해당 사이트에 DC로 채워진 SRV 레코드를 혼동하지 마십시오. 클라이언트의 주 DNS 접미사 (및 이들이 연결된 Windows 도메인)는 여전히 acme.local입니다. 클라이언트 / 워크 스테이션에는 단일 NIC 만 있으며 DHCP에서 파생 된 주 DNS 접미사가 acme.local로 설정되어 있습니다.

clt.acme.local 영역은 DC 로케이터 프로세스에서 사용되지 않으므로 SRV 레코드가 필요하지 않습니다. 클라이언트 / 워크 스테이션에서만 clt 네트워크의 구성원 서버 IP를 사용하여 구성원 서버의 비 AD DS 서비스에 연결하는 데 사용됩니다. AD DS 관련 프로세스 (DC 로케이터)는 clt.acme.local 영역을 사용하지 않고 acme.local 영역의 AD DS 사이트 (및 서브넷)를 사용합니다.

@ 마시모 3

clt 및 srv AD DS 사이트 모두에 대한 SRV 레코드가 있습니다. acme.local 영역에만 존재한다는 것입니다. 위의 참고를 참조하십시오. clt.acme.local 영역에는 DC 관련 SRV 레코드가 필요하지 않습니다.

고객은 DC 벌금을 찾을 수 있습니다. 클라이언트 DNS 서버는 DC의 clt IP를 가리 킵니다.

클라이언트의 DC 로케이터 프로세스가 시작될 때

• 클라이언트가 자신의 사이트를 알고있는 경우 DNS 질문은 _ldap._tcp. [site] ._ sites.dc._msdcs.acme.local SRV입니다. SRV 레코드가 등록 된 사이트 별 DC를 다시 반환합니다.
• 클라이언트가없는 경우 하지 의 사이트를 알고있는 DNS 질문은 _ldap._tcp.dc._msdcs.acme.local SRV 될 것입니다. 그러면 모든 DC가 다시 반환됩니다. 클라이언트는 응답하는 것을 찾을 때까지 DC의 LDAP에 바인딩하려고 시도합니다. 클라이언트가 하나를 찾으면 사이트 찾아보기를 수행하여 클라이언트 사이트를 판별하고 레지스트리에서 사이트를 캐시하여 향후 DC 로케이터 인스턴스가 더 빨리 발생하도록합니다.

@ 마시모 4

어, 잘 잡아 내가 보는 방법에는이 문제를 해결하는 두 가지 방법이 있습니다.

1. 덜 영향 을 미치면 ( 아래 2와 비교) dc의 clt NIC IP를 가리키는 dc1.acme.local 및 dc2.acme.local 의 클라이언트 / 워크 스테이션에 호스트 파일 에 항목을 작성하는 것입니다 .

또는

2. 각 DC의 netlogon.dns 파일에 필요한 SRV 레코드를 수동으로 만듭니다. 이것은 서버 네트워크에 영향을 줄 수 있습니다. 구성원 서버가 구성된 경우 구성원 서버가 clt 네트워크의 DC와 통신 할 수 있습니다.

전체적으로 그 어느 것도 예쁘지는 않지만 반드시 최종 목표는 아닙니다. 고객이 테크 찹을 테스트하고있을 수도 있습니다. 회의 테이블에 올려 놓고 "이것은 효과가있을 것입니다.하지만 구성 및 지원을 위해 정상 요금의 4 배를 청구하고 있습니다. PITA 충전을 1.5 배로 줄일 수 있습니다. [올바른 해결책]. "

앞서 언급했듯이, 나의 추천은 달리 설득하거나 달리는 것입니다. 그러나 그것은 어리석은 재미있는 작은 운동입니다. :)

결국 나는 두 사이트 솔루션으로 갔다.

• "서버"네트워크 용 DC 2 개, "클라이언트"네트워크 용 DC 2 개
• 하나는 "서버"네트워크 용이고 다른 하나는 "클라이언트"용입니다.
• "서버"네트워크의 DC에는 해당 NIC에만 NIC가 설치되어 있으므로 (클라이언트가 전혀 대화하지 않을 수 있음) 이는 쉽습니다.
• "클라이언트"영역의 DC는 2 개이지만 클라이언트 측 DC에만 DNS에 등록됩니다.
• 서버는 DC와 통신하고 클라이언트는 서버와 통신합니다.

물론 이는 두 네트워크간에 복제 트래픽을 활성화하는 것을 의미합니다. "클라이언트"네트워크의 DC에는 여전히 "서버"네트워크에 NIC가 있지만 DNS에 등록되지 않으므로 해당 네트워크의 DC는 클라이언트 측 IP 주소를 사용하여 DC에 연결합니다. 실제로 NIC는 완전히 쓸모없고 일부 방화벽 포트를 열어야합니다. 다른 옵션은 DC hosts파일을 관리하는 것이지만 피할 수 있기를 바랍니다.

글쎄, 나는 이것이 가능한 많은 (미친) 요구 사항을 충족시키기 위해 할 수있는 최선이라고 생각합니다.

모든 조언에 감사드립니다 :-)

우선 고객에게 서비스를 제공 할 때 고객의 요구 사항이 무엇인지 질문해야합니다. 고객이 복잡성의 수준이 불필요하다는 것을 이해할 수 있도록합니다.

• 고객 수는 얼마입니까?
• 이것은 모두 내부 트래픽입니까?
• 도메인의 기능 수준은 무엇입니까?
• TLS 프로토콜이 사용되고 있습니까?

KISS 방법 사용 -SSL / TLS를 활성화하고 하루에 두 개의 VLAN "SVR"및 "CLT"를 생성합니다 ....