크리에이티브 IP / 서브넷 / dns 체계

다소 작은 네트워크 (<= 25 노드) 만 관리했습니다. 일반적으로 게이트웨이 .1, dns / proxy를 .10으로, 메일을 .20으로, 프린터를 .30-39 등으로 설정합니다. DNS 호스트 이름이 더 나은 방법이므로 IP 주소를 직접 사용하지는 않지만 처음부터 네트워크를 구축 할 때 명확한 패턴 / 레이아웃 / 디자인을 원합니다.

내 DNS 매핑에는 간단한 명명 패턴 / 레이아웃도 있습니다. 예를 들어, 모든 장치에는 두 개의 이름이 있습니다. 역할 (dc01, mail02 등)을 기반으로 한 공식 이름과 비공식 이름. 공상은 없지만 단순하고 관리하기 쉽습니다.

더 직관적이고 창의적인 IP / 서브넷 / DNS 체계를 찾으려고합니다 (더 나은 것이있는 경우). 나는 네트워크 목표 등에 따라 다른 사람들 이보다 직관적 인 계획을 가지고 있다고 확신합니다. 현재 작업중인 네트워크는 여전히 작지만 경쟁 할 장치가 많습니다.

4-5 개의 주요 포인트를 포함하는 IP 주소 (범위 / 클래스), DNS 이름 및 서브넷 네트워크를 할당하는 일반적인 패턴 또는 방법을 찾고 있습니다.

1. 네트워크 서비스 (메일, 파일, 프록시 등)
2. 소프트웨어 개발 (환경-개발 / 스테이징 / 제품,
3. 미디어 (스트리밍, 대용량 파일 전송, 보관)
4. 가상 서버 / 데스크탑
5. VoIP

나는 VoIP로 직접 작업 한 적이 없지만 미래에 고려해야 할 사항입니다.

전반적으로 나는 모두에게서 좋은 아이디어를 얻었습니다. 더 많은 표 / 허용 된 답변을 드릴 수 있기를 바랍니다. 답변 주셔서 감사합니다!

간단하게 유지하십시오. 최대한 간단하지만 보안과 유연성을 여전히 허용합니다. 사물로 추상화를 디자인하십시오. 간단하지 않은 것처럼 들리지만 실제로는 단순성으로가는 길입니다.

서브넷의 경우 이것은 매우 일반적입니다.

• 하나의 서브넷에있는 사용자
• 다른 손님
• 자체 서브넷에있는 서버
• VoIP 자체도 마찬가지입니다.

필요에 따라 각 서브넷을 통해 트래픽을 필터링하십시오. VLAN을 사용할 수 있습니다. 선택한 네트워크 장치 공급 업체의 CLI에 대해 잘 알고 있기를 바랍니다.

DNS에 관해서는, 당신은 이것을 좋아하지 않을 것이지만 ... 당신에게 맞는 것을 사용하십시오. 개인적으로, 나는 서비스와 관련이없는 완전히 추상적 인 호스트 이름을 서버에 제공하고 싶습니다. 그런 다음 CNAME을 호스트 이름으로 서비스합니다. 이렇게하면 서비스를 마이그레이션해도 DNS 변경 문제가 발생하지 않습니다. 또는 적어도 많지 않습니다. 또한 호스트 이름 앞에 av가 붙은 가상 서버의 이름을 지정하는 것을 선호합니다.

예 :

• 새 데이터베이스 서버의 이름은 Athena입니다. 그것은 영원히 Athena로 지명 될 것입니다.
• Athena는 SQL08ENT-CRM, SQL08ENT-AEGIS (보안 시스템), SQL08ENT-DOCMAN에 대한 CNAMED입니다. 아마도 지역에 따라 CNAMED 일 수도 있습니다. 또는 호스트 이름에 지리가있을 수 있습니다. 아테나 -ATL. 아테나 시드니. 뭐든간에
• 서버가 기본 거부 정책이있는 서버 서브넷에 있습니다. 적절한 서브넷에서 적절한 트래픽이 포함되어 있습니다.

유지. 그것. 단순한. (그러나 기능적)

필자는 비슷한 규모의 조직 (우리는 / 26 명)에서 근무했으며, 그 이상의 이유 때문에 세밀한 IP 할당 체계가 운영 무결성에 가장 중요하다고 느꼈습니다. 게이트웨이 는 .1이어야하고 프린터 는 .2와 .12 사이, 서버는 .13과 .20 사이 여야했습니다. 개별 호스트에 대한 문서도 보관했습니다.

이것은 엉덩이에 큰 고통입니다. 아무리 부지런해도 문서를 최신 상태로 유지할 수 없었습니다. DNS 서비스가 없었기 때문에이 IP 할당 체계 문서를 사용하는 것이 우리가 가진 유일한 "이름 지정"서비스였습니다 (이상한 방식으로 실제보다 더 필수 불가결 한 것으로 보임).

규모가 큰 네트워크의 경우 몇 가지 사항을 권장합니다 (대부분 이미 수행 한 작업).

• 단순 -수백 개의 호스트를 관리하지 않습니다. 솔루션의 복잡성은 환경의 복잡성을 반영해야합니다. 지나치게 영리한 유혹에 저항하십시오. 나중에 스스로에게 감사 할 것입니다.

  1. 사용 가능한 IP 공간을 확보하고 DHCP를 통해 클라이언트에게 60 %를 제공하십시오. 어떤 종류의 동적 DNS 서비스를 설정하여 지독한 IP 주소를 다시 볼 필요가 없습니다. 그것들을 추적하는 것을 잊어라. 이익.

  2. IP 주소에 대한 다른 30 % 예약 이 서비스를 테스트 서버, 프린터, 네트워크 장치 : 관리한다. 등. DNS를 사용하여 문서화하십시오. 제 생각에는 Excel 스프레드 시트 (지속적으로 참조하고 유지해야 함)를 사용하여 DHCP 관리 IP 주소와 달리 이러한 "관리자 관리"IP 주소를 모두 적절하게 추적하는 것보다 더 큰 시간 낭비가 없습니다. 자체 문서화 및 훨씬 유용한 DNS 솔루션을 지원하기 위해 이러한 노력을 기울일 수 있습니다.

  3. 사용하지 않는 IP 주소 공간의 상단에 주소의 마지막 10 %를 유지하십시오. 작은 예비금은 결코 아프지 않습니다.

  4. 환경에 맞게 비율을 조정하십시오. 일부 환경에는 더 많은 클라이언트가 있고 일부 환경에는 "서버"(즉, "관리자 관리")가 무겁습니다.

• 네트워크 서비스 (메일, 파일, 프록시 등)
• 소프트웨어 개발 (환경-개발 / 스테이징 / 제품,

이 둘은 "관리자 관리"IP 공간 범주에 속합니다.

• 미디어 (스트리밍, 대용량 파일 전송, 보관)

내 생각에 이것은 서브넷과 관련이 없으며 네트워크 모니터링과 관련이 있습니다.

• 가상 서버 / 데스크탑

서버는 "관리자 관리"이고 데스크톱 (예 : 클라이언트 컴퓨터)은 "DHCP 관리"여야합니다.

• VoIP

물리적으로 별개의 네트워크가 이상적 일 수 있지만 비현실적입니다. 다음으로 가장 좋은 것은 별도의 VLAN과 서브넷입니다. 이것은 소규모 네트워크에서 트래픽을 분리해야 할 필요성을 느끼는 유일한 지점에 관한 것입니다 (공개적으로 액세스 가능한 것은 제외).

IP 할당

다음 구조를 사용하여 모든 것을 10.0.0.0/8 서브넷 아래에 배치하는 것이 site좋습니다. 10 . division.device

• site 물리적 위치 또는 논리적 등가물입니다 (예 : NY 사무소, NJ 사무소, DR 시설, 개발 환경).
• division논리적 인 세분입니다. 예 :
  0 => 스위치 / 라우터
  1 => 관리자, 2 => 사용자
  3 => VOIP
  4 => 손님
• device개별 장치 (PC, 서버, 전화, 스위치 등)

여기서 아이디어는 장치의 위치와 주소를 기준으로 장치의 위치를 ​​쉽게 결정할 수 있다는 것입니다. 10.2.1.100은 "사이트 # 2"의 관리자 워크 스테이션입니다.

이 모델은 클래스 기반 IP 할당에서 파생됩니다. 클래스 A (/ 8)는 기업입니다. 각 위치는 클래스 B (/ 16)를 받고, 위치의 각 논리 부서는 장치에 대한 클래스 C (/ 24)를받습니다.
"분할"레벨에 / 24보다 큰 것을 사용하는 것이 가능하며 때로는 바람직한 경우도 있습니다. / 17에서 / 24까지의 모든 것은 일반적으로이 구성표를 사용하는 공정한 게임입니다.

DNS 이름의 경우

저의 조언은 위에서 설명한 IP 할당과 비슷한 체계를 따르는 것입니다.

• 모든 것이 뿌리 mycompany.com
• 각 사이트 (/ 16)에는 자체 sitename.mycompany.com하위 도메인이 있습니다.
• 논리 부서에는 사이트 내에 하나 이상의 하위 도메인이있을 수 있습니다. 예를 들면 다음과 같습니다.
  • voip.mycompany.com(장치처럼 함께 tel0000.voip.mycompany.com, tel0001.voip.mycompany.com등)
  • switches.mycompany.com
  • workstations.mycompany.com (관리자, 사용자 및 손님으로 더 세분화 될 수 있음)
• 장치에는 의미있는 이름이 있어야합니다. 예를 들면 다음과 같습니다.
  • DNS 이름을 기준으로 벨소리가 울리는 내선 번호를 볼 수 있도록 전화의 이름을 지정하십시오.
  • 기본 사용자를 기준으로 워크 스테이션 이름을 지정하십시오.
  • "게스트"IP 주소를 명확하게 식별하십시오.
  • 서버의 이름과 기능을 알 수 있도록 서버 이름을 지정하십시오.
    이것은 (이름을 "지루한"사용하여 수행 할 수 있습니다 www01, www02, db01, db02, mail등) 또는 명명 체계를 공표하고 (예를 들어, 그것에 집착하여 : 메일 서버가 바위 이름을 따서 명명, 웹 서버는 나무의 이름을 따서 명명되어, 데이터베이스 서버는 화가의 이름을 따서).
    지루한 이름은 새로운 사람이 배우기 쉽고 멋진 이름 지정 체계가 더 재미 있습니다. 골라보세요.

기타 노트

가상 서버에 대해서는 :
. 그들은 물리적 시스템 (부문 / 목적으로하기보다는 그들이있는 거 "가상"하이퍼 바이저 / VM 관리 네트워크에 대한 별도의 부서를 가지고 있다는 사실을 분리 것처럼 이들에게 동일을 고려하십시오.
그것은 중요한 것처럼 보일 수 있습니다 상자가 가상인지 물리적인지 알 수 있지만 모니터링 시스템에 "이봐, 이메일이 다운되었습니다!"라고 표시되면 "어떤 시스템이 이메일과 관련이 있습니까?"라는 메시지가 표시됩니다. 가상 및 어떤 물리적입니까? ".
당신이주의 마십시오 기계가 하이퍼 바이저 호스트가 불면 경우 가상 또는 물리적 여부를 확인하는 실제적인 방법이 필요합니다, 그러나 이것은 당신의 모니터링 시스템이 아닌 네트워크 아키텍처에 대한 도전이다.

VOIP 관련 :
VOIP (특히 별표)는 "보안 구멍"의 동의어입니다. 모든 VOIP 항목을 자체 서브넷과 자체 VLAN에 연결하고 민감한 부분 가까이 두지 마십시오.
작년에 내가 본 모든 VOIP 전화는 VLAN 분리를 지원합니다 (사실 모두 음성 및 데이터 VLAN을 모두 지원하므로 전화를 데스크탑 이더넷 연결을위한 패스 스루로 사용할 수 있습니다). 이것을 활용하십시오-VOIP 환경이 해킹 당했을 때 기뻐할 것입니다.

계획 및 설명서 관련 정보 :
주소 및 DNS 이름 할당을 시작하기 전에 종이에 네트워크를 그리십시오. 실제로, 먼저 큰 종이에 연필로 그립니다.
많은 실수를 저 지르십시오.
자유롭게 지 웁니다.
유창하게 저주하십시오.
최소한 10 일 동안 저주와 소거를 중단하면 공식 네트워크 다이어그램으로 다이어그램을 Visio / Graffle / 일부 다른 전자 형식으로 넣을 차례입니다. 이 다이어그램을 보호하십시오. 장치를 추가 및 제거하고 조직을 키우며 네트워크 구조를 수정하면서 최대한의 정확성을 유지하십시오.
이 네트워크 다이어그램은 변경을하거나 새로운 관리자에게 네트워크를 설명하거나 신비한 실패를 해결해야 할 때 가장 친한 친구가 될 것입니다.